modelcontextprotocol / modelcontextprotocol/registry
HTTP authentication verification fails due to unreachable verification endpoint / missing egress IP documentation
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 7.3k
- Forks
- 994
- Avg merge
- 4d 12h
- Merged PRs (30d)
- 19
Description
Describe the bug
HTTP authentication login fails because the MCP Registry cannot fetch the public key verification file from the registered domain.
The domain is correctly configured according to the HTTP authentication flow:
/.well-known/mcp-registry-authis publicly accessible- The response format is correct (
v=MCPv1; k=ed25519; p=...) - The endpoint returns HTTP 200
- The same endpoint is reachable from multiple networks
However, during the authentication flow, the Registry backend fails to fetch the verification file and returns a timeout error.
This appears to be related to Registry outbound connectivity or missing documentation about the Registry verification request source IPs.
To Reproduce
Steps to reproduce the behavior:
- Configure HTTP authentication for a domain.
- Publish the verification file at:
https://example.com/.well-known/mcp-registry-auth
- Run:
mcp-publisher login http --domain "example.com" --private-key "<private-key>"
- Observe that authentication fails when the Registry tries to fetch the public key.
Expected behavior
The MCP Registry should successfully fetch the HTTP authentication verification file and complete the login flow.
If the Registry requires specific network access rules, the documentation should describe:
- Registry outbound/egress IP ranges
- Required firewall/CDN allowlist configuration
- Connectivity requirements for
/.well-known/mcp-registry-auth
Logs
Command:
mcp-publisher login http --domain "tamin24.ir" --private-key "XX"
Output:
Logging in with http...
Signing in process using key algorithm ed25519
Expected proof record:
v=MCPv1; k=ed25519; p=gvexpyDRgdRQV7mn7lPmSvbKTA2Clbs32kcky72L8dc=
Error:
failed to get token: failed to exchange http signature: token exchange failed with status 401
HTTP authentication failed:
failed to fetch keys:
failed to fetch public key:
failed to fetch key:
Get "https://tamin24.ir/.well-known/mcp-registry-auth":
dial tcp 185.143.233.238:443: i/o timeout
The verification endpoint is reachable:
curl https://tamin24.ir/.well-known/mcp-registry-auth
Response:
v=MCPv1; k=ed25519; p=gvexpyDRgdRQV7mn7lPmSvbKTA2Clbs32kcky72L8dc=
Additional context
The domain is behind ArvanCloud CDN.
Additional tests:
- TLS certificate is valid.
- DNS resolution is correct.
- Both CDN edge IPs respond successfully:
185.143.233.238
185.143.234.238
Both of the following tests return HTTP 200:
curl --resolve tamin24.ir:443:185.143.233.238 https://tamin24.ir/.well-known/mcp-registry-auth
curl --resolve tamin24.ir:443:185.143.234.238 https://tamin24.ir/.well-known/mcp-registry-auth
The registry endpoint appears to run on Google Cloud infrastructure, but no official documentation was found regarding the outbound IP addresses used for HTTP authentication verification requests.
It would be helpful to document the expected egress IP ranges or provide more detailed diagnostics for failed verification fetches.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start at the HTTP authentication login flow invoked by mcp-publisher login http and the Registry fetch of /.well-known/mcp-registry-auth; inspect outbound request diagnostics against the reported timeout and successful curl results. Done means the Registry can fetch the verification key for this case, or the required egress IP ranges, allowlist rules, and connectivity requirements are documented.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- authentication, backend, documentation, networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 52/100