We probed 920 public MCP servers with a GET — 80% returned nothing, but most aren't dead

Name: Public MCP server liveness census (2026-06)
Creator: SaSame
License: https://opendatacommons.org/licenses/by/1-0/

Open data + reproducible method · 2026-06-18 · corrected 2026-06-21 · SaSame

Update — 2026-06-21 (please read before citing the 80%): The headline number below is from a GET-only probe, which is the wrong tool for MCP — servers answer over POST / JSON-RPC. We followed up with a proper POST/JSON-RPC audit on the servers we had flagged as empty, and found that ~70% of our "ghost" flags were probe artifacts, not dead servers: the server was validating input (a sign of health, not a ghost), we had only probed its first tool, or it was a working tool fed our trivial test input (e.g. a renderer that faithfully returned "test" → "test"). In that re-audited sample, genuinely empty servers were roughly 1–3%, not the majority. So read 79.7% as "invisible to a casual GET crawler," not "dead." We are publishing this correction because being wrong in public and fixing it is the whole point of an open observatory.

We index public MCP (Model Context Protocol) servers from the registries agents are told to discover tools from, and probe each one with a polite, GET-only liveness check. This is the honest result across 920 distinct public MCP servers — followed by the correction above, which you should weight more heavily than the headline.

20.3% returned real content to a GET. 79.7% did not — see the correction.

Result	Count	Share
Returned real content to a polite GET probe	187	20.3%
Returned nothing to a polite GET (error / empty / or needs a POST/JSON-RPC handshake — not necessarily dead, see update)	733	79.7%
Total probed (distinct servers)	920	100%

"Registered" is not "reachable to a casual crawler." A server listed in a registry but returning nothing to a discovery GET is harder for agents to find and trust — even when, as the correction shows, it is actually alive over POST.

Coarse quality grade (a separate axis from the content check): A 110 · B 140 · C 644 · D 26. Note: our anti-ghost grading criterion has since been hardened (multi-tool sampling; input-validation and trivial-test-input no longer count as "ghost"), so these grades are being re-computed by our continuous observatory.

The full per-server data is open: mcp-census-2026-06.csv (url, grade, returns_real_content, audited_at for all 920). Treat returns_real_content=false as "no content to a GET," per the correction above.

What the check means (so you can falsify it)

Population: public MCP servers indexed from public registries. The 920 is the audited subset of a larger indexed ledger.
Headline probe: a single polite GET-only request. We never authenticate, never pay, and skip priced/x402 endpoints. Rate-limited (~1 / 1.5s). A GET is a weak liveness signal for MCP, which is exactly why the correction re-probed over POST.
returns_real_content = true means a non-trivial real response body to the GET at probe time — not an error, not empty, not a placeholder. false does not mean dead (see update).

Honest caveats (read before citing): This is a snapshot (2026-06-18, corrected 2026-06-21). Many servers counted as "nothing to a GET" are temporarily down, behind auth we did not pass, or simply expecting a POST/JSON-RPC initialize handshake — so this is "no real content to a polite GET," not a claim that 80% are permanently dead, and our follow-up POST audit confirms most are alive. It is, however, what a casual discovery crawler sees. The grade is our own heuristic, not a standard. And we have an interest here — we help with MCP discoverability — which is exactly why the raw data and method are open. Re-run it and tell us if we're wrong; that is how we found and corrected the 70% ourselves.

If your MCP server is registered but isn't getting discovered or called, that is the exact thing we diagnose at SaSame — with a proper POST/JSON-RPC audit, not a GET. The free check is real.

SaSame · srl-sasame.com · data CC-BY · method reproducible (see the report repo) · corrected 2026-06-21