You may have seen the claim that roughly half of all MCP servers are dead. It gets repeated every time the official registry comes up. I wanted a real number, so I inspected the entire official MCP registry and ran a health check against every server in it: 14,559 servers, checked on 2026-07-02, without a single API key.
The fully-dead rate is 4.1%.
Here is the complete verdict distribution:
| Verdict | Count | Share |
|---|
| Healthy | 11,582 | 79.6% |
| Degraded | 2,212 | 15.2% |
| Dead | 596 | 4.1% |
| Unknown | 169 | 1.2% |
So the honest summary is: about 1 in 5 servers is dead or broken in some way, and only about 1 in 25 is fully dead. That is a real quality problem, but it is nowhere near half, and the gap between the myth and the measurement matters if you build on this ecosystem.
The interesting part is where the failure hides
A single aggregate number conceals the actual structure. An MCP registry entry can point at up to three kinds of things: packages (npm, PyPI, OCI images), a source repository, and hosted remote endpoints. When I broke the failures down by layer, they were not evenly spread at all.
Packages are the reliable layer. Across npm, PyPI, and Docker Hub, only about 1% of declared packages are broken. If a server ships as a package, the artifact you install almost always still exists and resolves.
Repository links rot. 13.8% of declared GitHub repos are 404, gone, or archived. The code may live on inside a package, but the front door you would read before you trust it has fallen off.
Hosted remotes are the fragile layer. The registry declares 7,158 remote endpoints, and 13.6% of them are down. Worse, servers that declare a remote are the sickest cohort overall: 25.9% dead-or-broken and 7.5% fully dead, versus 4.1% dead across the whole registry.
That inversion was the "huh" moment for me, I expected abandoned packages would be the graveyard. They are not. The static artifacts are nearly immortal; what decays is anything that needs someone to keep a process up, a domain paid, and a TLS cert current. A hosted endpoint is a promise that renews monthly. A tarball on npm is a fact.
Two smaller findings round out the picture. On the sloppy end, 2.1% of servers publish a server.json that fails the JSON Schema it declares for itself, a pure conformance bug and trivially fixable. On the strong end, 3,719 servers complete a full MCP session with the checker: they answer initialize and return their tool list. That handshake is the strongest proof a server actually works that you can get without credentials.
Why this matters when you pick a server
The registry cannot tell you which cohort a listing belongs to. A server whose npm package installs cleanly and a server whose remote endpoint is down look identical on their registry pages. If you wire a remote MCP endpoint into an agent today, you draw from the cohort where roughly 1 in 4 is dead or broken, and nothing in the listing warns you.
One honest caveat: this is a single census with one check date, 2026-07-02. It is a snapshot, not a trend line, and it measures health and protocol conformance only. It says nothing about security or code quality.
How I checked
The census is reproducible with the tool that produced it: Akashi, a keyless MCP health checker (a single static Go binary, MIT). It reads only public signals: the MCP registry, the public GitHub API, npm, PyPI, anonymous Docker Hub, and a capability-only MCP initialize / tools/list handshake. It never authenticates to a probed server and every row in the dataset is a claim you can re-derive on your own machine:
akashi check <registry-name | github-repo-url | remote-url>
The check rolls up to one verdict, healthy, degraded, dead, or unknown, and Akashi can emit a shields.io badge stamped with the check date.
The full dataset is CC-BY at github.com/RoninForge/state-of-mcp, with a browsable index and one dated page per server at roninforge.org/data/state-of-mcp. If you maintain a server, checking your own listing is one command, and it tells you which layer to look at first.
curl -fsSL https://roninforge.org/akashi/install.sh | sh
akashi check your-server-name
