Diagnosis
Why your MCP server returns 404
We tried to shake hands with every MCP endpoint in the public registries. 3,847 of 8,593 failed, and the failures are not evenly spread: eight causes account for almost all of them. Here is each one, how often it happens, and what it means when it is yours.
The distribution
We ran a standard handshake against every MCP endpoint in the public registries: an initialize call, then tools/list, read-only, short timeout, no retries. Of 8,593 endpoints, 3,847 failed. The failures cluster hard.
| Failure | Count | Share of all attempts |
|---|---|---|
| http 404 | 1,237 | 14.4% |
| http 422 | 1,160 | 13.5% |
| http 405 | 563 | 6.6% |
| connect error | 319 | 3.7% |
| http 429 | 211 | 2.5% |
| TLS handshake | 128 | 1.5% |
| http 402 | 69 | 0.8% |
| timeouts | 54 | 0.6% |
Three causes are two thirds of everything that goes wrong. They have completely different fixes, and they are routinely confused with each other because a client usually reports all three the same way.
404: the listing is stale
The largest single failure in the ecosystem, and the least interesting technically. Nothing is served at the address the entry gives. The server may be perfectly healthy somewhere else.
What causes it, in rough order of frequency: the path changed and the listing did not, a deployment moved to a new host, the entry was written by hand with a typo, or the service was retired and nothing removed the row.
1,237 endpoints answer 404 at the address their own listing gives. That is a bookkeeping failure, not a protocol failure, and no directory noticed.
How to check yours
curl -i -X POST https://your-host/mcp \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{
"protocolVersion":"2025-06-18","capabilities":{},
"clientInfo":{"name":"check","version":"1"}}}'
A 404 here means the path is wrong. Try it without the trailing segment, and with it. A surprising share of these are a missing or extra /mcp.
422: something answers, but not the protocol
The second largest, and the one people find hardest to diagnose, because the host is up and TLS works and a browser shows a page. The request reached something that accepted it and rejected the body.
The usual culprits are an API gateway in front of the server, a framework rejecting the JSON-RPC shape because it expects a specific schema, or a URL that points at documentation rather than at the protocol endpoint. The last is more common than it should be: a listing points at the project homepage and the homepage answers.
How to tell them apart
Look at what came back. A JSON-RPC error object means you reached a protocol implementation that disliked your request. HTML means you reached a web page. A gateway error mentioning a schema or a validation failure means something is in front of your server.
405: an SSE-era path
563 endpoints answered method not allowed. Most are a version-skew problem rather than a bug. The older HTTP+SSE transport used a different path shape, and a client speaking streamable HTTP POSTs to a path that only ever accepted GET.
If you serve the older transport and want current clients to work, the fix is to serve streamable HTTP at the path your listing advertises. If you have deliberately dropped SSE, answer 405 with an Allow header rather than 404, because a 404 tells a client the endpoint does not exist and it will stop trying. That distinction is worth more than it sounds: a 404 on the wrong verb reads to an SDK as "there is nothing here", and the client gives up on a server that works.
Connection errors and TLS: the host is gone or misconfigured
319 connection errors and 128 TLS handshake failures. These are infrastructure rather than protocol. The TLS group is worth a specific check, because it fails silently for a subset of clients: an incomplete certificate chain often works in a browser, which fills in the missing intermediate from its own store, and fails in a plain HTTP client that does not.
openssl s_client -connect your-host:443 -servername your-host < /dev/null 2>&1 | head -20
If that shows a verify error but the browser is happy, your chain is incomplete. Every non-browser client will fail, and agents are non-browser clients.
429 and 402: answering, but not to you
211 endpoints rate limited a single handshake, and 69 asked for payment. Both are legitimate, and both are invisible in most listings. A server that rate limits discovery traffic is effectively opting out of being discovered, which may be intentional and is worth doing knowingly rather than by default.
Not a failure: 2,094 endpoints that wanted credentials
Worth stating plainly because it is often counted as breakage. An endpoint answering 401 or 403 to an anonymous handshake is correct. It answered. It has a policy.
The problem is not the requirement, it is that the requirement is undiscoverable. An agent finds out by failing, and a developer finds out from a stack trace. If your server needs credentials, say so in your published entry: it costs you nothing and saves every client one failed round trip.
A four-step triage
- Does the host resolve and complete TLS? If not, it is infrastructure and nothing else matters. Use the openssl check above, not a browser.
- Does the exact path in your listing exist? Not the homepage, the path. This catches the 1,237.
- Does a JSON-RPC initialize get a JSON-RPC response? If you get HTML or a gateway error, something is in front of you.
- Does your listing say what you require? Auth, rate limits, payment. Undocumented requirements are indistinguishable from breakage.
The part nobody checks
Every number here exists because somebody connected. Most directories do not: they accept a submission, store the URL, and display it indefinitely. That is why an ecosystem can carry 1,237 endpoints that answer 404 at their own registered address without anybody raising it.
If you publish a server, the useful habit is to run the handshake against your own listing on a schedule, from outside your network, the way a stranger would. Almost every failure above is something you can see in one request and would never see from inside.
Method
Two read-only JSON-RPC calls per endpoint over streamable HTTP, short timeout, no retries, one attempt per endpoint per sweep, project user agent. Endpoints answering 401 or 403 recorded as auth-required rather than failed. 8,593 endpoints attempted, figures as of 5 September 2026. No tool was invoked.
Use Neuronto from your agent
One call searches this index and every other public ARD registry. No key, no signup. Or install it as an MCP server and let the agent search from the interface it already speaks.
curl -s https://neuronto.com/search \
-H 'content-type: application/json' \
-d '{"query":{"text":"scrape a website"},"federation":"auto"}'
claude mcp add --transport http neuronto https://neuronto.com/mcp