There’s a number going around the MCP ecosystem: half of all MCP servers are dead. Audits of community-indexed servers report 52% abandoned, install-failure rates of 30–50%, and a long tail of weekend projects that never got a second commit. We wanted first-hand data instead of a retold statistic — so we probed the official MCP registry ourselves.

Method: on July 29, 2026 we sampled 600 entries from registry.modelcontextprotocol.io (the first six pages of the API, alphabetical). 516 of them declare a remote (streamable-HTTP) endpoint. We sent each one a real MCP initialize handshake — the same live probe every server in our directory passes before listing — with an 8-second timeout, and classified the responses.

The result: 94% of registry servers are alive

  • 75.8% answered the MCP handshake outright — a valid JSON-RPC response, no auth required to say hello.
  • 18.0% responded with a proper OAuth challenge (401 + WWW-Authenticate) — alive and correctly gated.
  • 2.9% were genuinely dead: unreachable, 404, server errors, or a marketing page where an MCP endpoint should be.
  • The remaining ~3% answered oddly (redirects, non-MCP JSON) — reachable, but not cleanly speaking the protocol.

That is not a dying ecosystem. That is a 93.8% liveness rate — far from the 52%-dead picture.

Both numbers are true. That’s the actual finding.

The 52% figure comes from scans of the scraped, auto-indexed corpus — the 20,000–60,000 “servers” counted by directories that index every GitHub repository with MCP in the README. That population is full of abandoned experiments, and scanning it honestly yields carnage. The official registry is a different population: opt-in, namespace-verified, and young enough that abandoned projects haven’t piled up.

Which means the real quality crisis in MCP is not server rot — it’s discovery source. The same ecosystem looks 94% alive or 48% dead depending on where you look. If your client, your directory, or your agent picks servers from the scraped long tail, you inherit the graveyard. If it picks from verified, live-probed sources, you mostly don’t.

What liveness doesn’t tell you

An honest caveat: our probe measures whether a server answers, not whether it’s any good — or safe. A handshake says nothing about tool quality, prompt-injection surface in tool descriptions, permission scoping, or whether the server quietly changes its tools next week. Liveness is the floor, not the bar. That’s why the gate directory holds servers to more than a pulse:

  • Live-probed — a real MCP handshake at listing time, re-checked continuously, with the probe date shown.
  • Provenance — official vendor endpoints, clearly distinguished from community builds.
  • Auth hygiene — honest labels for how a server actually connects (OAuth, API key, open), including when a vendor restricts third-party clients; no “one-click” promises that die on the vendor’s error page.
  • Security scan — tool descriptions checked for prompt injection and hidden instructions before listing (try it on any server).
  • Drift detection — if a server’s tools change after you connect, you hear about it.

What this means if you're building or choosing

If you’re choosing servers: prefer sources that verify liveness and provenance over sources that maximize listing counts — a 20,000-server directory that indexes GitHub is quietly a coin-flip. If you’re shipping a server: get into the official registry (namespace verification is real signal), keep your endpoint stable, and implement standard OAuth — in our probing, non-standard auth is the top reason an otherwise-healthy server fails to connect from real clients. And if you’re running servers for a team, put them behind a gateway that re-checks them for you — liveness, like trust, decays without monitoring.

We’ll re-run this probe periodically and track the trend — the interesting question is whether the registry stays healthy as it grows past the point where anyone is watching.