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...
"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 sucks.
I have to give it to the vibe coding industry, I didn't think one could reinvent the wheel quicker and more often than frontend JavaScript programmers, but they're pulling it off!
I can't really tell why you would need to support the newer spec. It's mentioned that old stuff will work for at least a year after the new spec has been released, but I'm not so clear on what exactly will break. Is there some kind of phase out plan that the AI players have agreed upon for protocol versions will support for how long? Who is making these promises?
More importantly, I see a whole bunch of changes in headers and routing and whatnot on the MCP side itself, but I'm not really seeing what the advantages of the new spec are to either LLM users or MCP server resellers. Why consider upgrading in the first place?
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.
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.
I am interested in why you chose to do this, abd publish it with the headline you used. Was it to learn something? Or to get publicity for another project?
Tbh, this sounds like fear mongering to me. Of course the statement “99.9% of servers are not compliant” sounds impressive, but then it turns spec hasn’t even been released yet.
Also some general feedback: the whole thing looks generated, as does the comment I am replying to.
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...
"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 sucks.
I have to give it to the vibe coding industry, I didn't think one could reinvent the wheel quicker and more often than frontend JavaScript programmers, but they're pulling it off!
I can't really tell why you would need to support the newer spec. It's mentioned that old stuff will work for at least a year after the new spec has been released, but I'm not so clear on what exactly will break. Is there some kind of phase out plan that the AI players have agreed upon for protocol versions will support for how long? Who is making these promises?
More importantly, I see a whole bunch of changes in headers and routing and whatnot on the MCP side itself, but I'm not really seeing what the advantages of the new spec are to either LLM users or MCP server resellers. Why consider upgrading in the first place?
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
Usually a product not working with 99.995% of the eco system is a no go.
Gee I wonder if this is marketing for that 1 MCP server? Yep! I won't advertise it for them, but you can safely skip this drivel.
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.
I am interested in why you chose to do this, abd publish it with the headline you used. Was it to learn something? Or to get publicity for another project?
Tbh, this sounds like fear mongering to me. Of course the statement “99.9% of servers are not compliant” sounds impressive, but then it turns spec hasn’t even been released yet.
Also some general feedback: the whole thing looks generated, as does the comment I am replying to.