0 of 302: what a full census of the MCP Registry says about the 2026-07-28 revision

Why the revision matters

MCP revision 2026-07-28 moved the protocol toward a stateless design. It added server/discover, a resultType on results, cacheable results with ttlMs and cacheScope, and a new way to ask the client for input mid-call. It is not fully backward compatible. A client that negotiates the new revision against a server that only speaks the old one has to fall back. A security scanner that assumes one behaviour will misread the other.

So before writing checks for the new revision, I wanted to know how much of the ecosystem had moved. Both official SDKs shipped 2.0.0, the first release that speaks the revision, on 27 and 28 July.

Method

1. Population. Every entry in registry.modelcontextprotocol.io/v0/servers on 14 September 2026: 31,953 entries, 320 pages, 0 pagination failures. A failed page aborts the run instead of silently shrinking the population.
2. Frame. Only entries that point at an npm or PyPI package can be examined statically: 12,246 of them. Everything else is out of the frame (see below).
3. Sample. A seeded uniform random sample of 200 npm and 200 PyPI entries. Seed 2307759973. Uniform, not by download count, so popular servers aren't over-represented.
4. Fetch. Download each package's published artifact. 377 fetched; 23 failed (16 had no downloadable artifact, 5 weren't found, 2 exceeded the size cap). Failures are excluded from every n and listed.
5. Classify. An artifact supports 2026-07-28 only if it pins an SDK at or above 2.0.0 and its shipped source carries a revision feature, such as a server/discover handler. No SDK pin means unknown, never supports.

No MCP server was contacted. The census reads the registry listing and package archives from npm and PyPI, the same files npm install and pip install download.

Result

The interval is the point of publishing this. Zero out of 174 is consistent with a true share of up to about 2.2% of packaged npm servers. Zero is not "none".

A second run earlier the same day, with a different seed, found 3 npm artifacts that genuinely supported the revision. I didn't publish it because its pin detector had a bug (described below), but its 3 of 176 and this run's 0 of 174 are both consistent with a true share in the low single digits. That's what the interval is for.

Most packaged servers still pin the 1.x SDK: 166 of 174 npm pins and 113 of 128 PyPI pins. Seven weeks after release, the move to 2.x had barely started among published packages.

What this does not show

• The 18 packages that could flip the zero. Eighteen artifacts (5 npm, 13 PyPI) pin SDK 2.x but ship no handler for a revision feature in their own source. The rule needs both, so they count as does not support. But the 2.x SDKs speak the revision themselves, so many of these servers probably answer server/discover without writing a line for it. Counted as supporting, the pooled share is 18 of 302: 6.0% (95% CI 3.8–9.2%). Per ecosystem: npm 2.9%, PyPI 10.2%. The honest reading is a range, roughly 0–9% of packaged servers, and the artifact alone can't narrow it.
• The 56% that has no package. 17,897 of 31,953 entries are remote-only: a URL, no artifact to download. A static census can't see them, and this one doesn't claim to.
• Deployments. "Supports" is a statement about a published file. It says nothing about which version a server actually runs.
• Other package types. 1,354 entries point at a package outside npm and PyPI. Unexamined.
• The 75 unknowns. Of these, 74 carry no SDK pin at all, and 1 has a source signal but no pin. They're excluded from the denominator.

The detector also got things wrong before this run. The first full run that day looked for the SDK pin only at the archive root and classified 94% of artifacts as unknown. The second read <3 in a version specifier as a pin at 3.x. Both runs were discarded, both bugs were fixed, and both are recorded in the census changelog with their commits. I'd rather show the errors than have someone else find them.

Reproduce it

Every figure above comes from one CSV. Each row is a sampled record keyed by a salted digest, with no server names or URLs, because the report is about the population, not about anyone's server.

git clone https://github.com/Berakhah/agent-perimeter
cd agent-perimeter
uv run python analysis/census_analysis.py docs/census/2026-09-14/records.csv

The script recomputes each figure from the CSV, compares it with the published summary, and prints match on every line. Method hash 1c49920d8849ff45. The full method and the discarded runs are in docs/census/CHANGELOG.md.