Dora NodaFive specification revisions in twenty months, and the latest one deletes the handshake your server boots on. That is the situation every production MCP operator woke up to when the Model Context Protocol published revision 2026-07-28: a stateless rewrite that removes the initialize handshake and the Mcp-Session-Id header, at a moment when the ecosystem counts 97 million monthly SDK downloads and 10,000-plus production servers, governed by the Agentic AI Foundation under the Linux Foundation.
The one-paragraph answer, before the evidence: pin your SDK floors, serve both protocol eras from one server, and keep a stable REST/GraphQL API underneath the MCP layer so the next revision costs you a projection change, not a migration. This post shows the churn ledger that makes that answer necessary, tables exactly what 2026-07-28 broke, maps how each era-mismatch fails for real deploy/rollback/read-logs operations, and ends with a single pinning checklist.
The churn ledger: five revisions, every one breaking
MCP went from experiment to industry standard in about sixteen months — 97 million combined Python and TypeScript SDK downloads per month by March 2026, an estimated 10,000 active servers in production, hundreds of AI clients. Anthropic donated the protocol to the Agentic AI Foundation (AAIF) on December 9, 2025, co-founded with Block and OpenAI, with AWS, Google, Microsoft, Bloomberg, and Cloudflare as platinum members. Vendor-neutral governance, in other words — which steadied who decides while the wire itself kept moving:
| Revision | Status in Sept 2026 | What it broke or buried |
|---|---|---|
2024-11-05 | Legacy | The original HTTP+SSE transport; two endpoints and an endpoint event |
2025-03-26 | Superseded | Introduced Streamable HTTP and the OAuth model; HTTP+SSE effectively deprecated — AWS's documentation server later ripped SSE out entirely as a breaking change |
2025-06-18 | Older but supported | OAuth 2.1 resource-server split, elicitation, structured tool output — and removed JSON-RPC batching |
2025-11-25 | Widely deployed baseline | OIDC discovery, Client ID Metadata Documents, JSON Schema 2020-12 as the default dialect |
2026-07-28 | Current | Stateless core: initialize/notifications/initialized gone, Mcp-Session-Id gone, capability discovery moved to server/discover with per-request _meta |
Four transitions in twenty months, each with a removal, not just an addition. Any client fleet assembled over that window spans at least three eras — and that spread is the cost center: version negotiation, capability discovery, and pinned SDK floors for a server that agents use to deploy, roll back, and read logs.
What 2026-07-28 actually broke, row by row
Every claim below is traceable to the published changelog and the SDK migrations operators have already written up. The theme is one sentence: state moved from the connection into every request, and anything that assumed a session died with the session.
| Change | Before | After |
|---|---|---|
| Handshake | initialize + notifications/initialized opens every session | Removed; each request carries protocol version, client info, and capabilities in _meta |
| Sessions | Mcp-Session-Id header pins a stream to one replica | Removed from Streamable HTTP — which also removes the sticky-session load-balancer requirement |
| Discovery | Capabilities learned once during the handshake | New server/discover RPC every server must implement |
| Routing | Proxies had to inspect request bodies | Mcp-Method/Mcp-Name headers on Streamable HTTP POST allow header-only routing |
| Error codes | Resource-not-found at -32002 | Moved to -32602; -32020…-32099 reserved for the spec |
| Tool schemas | Constrained subset | Full JSON Schema 2020-12 ($ref, oneOf, allOf) |
| List caching | Re-list everything, every time | ttlMs + cacheScope hints on list results; deterministic tool ordering recommended |
| Observability | Ad-hoc correlation | _meta carries W3C Trace Context (traceparent, tracestate, baggage) |
| Do-not-call list | Roots, Sampling, Logging, ping, logging/setLevel, SSE resumability | Deprecated or removed — including server-initiated requests back to the client |
The last row is the one that bites infrastructure servers hardest. FastMCP 4.0 removed its ctx.sample() API outright, because a stateless protocol has no channel for the server to call back into the client mid-request. If your deploy tool sampled the model mid-tool-call — "summarize this diff before I roll it out" — that pattern needs a redesign, not a rename. Treat every row above as guilty until your conformance test proves otherwise: one operator's migration notes put it well when they pinned protocolVersion: "2025-06-18" in fixtures specifically to keep down-level compatibility tests honest.
The mixed-era failure table: how each mismatch actually fails
Not "what changed" but "what breaks, for which operation, under which combination." The three operations are the ones an infrastructure MCP server exists for — deploy, roll back, read logs.
Client era → Server on 2026-07-28 | Deploy (tools/call) | Roll back (tools/call) | Read logs (resources/read, tools/list) |
|---|---|---|---|
| Modern client, modern server | Works; version and capabilities ride in _meta | Works | Works; ttlMs hints cut re-list traffic |
| Legacy client (handshake-era), modern server without a shim | Fails at connect: client sends initialize, server has no such method | Same — never reaches the tool | Same — never reaches the resource |
| Legacy client, modern server with dual-era negotiation | Works after fallback to the handshake era | Works | Works, minus modern-only hints |
Modern client, legacy server (≤2025-11-25) | Fails or degrades: _meta versions ignored, server/discover unknown | Tool call may work; capability-gated guards misfire | List caching hints ignored; ordering nondeterministic |
Two rows deserve emphasis. Legacy-client-to-modern-server without a shim is a total outage per client, not a degraded mode — there is no graceful subset when the opening RPC does not exist. And modern-to-legacy is the silent one: calls can appear to work while version-gated behavior (schema features, pagination, structured output) quietly disagrees. Underneath both sits capability discovery, and per era, discovery is a different RPC — initialize returns capabilities once per session on the old wire; server/discover answers per request on the new one. A server that cannot answer both questions cannot truthfully serve both eras.
FastMCP 4.0 is the reference pattern: negotiate, don't fork
FastMCP 4.0 — rebuilt on MCP Python SDK v2 — is how the ecosystem's most-used framework answered the three-era reality, and its answer is worth copying even if you run a different stack. The client negotiates a mode per connection:
auto— probe for the modern protocol, fall back to the handshake era when the peer behaves like a legacy server;legacy— speak the established handshake protocol directly;modern(pinned2026-07-28) — stateless wire, no handshake at all.
Real migrations show all three in use: one team switched their HTTP transport to stateless while still answering handshake-era clients from the same process; another runs a non-blocking CI job against the FastMCP 4 beta so the eventual move is a pin change, not a project. The failure mode to watch is identity: with no session to stash it in, per-request identity is authoritative, and code that cached "who the client is" from initialize will attribute one client's requests to another. Modernize the lookup first, the transport second.
The pinning playbook: one checklist, run in order
One checklist, not two — a second list elsewhere in the post would drift apart from this one within a revision. Work it top to bottom:
- Exact-pin the server SDK. A caret range that can resolve a pre-baseline minor is how a clean install silently unships your protocol support. One operator found their floor allowed a pre-
2025-11-251.x and fixed it by raising the floor to match the surface they actually implemented. - Raise dependency floors to the era you serve. If you implement the
2025-11-25surface (2020-12 dialect, protected-resource metadata, structured output, Streamable HTTP), the minimum installable SDK must be one that speaks it. - Add a negotiation conformance test. Assert the negotiated version on a real client/server round-trip — and pin one fixture to the old version so a future SDK bump cannot silently drop the legacy path. Operators who did this caught downgrades before users did.
- Keep a repository-owned legacy matrix. Exercise old-client/new-server, new-client/old-server, and new/new explicitly; do not trust the SDK's automatic compatibility path to cover combinations you never ran.
- Grep for removed APIs before every SDK bump.
ctx.sample(),ping,logging/setLevel, session-id handling, batch calls — the removals list grows every revision, and each one fails at runtime, not at import. - Run a non-blocking probe job on the next SDK beta. The teams that sailed through
2026-07-28knew months earlier that their suite passed unmodified; the pin change was then a decision, not a discovery.
The stability layer: MCP as a projection, not the foundation
Now the second half of the promise: why a Render-compatible REST/GraphQL API underneath is the durability story. Count what survives a protocol rev in each layer. The MCP layer renames methods, moves errors, and re-homes capabilities every few months. The REST layer — deploy a service, roll back a release, stream logs, set an environment variable, attach a custom domain — has no reason to change at all, because it describes your platform's operations, not the agent protocol's framing of them.
Concretely, "Render-compatible" here means the boring endpoints agents actually need: create and inspect services, trigger deploys, list releases and roll back to one, tail build and runtime logs, manage environment variables. When the MCP revision revs again — and the ledger says it will — you rewrite a thin tool-to-endpoint mapping and re-run the compat matrix. The team that bolted agent access directly onto MCP-shaped internals rewrites the server. That asymmetry is the whole argument: negotiation handles the clients you have; the REST layer handles the protocol revisions you have not met yet.
The Monday-morning version: check which spec revision your server speaks, pin the SDK floor to it, add the negotiation test, open the beta-probe CI job, and confirm every MCP tool is a thin projection over a versioned REST endpoint. Four of those are an afternoon; the fifth is the architecture that makes the next breaking revision boring.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
