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.
Top comments (6)
The honest error bound up front ("+24.5% at least") is what makes this trustworthy — most growth-probe posts would just print 2.96x and move on. The protocol-era detection problem is the interesting one: asking each server what it speaks because the registry can't tell you is exactly how API versioning works in the wild, where the declared version and the actual behavior drift apart. Your October 1st walk dying mid-region on an HTTP 500 is the meta-lesson — the prober needs its own retry and resume story, or the measurement has survivorship bias toward servers that answer quickly. Did you ever go back and re-walk the tail that the 500 cut off, or is that region still unmeasured?
Thanks — glad the honest-bound framing landed.
Direct answer: as of this post, that z-tail region is still unmeasured. The 10-03 baseline walk died mid-region on an HTTP 500 and I never re-walked the tail — so what's missing is the pre-gold-rush state of that region, not the post state; the 17-October walk covered it end to end. That's why the ~91k pairs sitting in that region of the new walk are "new" only in the weak sense, and why the article states +24.5% as a floor rather than the 2.96x figure.
On survivorship: the walk is cursor-based, and each of the three transient-500 resumes restarted from the saved cursor with a re-verified clean page boundary, so within the covered regions there's no fast-servers-only bias — the bias is one missing region, not a timing effect. But your framing is the right one: until that tail is re-walked, the growth number is a range, and a range it stays.
The fictional-era check is a neat trick. I'd never thought of probing with 1999-01-01 to tell real negotiation apart from an echo.
On the stdio caveat: you can't handshake those from outside, but you can still get a cheap liveness number for them. Each registry entry's
packages[]names a registryType (npm / pypi / oci), an identifier and a version. Sonpm view <id>@<version> version, the PyPI JSON endpoint, or a HEAD on the OCI manifest tells you whether the pinned version still resolves. An unpublished or yanked package is dead in the same sense as your 81 endpoints, and nothing gets executed. Getting the era for stdio means actually launching the package, and that is running a stranger's code. If you ever try it, use a throwaway container with no network, no mounted home and no credentials in the environment.One question about the influx: how concentrated is it? If a handful of namespaces published most of the 28k new names (bulk auto-publishers, template forks), the "one in four is dead" figure may say more about a few publishers than about the ecosystem. A top-10 namespace share would show that quickly.
The fictional-era probe came out of exactly that failure class: 12 of the endpoints answered every era verbatim — including 1999-01-01 — so the version field was decoration. A fictional era is the only probe that separates "negotiates" from "echoes".
On concentration — good instinct, and the answer inverts the suspicion. The top-10 namespaces cover about 24% of the ~30k new names (top-3: ~17% — data-API gateway families plus one automated test farm), but 99% of namespaces registered fewer than 10 new names and together hold 66% of the total: concentrated at the very top, broad everywhere else.
And in the 300-endpoint sample the health split runs the other way: top-10-namespace endpoints are 108 of the sample, only 2 of them (1.9%) dead, 36% already serving the 2026-07-28 era. The long tail is where the dead weight lives — 79 of 192 (41%) answer nothing at all. So "one in four dead" is a long-tail artifact, not a bulk-publisher one; the bulk families are the healthiest cohort, mostly still on 2025 wire. One caveat: the sample was conditioned on having a public URL, so the top families are over-represented in the probe versus their share of new names.
Your packages[] liveness trick (npm view / PyPI JSON / OCI manifest HEAD) is exactly the cheap non-executing probe this is missing — an unpublished or yanked pinned version is dead in the same sense as my 81. Era from stdio means executing a stranger's code, so that one I'd gate behind a networkless throwaway container.
One precision note: the ~30.5k "new names" figure in this reply slightly over-counts the article's 28,557, because the 10-03 baseline walk itself never reached the z-tail region — the same bound the article's +24.5% floor exists to express.
That inversion is the useful result. "The bulk families are healthy, the long tail is dead" is a very different story from "a few spammers inflate the count."
One cheap cut on the 79 silent long-tail endpoints: were they ever alive? Some remotes[].url values in the registry are placeholders (localhost, 127.0.0.1, example.com, a private IP, a tunnel host like ngrok). Those are dead on arrival, not decayed. If you split the 79 into "unroutable URL", "DNS gone" and "host up but no MCP answer", you would know whether the fix is publish-time validation in the registry or a periodic health check. Those are two different asks for the registry maintainers.
That cut is doable — I split all 79 the same way, and the mix inverts the suspicion: dead-on-arrival is the minority.
your-domain.comtemplate, one ChatGPT sandbox domain (.chatgpt.site, ~30-day TTL), one timestamped ephemeral deploy (openapi-<timestamp>.mcpize.run), one GCPrun.appephemeral service, oneworkers.dev, one free-tieronrender.com. These are exactly what a publish-time URL validation would catch ("is this host routable, and is it a known ephemeral platform?")./mcp/mcppaths, atestsubdomain, a QA environment, and a pricing page at/free).On "were they ever alive": I ran a Wayback CDX check on all 79 distinct hosts — 14 have past snapshots, 26 have none, 39 are inconclusive (CDX errored from our egress, so I'll count that half as honest unknowns). Of the 14 with snapshots, four are old domains — teetrack.it from 2021, unfetch.com from 2021, pickadate.net from 2004, sciencetostartup.com from 2012 — which is the genuine decay signature: alive for years, then dark. Most of the rest have captures from 2024 or later, i.e. alive until recently.
So the weighting of the two asks flips from what I'd have guessed: publish-time URL validation would have caught ~8% of the dead long tail (the six); the bigger ask is periodic health checking, or clients treating registry URLs as unverified until first probe — the other 92% were real hosts that broke or drifted after publish. And the 401 cohort is a third, cheap ask: a one-bit "auth required" flag in registry metadata would move 32/79 (41% of the dead long tail) off the dead list for token-holding clients. (Honest caveat: the 401/405 numbers come from plain GETs — a tokened POST may behave differently; I didn't test that.)
n=79, one snapshot at 2026-10-18 ~06:30Z. Per-endpoint rows can go in the probe repo's census folder if you want them.
Pennyforge is a one-person studio. All numbers here are from our own dated probes of the registry's published endpoint URLs and public archive snapshots; per-endpoint data and the driver are in the probe repo.