State of the MCP Registry

An independent, measured snapshot of the official Model Context Protocol registry. Data current as of 2026-07-30 to 08-02. Numbers are from live probes, not estimates.

How much of it actually works

46% of the 7,676 distinct operators behind 10,716 active remote endpoints answer an anonymous MCP handshake (43% counting endpoints but excluding the single largest host).

Correction, 2026-08-24. This headline read 50% until today, counted per endpoint. Endpoints are not independent: the 10,716 of them are only 7,676 hosts, and gateway.pipeworx.io alone is 1,286 of them. In this 07-30 census every one of them was healthy, so it could not raise a failure count and instead inflated the healthy denominator — we were overstating how much of the registry works. The honest figure is 43–46% depending on how you de-bias, and the two methods disagree here where they agree elsewhere — so read the span, not a point. The per-endpoint breakdown below is unchanged and still counts endpoints. Full working.

Correction to the correction, 2026-09-08. The paragraph above said of gateway.pipeworx.io “every one healthy” as though that were a standing property of the host. It was a fact about the 07-30 census only, and it is no longer true — our own daily probe has contradicted it since 2026-08-27, 17 sound probe days during which this page went on asserting it. In the fixed 400-endpoint cohort that gateway is 97 paths, and it answered 100.0% of them on every sound day from 2026-08-10 to 2026-08-26. Since then: 48.5% on 2026-09-07, 95.9% on 2026-09-15, against 84.8% for the other 303 endpoints the same day. The de-biasing above still stands — those paths are one operator however they behave — but its stated reason was wrong: a concentrated host does not only shift a level, it manufactures variance. Full working.

The widely-repeated claim that "half of MCP is dead" traces to an April 2026 study of a broader, wild-crawled population. It does not describe the curated registry today: only 19% are genuinely dead.

Failure concentrates by hosting platform

Reachability tracks whether the hostname was ever meant to be permanent, not code quality.

Correction, 2026-08-24. The last two columns are new. Read across them before quoting a row: smithery.ai’s endpoint rate is high because 216 of its 217 registry endpoints are one host, server.smithery.ai, whose advertised paths mostly 404 — that is a registry-hygiene fact about listings on a shared gateway, not a durability fact about a platform, and its per-host column says so. The rows backed by hundreds of distinct hosts (railway.app, workers.dev, vercel.app) move by under four points and are the ones worth acting on. Working: the correction on the hosting write-up.

Protocol adoption

86% run the current protocol. The ecosystem is newer than it is abandoned.

The tool surface

8,639 tools across a random sample of 476 live servers (≈194,480+ ecosystem-wide). Only 18% declare an output contract — the rest return whatever they return. 24% of operators expose at least one tool pair an agent could plausibly confuse (corrected 2026-08-04, was 46% — that figure counted URLs, and one vendor's gateway accounted for 97 of the 400 sampled).

Read this section as describing anonymously-reachable servers, not the registry. These figures come from the pre-2026-08-02 sample, which was drawn from servers that answered anonymously on 7/30. See What our own sample was getting wrong below for how large that distortion is — substantial for reachability, small for the schema-declaration rates quoted here.

Contracts drift, and it clusters

4.4% of servers changed a tool contract within 36 hours; only 3 more in the next 36. A server can be perfectly up and no longer do what your agent learned it does.

Correction, 2026-08-02. This section previously read “a small set of servers that never stop moving, plus a frozen majority.” That over-claims what two 36-hour windows can show. Quiet across our windows is quiet; frozen is a much stronger claim, and we cannot distinguish a server that never moves from one that moved before our first snapshot. If drift is bursty per server rather than steady, 21-then-3 is the shape you would see even if no server were permanently stable. The numbers are unchanged; the interpretation was wrong. Raised by @anp2network.

What our own sample was getting wrong

Until 2026-08-02 every tool-surface figure here came from a sample drawn from servers that answered an anonymous handshake on 7/30 — a survivor set, presented as a sample of the registry. A reader (@anp2network) pushed on the sampling and we went looking. We now probe two cohorts every run and never merge them.

Correction, 2026-08-24. These four rows used to be reported pooled across every tool, which counts one operator once per URL path it advertises. In the CURRENT cohort gateway.pipeworx.io alone is 1360 of 4506 tool instances (30.2%), so the pooled figure largely described one vendor's gateway. The per-operator rates above give every operator one vote; the pooled pair is kept on the third row so the size and direction of the difference stay visible. Working: the same correction on the article these figures came from.

The reachability gap is structural rather than decay: CONTROL was defined as servers that answer anonymously, so it cannot contain the auth-gated half of the registry. Schema hygiene also separates the cohorts — 16.6% against 9.9% (7100 vs 4506 tools across 350 vs 258 servers; clustered by server, p = 0.01). Selection bias is not one number you apply to a dataset. On this run the selection moves the schema-declaration rate as well, so the output-contract figures should be read per cohort and not as a registry-wide rate either.

When a server moves, does the new address work?

The registry deletes almost nothing — of 10,716 URLs censused on 7/30, exactly one was removed within three days. The rest of the churn is supersession: the same server name publishing a newer version at a different URL. It is tempting to read that as servers moving rather than dying. So we probed both ends of every superseded pair on 2026-08-03.

56% of superseded servers’ new endpoints answer tools/list — against 54% for a fresh random draw from the registry the same day. A migrated server is not measurably more likely to work than any other entry.

42% are dead at both ends. The registry shows a tidy migration to a live-looking entry and nothing at either address answers. Registry freshness is not a health signal: a server that just cut a release and updated its entry is a project someone touched recently, and that does not predict a working endpoint.

Correction, 2026-08-03. We previously wrote that what a naive diff reads as dead servers is mostly servers that moved. They moved in the registry; 42% of the time the place they moved to is dead too. “Superseded” describes a database row, not a server that went on working somewhere else. The claim that the registry deletes essentially nothing stands unchanged — that was about bookkeeping, and the bookkeeping is accurate.

One caveat we cannot design away: successors are resolved through the registry’s name field, which is authored by the same operator whose endpoint broke. The stronger witness is contract continuity — does the new endpoint serve the tool set the old one did — and we hold a pre-move contract for only 4 pairs, far too few to quote as a rate. Raised by @anp2network.

The data

Every figure above comes from files you can download and re-walk. A claim about our own carefulness is worth less than an input a stranger can check.

• census-2026-07-30.json — the full-registry sweep, all 10,716 URLs with health class and status.
• successor-probe-20260803.json — every superseded pair, both ends probed, plus the raw result for all 1,217 URLs.
• method and known limits.

Correction: self-hosted template URLs (2026-08-03)

Self-hosted servers publish registry URLs the deployer fills in (https://{coder_hostname}/..., myPlatform.jfrog.github.io). Those entries are correct and are supposed to fail a probe — but our census counted them as broken. Strictly matched, 97 of the 2,039 entries we classed broken are templates (0.91% of the registry), so our broken figure is overstated by that much: 19.0% becomes 18.1%, and the headline "about a quarter unusable" becomes ~24.5%.

The error is small in aggregate and concentrated exactly where it hurts: templates are how self-hosted enterprise software ships, so the false positives cluster among the best-known projects. Fixed in the probe — templates now class as self_hosted_template, and auth codes (401/403/402/429) count as alive.

The raw data

Every figure on this page comes from one file, and the file is here: census-2026-07-30.csv — all 10,716 URLs, 1.4 MB. One row per endpoint: the URL, its host, the raw probe class, the HTTP status, which bucket we put it in, whether we flagged it a self-hosted template, and its registry status as of 2026-08-02.

This is published because a reader has no way to tell a number that was corrected under pressure from one nobody ever checked. Our corrections are real, but "trust our discipline" is not evidence. The file is. Re-derive anything here, or disagree with how we bucketed it — the probe_class column is the raw observation and bucket is our interpretation of it, kept in separate columns precisely so you can throw ours away.

The rest of the corpus — $39

The file above is the 7/30 snapshot, and it stays free. What it does not contain is everything we kept measuring afterwards: the daily reachability drift series (400-endpoint samples drawn fresh from the live registry since 2026-08-02, published nowhere else), a fresh re-probe of the full registry run within 72 hours of purchase so your copy is current rather than archival, structured JSON of all of it plus the superseded-endpoint successor analysis, a data card stating method and limits with the full corrections log, and a single-buyer commercial licence with attribution. $39, one payment.

Two other public censuses of this registry now exist, and you should know that before you buy. Fetchgate probed 15,329 registry URLs on 2026-08-27 and publishes per-server results free under CC BY 4.0; mcpqueen publishes a free CSV monthly. Both are larger and fresher than our 7/30 snapshot. We read them as corroboration rather than rivalry — their 22.7% “dead, broken, or not MCP” lands 0.7 points from our 23.4% unusable, on a different population a month later, which is the strongest evidence on this page that the method measures something real. Where we are actually alone: transport decay measured per transport (legacy sse 42.3% dead against streamable-http 6.1% — Fetchgate records its 141 SSE-only URLs as skipped) and operator-level dedupe (7,676 distinct operators behind the endpoints). If those two are not what you need, take one of the free datasets; we would rather you did than buy the wrong thing.

Check your own server, free

Paste the URL clients connect to. We send one real anonymous initialize from outside your network and tell you what a stranger sees — the same probe used for all 10,716 entries on this page. Nothing is stored.

Working with us

We probe every server in the official registry on a schedule, publish the numbers, and publish our corrections when we get them wrong. Four ways to use that, from free upward:

Two findings that apply to nearly every server we measure, free to act on: 21% of the 168 operators we surveyed declare an outputSchema on their tools (it was quoted here as 16.8% of pooled tools until 2026-08-24, a figure one gateway dominated), so callers mostly cannot predict return shape; and 16.2% of answering servers negotiate a protocol older than 2025-06-18 — which fails silently, because the handshake still succeeds.