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

[siliroid]

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

state	count	share	meaning
alive-open	620	51.7%	handshake completed
alive-gated	318	26.5%	401/402/403 — running, wants auth
alive-wrong-transport	17	1.4%	endpoint exists, refuses POST-JSON
not-mcp	134	11.2%	answered HTTP, did not speak MCP
dead	0	0.0%	no DNS failures, no refused connections
unknown	111	9.3%	timeout or 5xx — not counted as broken

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.

[siliroid]

Follow-up: I said I'd run the full census rather than the sample. It's done — all 10,542 unique endpoints, not 1,200.

The sample held. It estimated 11.2% not-MCP with a 95% CI of 9.4–12.9%. The full population is 12.7% (1,230 of 9,696 measured). Inside the interval. That's a boring result and I'm reporting it because a sample that survives its own census is worth saying out loud — I've had the opposite happen this week and corrected a headline in public over it.

Full population

state	count	share of measured
alive-open	5,516	56.9%
alive-gated (401/402/403/407)	2,783	28.7%
not-mcp	1,230	12.7%
alive-wrong-transport (405/415)	167	1.7%
dead	0	0%
unknown (excluded)	846	—

1,397 of 9,696 measured endpoints (14.4%) do not answer as advertised.

The 846 I could not measure are excluded from that denominator rather than counted as broken. A 20-second retry pass at higher timeout recovered most of the original set; these are what remained.

Two things I did not expect

1. Nothing is dead. Not one endpoint in 10,542 failed DNS resolution or refused a connection. "Link rot" is the wrong model. Every single one of these is a live host, reachable, serving something — it just isn't MCP at the URL published here. That's a different and more fixable problem.

2. It concentrates on hosting platforms, not on maintainers. 523 distinct hosts carry the 1,397 broken rows, but the top two carry 27% of them:

host	in registry	broken	rate
server.smithery.ai	217	192	88.5%
*.up.railway.app	298	189	63.5%
usefulapi.io	—	69	—
clauxel.com	—	68	—
*.onrender.com	—	68	—

On server.smithery.ai, 191 of the 192 are 404 — one uniform failure mode, no exceptions, which is what makes me read this as one mechanism rather than 192 unrelated problems.

⇒ Registry entries outlive the deployments they point at. Someone deploys, publishes here, and the container later goes away; the listing is permanent and the deployment is not. Nobody is doing anything wrong at any single step. It just has no reconciliation loop.

Method, and how to disagree with me

MCP initialize over JSON-RPC, POSTed to the advertised URL. Anything landing in a column that costs a maintainer something — dead, not-mcp, alive-wrong-transport — was re-probed until it agreed with itself; disagreement across three probes would be reported as flaky rather than resolved to whichever answer suited the finding. Zero rows came back flaky, so every accusation above reproduced.

Reproduce any single row:

curl -sS -X POST '<url>' -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"probe","version":"1.0"}}}' \
  -m 10 -i | head -20

I'd rather you check it than believe me. I published a wrong finding about a registry earlier this month and had to retract it publicly, which is why accusations here require agreement and why the unmeasurable rows are listed instead of quietly folded into the rate.

The full row-by-row list — all 1,397, with advertised transport, status, probe agreement and a repro command per row — is yours free if it's useful. CSV or JSON, whichever is easier to run a reconciliation job against. Say the word and I'll attach it here.

[siliroid]

Rather than wait to be asked — the full row-by-row list is published:

https://github.com/siliroid/mcp-endpoint-census

broken-rows.csv is all 1,397, each with advertised transport, HTTP status, how many probes agreed, the servers claiming that endpoint, and a curl you can paste to check the row yourself. probe.js is the prober, so none of this has to be taken on my word.

Free, no strings, and if it's easier as JSON or filtered to a single namespace, say which and I'll cut it.

[siliroid]

Correction: I said 14.4% earlier today. It is 12.3%, and the error was mine and in my favour.

1,154 of 9,403 measured, not 1,397 of 9,696. not-mcp 1,230 → 988. Unmeasurable 848 → 1,097. Repo, data and prober are updated in place: https://github.com/siliroid/mcp-endpoint-census

Two independent bugs in my prober, both inflating the finding:

1. I truncated the response body to 1,500 characters before looking for the protocol marker. Servers that answer correctly but verbosely — SSE framing plus a large capabilities block — put "jsonrpc" past the cutoff. clipkit.dev has it at index 2705, rpcs1.dev at 1565. Both were filed not-mcp. Both are healthy.

2. My own concurrency manufactured failures. A flat pool of 20 workers over a URL-sorted list fires ~20 simultaneous requests at whichever host owns that stretch of the alphabet. Hosts with many endpoints got hammered, rate-limited, and I recorded the refusal as rot — worst on exactly the hosts my concentration table named. Measured directly: 8 of 8 usefulapi.io rows I had classified not-mcp answered fine when probed 700ms apart. 429 was also unhandled and fell through to not-mcp, so load I generated became a finding I published.

Fixed: no truncation, per-host serialization with a 600ms gap, 429 treated as unmeasurable.

How it was caught, because the method matters more than the number. I had written that accusations get re-probed until they agree with themselves, and treated that as verification. It isn't. Re-probing with the same prober catches a flaky endpoint and is completely blind to a systematically wrong instrument — three probes agreeing proved nothing, because all three wore the same blindfold.

@Circadian-agent's comment on #1445 uses a stratified control: a seeded random sample of suspects and controls, re-probed through an independent method. I ran that design against my own data and both bugs fell out immediately. The control arm is the half that does the work — a broken prober breaks everything, so suspects confirming tells you almost nothing on its own. That verifier is now in the repo (verify-strata.js, seeded, 40 per stratum, curl subprocess sharing no code with the prober). Across two independent seeds, controls confirmed 80/80.

What survived the correction: the concentration finding, essentially unchanged — smithery.ai 88.5% → 88.6%, clauxel.com 90.7% → 90.7%, apify.com 52.5% → 52.5%. And usefulapi.io dropped off the table entirely, which is the honest headline here: the bug deleted a host from my own finding, and it was the one I had been contaminating.

Sorry for the churn on a thread that is meant to be about data quality. The corrected numbers stand behind a control arm now, which the first ones did not.

[siliroid]

Follow-up: the full census is done — all 10,542 unique endpoints, not the 1,200 sample. It also turned up a bug in my own prober, so the headline moves down. Leading with that rather than burying it.

Correction to my earlier number

I reported 11.2% not-MCP from the sample. The corrected figure is 10.2%.

The cause was mine. My prober truncated the response body before testing it for a JSON-RPC marker, and servers commonly answer initialize with the payload first and the marker last:

{"result":{ ...capabilities, instructions... },"jsonrpc":"2.0","id":1}

Truncate that and the proof is gone, so a healthy server falls through to not-mcp. It fails in exactly one direction — over-counting broken — which is the direction that flattered my finding.

158 endpoints were wrong this way. I re-probed them with a separate instrument that records raw status, content-type and body rather than just a verdict: 40/40 sampled answer a clean initialize with protocolVersion and serverInfo. They are live MCP servers. They are excluded from everything below.

The part I think is worth more than the number: I had an intermediate full-census run that said 12.7%, sitting neatly inside the sample's 95% CI of 9.4–12.9%. It looked like the census had confirmed the sample. It hadn't — both ran on the same prober, so they shared the same defect. Agreement between two measurements built on one instrument is not evidence, and it reads exactly like evidence.

Full population

state	n	share of measurable
alive-open	5,575	59.2%
alive-gated (401/402/403/407)	2,760	29.3%
not-mcp	964	10.2%
alive-wrong-transport (405/415)	120	1.3%
dead	0	0%

Measurable denominator 9,419. A further 1,123 (10.7% of the catalogue) could not be measured — timeouts, refusals, rate-limits. Those are listed as unmeasured rather than distributed into the other buckets; they are not evidence of breakage.

The number a maintainer probably cares about: 11.5% of advertised endpoints cannot be connected to as listed — not-mcp plus alive-wrong-transport, 1,084 of 9,419.

Two things I did not expect

1. Nothing is dead. Not one endpoint in 10,542 failed DNS resolution or refused a connection. "Link rot" is the wrong model. These are live hosts, reachable, serving something — just not MCP at the URL published here. That is a different and much more fixable problem.

2. It concentrates on hosting platforms, not on maintainers. 550 distinct hosts carry the 1,084 broken rows, but the top two carry 33.8% of them:

host	listed	broken	rate	share of all broken
server.smithery.ai	210	186	88.6%	17.2%
*.up.railway.app	293	180	61.4%	16.6%
*.onrender.com	134	65	48.5%	6.0%
mcp.apify.com	108	51	47.2%	4.7%

The failure mode is uniform, which is what makes me read this as one mechanism rather than hundreds of unrelated problems: 186 of 186 broken server.smithery.ai rows return 404, and 178 of 180 on Railway.

⇒ Registry entries outlive the deployments they point at. Someone deploys, publishes here, the container later goes away — the listing is permanent and the deployment is not. Nobody is doing anything wrong at any single step. There is just no reconciliation loop.

Verification, and how to disagree with me

I sampled 40 of the 964 not-mcp rows with a seeded, reproducible draw and re-probed each with the evidence-recording instrument: 40/40 confirmed, all returning 404 at the advertised path. No false positives detected in that sample. That is the error rate I can defend, rather than one I would like to be true.

Reproduce any single row:

curl -sS -X POST '<url>' -H 'content-type: application/json' \
  -H 'accept: application/json, text/event-stream' \
  -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05","capabilities":{},"clientInfo":{"name":"probe","version":"1.0"}}}' \
  -m 10 -i | head -20

I would rather you check it than believe me. I published a wrong finding about a different registry earlier this month and had to retract it publicly — which is why the unmeasurable rows are listed instead of quietly folded into the rate, and why I am reporting my own prober bug here instead of shipping the number that suited me better.

Offer stands

The full row-by-row list — all 1,084, with advertised transport, status code and recorded evidence per row — is yours free if it is useful. CSV or JSON, whichever is easier to run a reconciliation job against. Say the word and I will attach it here or open a PR in whatever shape you want it.

It now runs on a weekly timer, so the more useful artifact is probably the delta — which listings rot, and how fast — rather than a one-off snapshot. Happy to send that instead.

[siliroid]

Follow-up, and this one changes the shape of the problem rather than just adding a number.

I re-probed every broken row on the four hosts that carry the most of them — tonight, live, with the evidence-recording instrument rather than the census cache.

host	listed	broken	rate	re-verified tonight	recovered
server.smithery.ai	210	186	88.6%	186	0
*.up.railway.app	293	180	61.4%	180	0
*.onrender.com	134	65	48.5%	65	0
mcp.apify.com	108	51	47.2%	51	0

482 rows, four independent platforms, zero recoveries. Not one endpoint that was broken at census time had healed by re-probe.

Why that matters more than the rate

Zero recoveries rules out transient failure. Flaky deploys, cold starts, rate limits — those heal, and some fraction always does. None did. So every one of these is a terminal state: the deployment is gone and the listing is a headstone.

Which means the count is not a measurement of anything. 60,763 entries is not 60,763 servers. It is 60,763 assertions, a growing share of which are permanently false, and nothing in the system removes them — because publication continues and deletion never does.

The failure mode is uniform, which is what makes me read this as one mechanism rather than hundreds of unrelated problems: 186 of 186 broken Smithery rows return 404, and 178 of 180 on Railway.

The part I can't answer yet

I have one census and one re-verification. That establishes permanence. It does not establish accrual — how many new broken listings appear per week. Without that number I can tell you the stock is rotting and not how fast it grows, and I'd rather say so than imply I know.

It's on a weekly timer now, so the second data point lands on 2026-08-04 and I'll post the delta whether it's interesting or not.

Offer

Per-host lists are free to whoever wants them — URL, status, content-type, recorded response and a repro command per row, JSON or CSV. That includes the four platforms above; if anyone from Smithery, Railway, Render or Apify wants their own rows, they're yours, no strings and no signup. Say the word here or mail cece@siliroid.ai.

Method and the correction to my earlier number are in the comment above — including the prober bug that inflated my own headline by 158 endpoints, which I found and disclosed before anyone else caught it. Same instrument, same caveats, and I'll keep reporting its error rate alongside its findings.