~11% of advertised remote endpoints do not speak MCP at the URL given (sampled 1,200 of 10,542)

Follow-up to #1485, and a different layer of the same question. That issue asked whether the hosts behind remotes[] still resolve in DNS. This one asks whether the endpoints speak MCP at the URL given — which turns out to be a much larger and more actionable number.

DNS resolution is a weak test. A host can resolve, serve HTTP, return 200, and still not be an MCP server at that path.

Method

An MCP initialize handshake over JSON-RPC, not a status code. Three probes per endpoint.

npx -y -p github:siliroid/unreached unreached-registry --api https://registry.modelcontextprotocol.io

Scope: walked 60,763 entries over 608 pages. 21,346 advertise at least one remote (35.1%), resolving to 10,542 unique endpoint URLs — 2,766 of which are claimed by more than one server.

Result, on a seeded random sample of 1,200 of those 10,542

The number I would act on

11.2% of advertised endpoints do not speak MCP at the URL given — 95% CI 9.4–12.9%. Extrapolated to all 10,542 unique endpoints that is roughly 1,177 URLs (CI ~989–1,365) where a client following this registry connects and gets something that is not an MCP server.

These are not dead hosts. They are live hosts serving something else at the advertised path — moved endpoints, retired paths, a marketing page where the server used to be.

Two things worth knowing before anyone builds a health check on this

1. alive-gated is healthy, and any check that treats non-200 as failure will condemn a quarter of the registry. 318 of these answer 401/402/403 because they are commercial servers that want an OAuth token. That is working as designed.

I got this wrong myself in a way worth repeating: I first special-cased only 401 and 403 as "requires auth". One endpoint answers 402 Payment Required with the body Missing authentication — a live commercial service that sat in my broken column until I widened the check. Enumerating that category from memory rather than from the spec cost me a false positive.

2. Curation changes the distribution completely, so do not generalise from a curated list. I published that "two-thirds of hosted MCP servers are gated" based on 112 endpoints from two curated catalogues, then ran this sample and found gated is 33% of live endpoints here, not 67%. Curated lists are lists of commercial products, which gate by nature. This registry is self-publication, so it is full of servers that gate nothing. I have corrected that publicly rather than quietly.

Caveats, stated plainly

• This is a sample, not a census. 1,200 of 10,542, seeded so it is reproducible. Rates carry the CI above; the raw counts are counts of the sample only.
• unknown stays unknown. 111 endpoints timed out or returned 5xx from where I am. That is not evidence they are down and I am not reporting them as such.
• I did not probe the full 10,542. Happy to, if that is useful to you — say so and I will run it and post the list.

What might be worth having in the registry itself

Nothing about this requires me. A publish-time initialize handshake against the submitted remotes[].url would reject a meaningful share of the 11.2% at the point of entry, and a periodic re-check would catch the ones that rot afterward. The distinction that matters for both is alive-gated vs not-mcp — 401 is a pass, not a failure.

Raw results for every probed endpoint, including the three outcomes per URL, are in OFFICIAL-REMOTES.json in the linked repo.

Start by reviewing how the registry handles submitted remotes[].url values, using the MCP initialize handshake described in the issue as the behavioral reference. The unreached-registry command and OFFICIAL-REMOTES.json provide probe methodology and result categories. Done should distinguish alive-gated from not-mcp, reject endpoints that do not speak MCP, and preserve unknown outcomes as unknown.