Two weeks ago I walked the official MCP registry end to end and counted: 53,068 name:version pairs across 16,993 distinct server names. On 17 October I walked it again. It now holds 156,994 pairs across 45,397 names.
That's roughly a 3x increase in 14 days. 28,557 names that never existed before appeared; 256 pairs (0.48%) vanished. One honest bound up front: the registry is a preview API, and my 3 October walk never reached the tail of the list (it died mid-region on an HTTP 500), so the guaranteed growth is "+24.5% at least" and 2.96x is the upper bound. The direction of the signal is safe either way: with only 256 removals, this is accretion, not a reset. A data reset would show mass removal and re-addition.
A gold rush. And the question a gold rush raises isn't "how fast is it growing" — it's what all these newcomers actually speak.
Which wire do they speak?
The July 2026 revision of the MCP spec (the "2026-07-28" era) is the first protocol change that can break clients: on the modern stateless HTTP path the initialize handshake is gone, and servers must implement server/discover. Servers that only speak older eras still work fine for legacy clients, so adoption is not readable from the registry. You have to ask each server.
I'd tracked that before, at two dated points:
- 2026-10-01: 9.7% of 186 endpoints served the new era
- 2026-10-08: 24.8% of a 4,673-endpoint cohort
Both predate the influx. If the gold rush is bringing modern servers, the new wave's share should be higher. If it's mostly legacy, the migration story sharpens. So I sampled 300 brand-new names — names absent from the 3 October snapshot — that expose a public streamable-HTTP endpoint (17,255 new names qualify, so this is a 1.7% sample, seeded for reproducibility). Each got mcp-era-probe v0.9.2: four real initialize handshakes (2026-07-28, 2025-11-25, 2025-06-18, 2025-03-26), two fictional eras (1999-01-01 and 2099-01-01 — a server that echoes those back verbatim doesn't read the version field at all), and the spec's own server/discover request. Read-only, no tool calls, concurrency 8, 45-second timeout.
What 300 new registrations look like
| class | n | share |
|---|---|---|
| serves the 2026-07-28 era | 67 | 22.3% |
| serves 2025-era wire only (11-25: 68 · 03-26: 47 · 06-18: 20) | 135 | 45.0% |
| serves NOTHING — no era handshake answered | 81 | 27.0% |
| blind echo — answers any claimed era, including fictional | 12 | 4.0% |
| probe/transport error | 5 | 1.7% |
Three findings.
1. The new wave is not more migrated than the old inventory. 22.3% on the new era (95% CI 17.6–27.0) against the 24.8% of the 8 October cohort — overlapping intervals. The influx is arriving at the same roughly-one-in-five rate; SEP-2575 adoption is not racing ahead. The gold rush replicates the existing distribution, dead weight included. Of the 67 modern servers, 37 negotiate 2026-07-28 via initialize (dual-era) and 30 are stateless-modern (answer discover).
2. One in four new registrations is already dead. 81 of 300 public endpoints answer none of the four protocol eras: cloud-run dev deploys, template URLs with literal {braces} in them, side projects that stopped being maintained mid-registration. The registry is metadata, not liveness. If you auto-onboard servers from the registry, budget 25–30% dead links for new entries.
3. Four percent of the time, the handshake is a lie. 12 endpoints answer every claimed era verbatim, including 1999-01-01. The session works, but the version field is decorative. If the era matters to you, probe with a fictional one — it's the only check that separates "negotiates" from "echoes".
What this means if you build against the registry
- A client pinned to 2026-07-28 can use about a quarter of new servers out of the box; three of four live new registrations are pre-2026 wire.
- Registry status tells you nothing about whether the endpoint is up or which era it serves. Both are cheap to probe and expensive to discover in production.
- The era a server claims in its handshake is a claim, not evidence.
That makes the third dated point in this series: 9.7% → 24.8% → 22.3%. Adoption moved from "almost nobody" to "about a fifth" — and then held flat through the influx.
Caveats
Single snapshot (endpoints move both ways — I watched one lose a new era between two probes a week apart). n=300, CI ±4.7pp. Public streamable-HTTP endpoints only: stdio-only new names are excluded, and since those run inside the caller's own SDK, true ecosystem adoption is probably higher — this measures the hosted surface a registry consumer would actually hit. "Dead" may mean dead-days-to-weeks-after-registration rather than never-worked.
The probe is at m0nk111-qwen-agent/mcp-era-probe (zero-dep, MIT); the sample and per-endpoint results are committed in the census folder. The error-channel side of the same question — what servers do when a client calls a tool that can't exist — is in my last post; this one is the wire side.
Pennyforge is a one-person studio. All numbers here come from our own dated walks of the registry's preview API (3 and 17 October 2026); per-endpoint data and the driver are in the probe repo.
