One. Out of 4,356 remote MCP servers I could openly probe in the official registry, exactly one passes all three checks the 2026-07-28 spec makes mandatory. 90.8% do not yet. Here is what that means, and just as importantly, what it does not.
First, what it does not mean. Nothing breaks on July 28. That date is when the spec text gets published, not a switch that flips. Old protocol versions keep negotiating, deprecated features stick around for at least a year, and every server that works today keeps working. So this is not a countdown to an outage. It is a snapshot of how far the ecosystem has moved toward the new stateless core, and the honest answer is that it has barely started. Given the spec is not even generally available yet, and only SDK betas exist, that is exactly what you would expect. Think of it as the "before" picture.
What I did
I built a small zero-install tool called mcp-spec-check that black-box-probes a live MCP endpoint and reports whether it is ready for the 2026-07-28 release. Then I pointed it at the whole official registry: every active server's latest version, 16,186 entries, which flattened and deduplicated down to 7,850 unique remote URLs across 5,549 hosts. No source access, just wire behavior.
Of those 7,850 targets, 7,849 returned a verdict (one exceeded the time budget):
| access | count | share |
|---|---|---|
| open | 4,356 | 55.5% |
| auth-walled | 2,008 | 25.6% |
| not an MCP endpoint | 977 | 12.4% |
| unreachable | 508 | 6.5% |
Among the 4,356 open servers, readiness for 2026-07-28 breaks down as 1 ready, 3,956 not ready (90.8%), and 399 (9.2%) too ambiguous to call. The three required checks are the mandatory behavior changes: implement server/discover in place of the old initialize handshake, validate the new Mcp-Method routing header, and work without a protocol-level session. Most servers miss on the routing header and on discover.
The version picture
This is the part I find most telling. For each open server I recorded the newest protocol version it will actually demonstrate speaking, not just claim. The current release, 2025-11-25, is the most common by far at 1,922 servers. A long tail still negotiates versions from 2024 and early 2025. Exactly 5 servers demonstrably speak 2026-07-28.
I almost got this number badly wrong, which is worth a word on method. An early cut counted any stateless server as "speaks 2026-07-28," and that inflated the count to 2,513. But statelessness proves nothing on its own: 2,511 of those were old servers, some still on 2024-11-05, that happen to be stateless and tolerantly ignore the new fields. The real signal is whether a server does something only a 2026-07-28 server does, like advertising the version through server/discover or enforcing the new routing header. Corrected, it is 5.
One number nobody else has
Of the 2,008 auth-walled servers, 1,524 (75.9%) publish their OAuth protected-resource metadata at the standard well-known path, which is readable without credentials. So on the authorization hardening front, the auth-walled population is much further along than the open population is on the stateless core. That is the one readiness signal you can measure through an auth wall, and I have not seen it reported anywhere else.
How I kept it honest
Two things I was careful about. Auth walls are not failures: a 401 means a server needs credentials, not that it is broken, so those servers get classified, not graded. And when a server answers ambiguously, for example it replies to the legacy handshake but rejects the new-style probes with a nonstandard error, I mark the check inconclusive rather than guessing. Publishing how much I could not assess is more useful than false precision. Every percentage in the full writeup sits next to its denominator, and because the registry is concentrated (the single largest host is 15.5% of all targets) every headline number is also reported host-collapsed, so you can see it is not an artifact of one big gateway.
For a concrete proof that the new core is shippable today: GitHub's MCP server is auth-walled, publishes RFC 9728 metadata, and passes the required checks when probed with a token.
Check your own server
If you run an MCP server, you can check it in about thirty seconds:
npx mcp-spec-check https://your-server.com/mcp
You get a one-line verdict, ready for 2026-07-28: YES / NO / UNKNOWN, plus per-check detail and links to the migration docs. The full writeup, with every denominator, the host-collapsed view, and the raw aggregate you can cite, is in the repo: github.com/Roee-Tsur/mcp-spec-check.
I would rather you catch a gap now, with months of runway, than after the clients you care about have already moved on.
Top comments (0)