The MCP Registry Grew 170% in Twelve Weeks. We Also Found Out 89% of Our Own Change-Feed Was Noise.
- Patrick Duggan
- 34 minutes ago
- 4 min read
We track the Model Context Protocol registry. Every day we snapshot it, and every day we diff today against yesterday and write down what changed. We have 81 consecutive snapshots and 3,135,987 server records.
Two things came out of actually looking at them. One is a number nobody else is publishing. The other is us being wrong for eleven weeks.
MCP is growing faster than most people think
Servers in the registry, on the day we counted them:
2026-05-02 — 21,962
2026-06-01 — 31,484
2026-07-01 — 44,267
2026-07-27 — 59,417
That is +170% in twelve weeks, roughly 460 net new servers a day, and it grew on every single observed day. No plateau, no dip, no consolidation. Whatever you believe about whether MCP is a good idea, the install base is not waiting for you to decide.
For a defender that number is the whole story. Every one of those servers is a thing your agent may be told to trust, and the population it can be told to trust is compounding weekly. The attack surface is not a fixed set you can review once.
Now the part where we were wrong
Our change-feed index holds 207,374 findings. 184,896 of them — 89% — say a server was removed.
We had been carrying that number without interrogating it. Put it beside the growth curve and it falls apart instantly. During May 4–10 the differ logged roughly 7,000 removals a day against a population of about 22,000 that grew every day of that week. You cannot shed a third of a registry daily while expanding. The events are not real.
The mechanism turned out to be mundane and entirely our fault. Our registry ingest runs at 02:05 UTC; the differ runs at 02:40. If the ingest is slow or incomplete at that moment, every server not yet written looks present yesterday, missing today — so the differ dutifully records thousands of removals that never happened.
The evidence is sitting in our own series. On June 16 our snapshot returned 29,500 servers against a trend line of about 38,000 — a 22% shortfall — and recovered to 38,517 the next day. That is the failure caught in the act. There are missing crawl dates too: May 10, May 12, May 15–17, June 24.
Today the same job produced 4 removals out of 18,522 servers — 0.02%. That is what a healthy day looks like. The difference between 0.02% and 12% is not threat activity. It is whether our own crawl finished.
What we shipped
A guard. If removals exceed 2% of yesterday's population, the job now refuses to write them, emits a single auditable crawl_anomaly record instead, and makes the run loud about it. Every other finding type still writes normally, and the threshold is environment-tunable for the day a genuine mass-delisting actually happens and we want the raw data.
There was already a guard in that code for an old pagination bug. There was no guard for a partial crawl — which is the failure that actually occurs. That is usually how it goes: the defended failure is the one you already had, and the live one is the one nobody wrote a check for.
We verified both directions before shipping, because a guard you have only seen stay quiet is not a guard you have tested. Inert on a healthy day at 0.02%. Forced to trip, it dropped the phantoms and left exactly one record behind.
The detector that has never once fired
While we were in there we found something we are not going to quietly fix.
The same job is supposed to detect rug pulls — a server that silently rewrites its tool description while keeping the same version number. That is the fingerprint of tool poisoning: the agent re-reads a description it already trusted, and the description now says something else. It is the single most important thing this job could catch.
Across all 81 snapshots it has emitted zero rug-pull findings. Zero silent-remote findings too.
So we measured whether it can fire. On two consecutive live days we compared every server present in both: 982 overlapping servers, 970 of them at an unchanged version. Description-hash changes among those 970: none.
The registry is versioned. A description edit ships as a new version. The condition "description changed while version stayed the same" may be structurally unreachable in this data model — which means that zero does not mean we looked and found no rug pulls. It means we cannot look.
Those are entirely different claims, and the gap between them is where security products go to die. A dashboard reading "0 rug pulls detected" is indistinguishable from a working detector right up until someone asks what it would take for the number to be anything else.
We could have made it fire by loosening the condition. That would have been manufacturing a signal. Instead it is documented in the code as a known-unreachable check, and real tool-poisoning detection goes on the list as what it actually is: a cross-version description diff with a judged delta, which is a different and harder piece of work.
Why publish our own broken number
Because the alternative is worse. We publish other people's measurement failures fairly regularly. An outfit that does that and quietly deletes its own is running a marketing operation, not a research one.
And the honest version is more useful than the flattering one. "We track 207,374 MCP findings" was a bigger number. "We track roughly 22,000 real ones and we just threw out 185,000 that were our own crawl talking to itself" is a number you can actually build on.
The growth figure is the one to take away: 21,962 to 59,417 in twelve weeks. That one we checked twice.
Method: 81 daily snapshots of the MCP registry, 2026-05-02 through 2026-07-27, 3,135,987 server records and 207,374 diff findings, queried directly. Counts are exact facet distributions, not estimates. Growth is measured on distinct servers per snapshot; the overlap test sampled 1,000 servers across two consecutive days.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.