Is any MCP server ready for the 2026-07-28 spec?

Not fully, as of this census. None of the 4,937 reachable servers passes all four required-conformance signals (server/discover, handshake-free stateless calls, session independence, routing-header enforcement). 40 servers are exactly one condition away, and 81.2% already accept handshake-free calls, the heart of the new revision.

Will MCP servers break on July 28, 2026?

Not on day one. The revision ships with a formal deprecation policy and a minimum twelve-month window for legacy versions, and clients keep speaking older protocol versions. Readiness here measures conformance with the new revision, not whether a server stops working the day it publishes.

How many MCP servers still depend on sessions?

805 of the 4,937 reachable servers (16.3%) still mint the removed Mcp-Session-Id header, and 544 hard-require it: they reject requests without a session and cannot serve new-spec clients without change.

Why is the denominator 4,937 and not all 18,032 registered servers?

Because runtime readiness can only be measured against a server you can actually reach. Most registered servers are package-only (npm, PyPI, Docker) with no hosted endpoint to probe keylessly. Quoting a readiness percentage over the registered total would silently count unmeasurable servers as unready.

Measured against the 2026-07-28 release candidate, ruleset 2026-07-28-rc. Re-verified against the final specification on publication day.

Zero of 4,937 reachable MCP servers are fully ready for the 2026-07-28 spec

On 2026-07-22, six days before the Model Context Protocol's 2026-07-28 revision publishes, we probed every one of the 18,032 servers in the official registry. Of the 4,937 reachable through a conformant keyless initialize, none passes all four required-conformance signals of the new revision. The counterweight is real, though: 81.2% already tolerate handshake-free stateless calls, the heart of the change. Dataset: CC BY 4.0, tag v2026.07.22-1e9d52c.

Readiness verdicts

Verdict	Servers	Share of reachable	Meaning
ready	0	0.0%	passes all four required-conformance signals
needs-migration	4,225	85.6%	reachable, answers the old handshake flow, missing the new requirements
at-risk	712	14.4%	on a removed or deprecated surface (required sessions, HTTP+SSE transport, experimental Tasks)

The remaining 13,095 registered servers carry no runtime verdict: package-only, auth-gated, or down, with no endpoint a keyless probe can measure. That is why every percentage on this page uses the 4,937 denominator.

The four required signals, individually

Accept handshake-free calls

4,010 (81.2%)

The stateless core is the widest-adopted piece by far

Session-independent

4,132 (83.7%)

805 still mint Mcp-Session-Id; 544 hard-require it

Implement server/discover

37 (0.7%)

The new mandatory discovery RPC, still nearly absent

Enforce routing headers

39 (0.8%)

Reject a mismatched Mcp-Method header as the revision requires

40 servers pass three of the four signals: one condition away from ready. The bottleneck is not the architectural change; it is the two new mechanical requirements, server/discover and header enforcement, which ship by default in the new SDK betas.

What versions servers speak today

Negotiated protocol version	Servers	Share of reachable
2025-06-18	2,799	56.7%
2025-03-26	1,536	31.1%
2024-11-05	528	10.7%
2025-11-25	61	1.2%
2025-11-05	3	0.1%
2026-07-28	1	0.0%

Exactly one server already answers with 2026-07-28. 528 still negotiate 2024-11-05, a version three revisions back. Servers that completed initialize without exposing a version are not in this table.

The registry grew 24% while nobody migrated

Between our 2026-07-02 baseline census and this one, the official registry grew from 14,559 to 18,032 servers, 24% in twenty days, while health rates stayed flat (79.7% healthy). The ecosystem is expanding on the old protocol faster than it is migrating off it. Both dated editions are public in the dataset repository, so this comparison is reproducible, not asserted.

If you run an MCP server

Check your own server: the free check form resolves your registry entry, or run akashi locally: akashi check your-namespace/your-server prints a per-signal spec 2026-07-28 line.
If you are on an SDK, upgrade to the 2026-07-28 beta (Python, TypeScript, Go, and C# betas are out): server/discover, header enforcement, and the stateless core come with it.
If you issue Mcp-Session-Id, plan the move to server-minted handles passed as tool arguments; required sessions are the single largest at-risk surface in this census.

State of MCP - Methodology - Dataset (CC BY 4.0) - Check your server

FAQ

Is any MCP server ready for the 2026-07-28 spec?: Not fully, as of this census. None of the 4,937 reachable servers passes all four required-conformance signals (server/discover, handshake-free stateless calls, session independence, routing-header enforcement). 40 servers are exactly one condition away, and 81.2% already accept handshake-free calls, the heart of the new revision.
Will MCP servers break on July 28, 2026?: Not on day one. The revision ships with a formal deprecation policy and a minimum twelve-month window for legacy versions, and clients keep speaking older protocol versions. Readiness here measures conformance with the new revision, not whether a server stops working the day it publishes.
How many MCP servers still depend on sessions?: 805 of the 4,937 reachable servers (16.3%) still mint the removed Mcp-Session-Id header, and 544 hard-require it: they reject requests without a session and cannot serve new-spec clients without change.
Why is the denominator 4,937 and not all 18,032 registered servers?: Because runtime readiness can only be measured against a server you can actually reach. Most registered servers are package-only (npm, PyPI, Docker) with no hosted endpoint to probe keylessly. Quoting a readiness percentage over the registered total would silently count unmeasurable servers as unready.