Author here. Some context on why I built this and what the number does and doesn't mean, since I expect the obvious objection up front.
The 2026-07-28 release is the biggest change to MCP since launch: the initialize handshake and the protocol-level session go away in favor of a stateless core, routing headers become mandatory, and some error codes move. I wanted to know how far the ecosystem had actually moved, so I wrote a zero-install black-box probe (npx mcp-spec-check <url>) and pointed it at every remote server in the official registry.
The obvious objection first: the spec isn't GA yet, so of course almost nothing implements it. That's fair, and it's exactly why I framed this as an adoption baseline rather than a "90% will break" story. Nothing breaks on July 28. Old versions keep negotiating and deprecated features stick around for at least a year. This is the "before" snapshot, and I plan to re-run it through GA to watch the curve.
A few findings I think hold up better than the headline:
75.9% of the 2,008 auth-walled servers already publish RFC 9728 protected-resource metadata, which is readable through the wall. Authorization hardening is way ahead of the stateless-core migration.
Version distribution: 2025-11-25 is the modal protocol, with a long tail back to 2024-11-05.
Registry hygiene: 16,186 entries collapse to 7,850 unique, reachable, actually-MCP targets once you filter junk and dedup.
On method, because I know it will get poked: probes are host-serial with a named User-Agent, verdicts are validated in CI against a real old-spec server and a 2026-07-28 RC beta server, every percentage in the writeup carries its denominator, and I publish the inconclusive rate (about a third of servers, for the two hardest checks) instead of guessing. The aggregate is committed so you can check my math.
The thing I most want to hear about is a wrong verdict on your own server. Happy to defend or revise the methodology here.
_3u10•20m ago
Usually a product not working with 99.995% of the eco system is a no go.
ramon156•15m ago
Cool project idea. skimmed the README as well as the docs link and could not figure out which MCP is ready. Docs just seem to repeat the same thing over and over.
Would be nice to chisel this before releasing
namnnumbr•12m ago
That's a misleading title - of course no existing MCP server is going to be compliant with a spec that has not yet been released, and obviously no server is going to incorporate substantial, breaking changes when the clients themselves don't support the spec...
parhamn•8m ago
"OAuth 2.0 Client ID Metadata Document (CIMD)" is a big one. As an agent-provider, prereigstering client IDs for a bunch of different services and going through each ones special hoops for org validation and stuff sucks.
roee_tsur•1h ago
The 2026-07-28 release is the biggest change to MCP since launch: the initialize handshake and the protocol-level session go away in favor of a stateless core, routing headers become mandatory, and some error codes move. I wanted to know how far the ecosystem had actually moved, so I wrote a zero-install black-box probe (npx mcp-spec-check <url>) and pointed it at every remote server in the official registry.
The obvious objection first: the spec isn't GA yet, so of course almost nothing implements it. That's fair, and it's exactly why I framed this as an adoption baseline rather than a "90% will break" story. Nothing breaks on July 28. Old versions keep negotiating and deprecated features stick around for at least a year. This is the "before" snapshot, and I plan to re-run it through GA to watch the curve.
A few findings I think hold up better than the headline:
75.9% of the 2,008 auth-walled servers already publish RFC 9728 protected-resource metadata, which is readable through the wall. Authorization hardening is way ahead of the stateless-core migration. Version distribution: 2025-11-25 is the modal protocol, with a long tail back to 2024-11-05. Registry hygiene: 16,186 entries collapse to 7,850 unique, reachable, actually-MCP targets once you filter junk and dedup. On method, because I know it will get poked: probes are host-serial with a named User-Agent, verdicts are validated in CI against a real old-spec server and a 2026-07-28 RC beta server, every percentage in the writeup carries its denominator, and I publish the inconclusive rate (about a third of servers, for the two hardest checks) instead of guessing. The aggregate is committed so you can check my math.
The thing I most want to hear about is a wrong verdict on your own server. Happy to defend or revise the methodology here.