"In the Registry" Is Not "Runs"

The official MCP registry is the catalog everyone points their agents at — the Anthropic/GitHub/Microsoft-backed list of Model Context Protocol servers. Browsing it, you'd think you have hundreds of tools a npx away. We wanted to know how many of those listings actually turn into a working server on your laptop. So we pulled the whole thing and measured the drop-off — no models, just registry JSON, package lookups, and a fixed handshake over stdio.

The funnel is steeper than the catalog's size suggests.

The numbers

mcpfunnel — 306 unique servers in the official MCP registry

  composition:
     256   83%  remote          (hosted HTTP endpoints)
      32   10%  npm   (installable, stdio)
      12    3%  pypi  (installable, stdio)
       4    1%  oci
       2    0%  other

  ● 44 of 306 (14%) ship an installable package — the rest are remote-only (hosted)

  install -> boot funnel (44 installable servers, no config):
      44  installable
      44  resolve on npm/PyPI   (0 dead pointers)
      21  complete a tools/list handshake out of the box   (23 didn't)

  ● only 47% of installable registry servers completed a handshake with no configuration.

Two findings fall out, and they're different from what we expected.

First: the registry is mostly remote. 84% of the listed servers aren't packages you install — they're hosted HTTP endpoints (streamable-http URLs). The mental model of "MCP server = a thing you npx and run locally" is already the minority case. Only 14% (44 of 306) ship an installable npm or PyPI package. That's a real shift in what the ecosystem is: it's becoming a directory of hosted services, not a package index. Worth knowing before you architect around "just run it locally."

Second: of the ones you can install, fewer than half boot clean. All 44 installable packages resolve — no dead pointers, which is good and says the registry validates that the package exists (unlike, say, slopsquatted names that 404). But existence isn't function. When we launched each one and sent the standard MCP initialize + tools/list handshake, only 21 of 44 (47%) completed it with no configuration. The other 23 started and went silent, or never started, or hung until our timeout.

The honest part of that 47%

Here's where most "X% of things are broken!" posts overreach, so let's be precise. A server that didn't complete our handshake is not necessarily broken — a lot of them need a credential in the environment (an API key, a database URL) and exit early without it. Our test gives them nothing, on purpose, because we're answering a specific question: if a user follows the registry listing and just runs it, does it work? For 47%, yes. For the rest, "it depends" — and the registry listing rarely tells you which.

That distinction is the actionable bit. mcpfunnel reports the split (no-handshake vs no-start vs timeout) so you can tell a server that needs an API key from one that's genuinely dead, rather than lumping them together. The honest headline isn't "half the registry is broken" — it's "half of the installable registry runs out of the box, and the listing won't tell you which half."

How it works

mcpfunnel is deterministic end to end:

1. Pull the registry (paginated JSON, deduped to the latest version per server).
2. Classify each: remote, npm, pypi, oci, other — from its packages/remotes metadata.
3. Resolve each installable package against registry.npmjs.org / pypi.org (a 404 = dead pointer).
4. Handshake: launch it with npx/uvx, send initialize then tools/list over stdio with a per-server timeout, and bucket the outcome.

No LLM is involved at any stage — the MCP handshake is a fixed request/response, so every number here is reproducible. The composition pass runs against a saved registry snapshot in milliseconds (--registry snapshot.json); the boot funnel is --boot (slower, since it actually launches servers), and you can replay a saved run with --funnel-results. --json for dashboards.

Prior art, credited: NimbleBrain analyzed the registry and found ~20% of servers can't be packaged at all — but they measured packageability (metadata completeness) and curated by hand. The install→boot→handshake funnel — does the thing actually start and speak the protocol — is the gap we filled, as one reproducible script.

Why this matters

When you add an MCP server to an agent, you're trusting a listing. The reflex is to assume "official registry" means "vetted and working." What the funnel shows is that the listing is a pointer, and the pointer's reliability degrades at every step: 84% aren't local at all, and of the local ones, half need work before they run. None of that is a scandal — it's an early ecosystem doing early-ecosystem things — but it changes how you should onboard a server: pin the version, smoke-test the handshake, and check whether the silence means "needs an API key" or "abandoned" before you wire it into an agent and let it fail mid-task.

mcpfunnel automates exactly that smoke test. Run it on the servers you're about to depend on.

Single file, no dependencies. → Talk to us if you're standing up MCP servers in production.

---

Registry pulled live 2026-06-20 (306 unique latest servers; the snapshot + the boot-funnel results are included for reproducibility). The 47% is "completes a handshake with no configuration" — not "is functional"; mcpfunnel reports the no-start / no-handshake / timeout split so credential-gated servers aren't miscounted as broken. Counts are exact; the handshake is deterministic.

---

Get the tool → mcpfunnel in agent-ops — open source (MIT), a single dependency-free script, part of our toolkit for running coding agents in production.