The 2026-07-28 Model Context Protocol specification shipped on 28 July 2026, and the maintainers frame it as the most important release since remote MCP launched over a year ago. The protocol core is now stateless: the initialize handshake and Mcp-Session-Id header are gone, server-initiated requests are redesigned around a retry pattern called MRTR, authorization is hardened, and Roots, Sampling and Logging are deprecated on a twelve-month clock. Nothing you run today stops working — but the migration is real, and the order you do it in matters.
What actually breaks, in the order it will bite you
We covered the strategic case for the stateless rework three weeks ago, when this was still a release candidate, in MCP Goes Stateless. That post answered whether to build on it. This one answers what to change now that the spec is final and all four Tier 1 SDKs have shipped against it. If you are earlier in the journey and want the conceptual grounding rather than the migration diff, start with What Is MCP? and work forward from there. The distinction matters because the final spec landed with details the release candidate coverage largely skipped — MRTR chief among them.
The headline change is the one everybody has read about: the initialize/initialized exchange and the Mcp-Session-Id header are retired. Each request now carries its own protocol version, client identity and capabilities in a _meta field, and a new optional server/discover RPC lets a client fetch capabilities up front if it wants them. Any request can land on any instance behind a plain round-robin load balancer with no shared session store. If your server code reads a session id anywhere, that is your first and largest edit.
The subtler point the official post makes, and that most secondary coverage misses: dropping the protocol-level session does not force your application to be stateless. If your server genuinely needs state across calls, the maintainers recommend minting an explicit handle from a tool and having the model pass it back as an argument — state the model can see and thread between tools, rather than state hidden in the transport. That is a design instruction, not just a migration note, and teams that miss it tend to rebuild sessions badly on top of a protocol that just removed them.
MRTR: the change that quietly breaks your approval flows
Multi Round-Trip Requests is the piece worth reading twice. Server-initiated requests — elicitation/create, sampling/createMessage and roots/list — previously required a held-open bidirectional stream. That does not survive a stateless protocol, so MRTR (SEP-2322) replaces it: when a tool needs something mid-call, such as a confirmation or a missing parameter, the server returns resultType: "input_required" along with the requests it needs answered, and the client retries the original call with the answers attached in inputResponses.
In practice this is the change most likely to break something a business actually depends on, because human-approval steps are exactly the flows built on elicitation. If your agent pauses to ask a person before sending an invoice, changing a price or deleting a record, that pause is implemented on the old server-initiated path. Under MRTR the same interaction becomes a return-and-retry cycle, which means your client has to be able to re-issue a call idempotently with accumulated answers. Teams that treat this as a transport detail discover the hard way that it is a control-flow rewrite. Supabase's head of product publicly framed MRTR as the change that finally lets a stateless MCP server confirm with a user before acting — cost of a new project, or a query that would delete data — which is precisely the pattern SMEs care about.
Authorization got stricter, and DCR is on the way out
Authorization is where implementers spend most of their integration time, and this revision moves several things at once. Authorization servers should now return the iss parameter per RFC 9207, and clients must validate it before redeeming a code — this closes an authorization-server mix-up hole. Client credentials are now bound to the issuer that minted them, so no reuse across authorization servers. Clients set application_type during Dynamic Client Registration so authorization servers stop rejecting localhost redirects for desktop and CLI apps, which is the actual cause behind a great many mystifying redirect_uri errors.
The strategic item in that list is the last one: Dynamic Client Registration is now formally deprecated in favour of Client ID Metadata Documents. DCR keeps working for backward compatibility and will be removed in a future revision. If you are scoping an integration this quarter, build on CIMD and skip a migration you would otherwise do twice.
Deprecations run on a twelve-month clock, not a cliff
Roots, Sampling and Logging are deprecated (SEP-2577). They still work and will keep working for at least twelve months under the new formal deprecation policy, which sets a twelve-month minimum window so teams can plan upgrades instead of reacting to them. The legacy HTTP+SSE transport is likewise officially deprecated with a year-long offramp. New implementations should not adopt any of them.
Tasks, meanwhile, moved out of the experimental core into the io.modelcontextprotocol/tasks extension, with a poll-based tasks/get and a new tasks/update. Change notifications move from the old HTTP GET endpoint to a single subscriptions/listen stream that clients opt into per notification type. Two other extensions are now first-class alongside it: MCP Apps and Enterprise Managed Authorization.
Two operational wins you get for free
Streamable HTTP requests must now include Mcp-Method and Mcp-Name headers, so a gateway, rate limiter or WAF can route and meter on headers instead of parsing JSON bodies. If you have ever tried to rate-limit an MCP server per tool, you know why this matters. Separately, responses from tools/list, prompts/list, resources/list and resources/read now carry ttlMs and cacheScope with a deterministic ordering, so clients can cache tool catalogues and keep upstream prompt caches stable across reconnects.
That second one has a direct cost consequence. Unstable tool-list ordering silently invalidates upstream prompt caches on every reconnect, and prompt-cache misses are pure token spend. Deterministic ordering plus explicit cache hints is a quiet efficiency win that shows up on the bill rather than in a benchmark — the sort of thing you only notice if you are tracing per-call token cost, which is the discipline we wrote up in AI Agent Observability.
How big is this ecosystem now, actually
Some concrete adoption numbers from the maintainers, useful for anyone deciding whether MCP is a safe bet: across the Tier 1 SDKs the project sees close to half a billion downloads a month, with both the TypeScript and Python SDKs crossing one billion total downloads. All four Tier 1 SDKs — TypeScript, Python, Go and C# — speak 2026-07-28 as of release day, with the Rust SDK supporting it in beta. Honeycomb reported that nearly 20% of all its monthly interactive queries are now made by agents. The maintainers of the mcp-use framework, Manufact, reported cutting package size by roughly 83% and running about 25% faster on the new client-server split.
A migration order for a Dutch SME that shipped an integration in 2025
- Triage first: grep for Mcp-Session-Id and for the initialize handshake. If neither appears, your migration is mostly an SDK version bump and a header addition.
- Find every human-approval step. Anything built on elicitation needs the MRTR return-and-retry rewrite, and it needs the retried call to be idempotent. Budget real time here, not an afternoon.
- Check what you depend on among Roots, Sampling and Logging. You have twelve months minimum, but move Sampling to provider APIs and Logging to OpenTelemetry rather than waiting for the removal notice.
- Switch new auth work to CIMD, add RFC 9207 iss validation on the client, and stop reusing client credentials across authorization servers.
- Add Mcp-Method and Mcp-Name at the gateway, then use them for per-tool rate limiting — the cheapest security control in this list. Agent-specific threats do not go away with a spec bump; see AI Agent Security for the threat model that still applies.
If you are scoping a new integration rather than migrating one, target 2026-07-28 from day one and you skip all of the above. The stateless core is genuinely easier to operate: ordinary HTTP hosting, no sticky sessions, no shared session store, horizontal scaling that works the way the rest of your infrastructure already works. The day-two operational habits are unchanged by this revision — Running MCP in Production covers those separately. That is the real story for a 20-to-50-FTE company — not that MCP got more capable, but that it got boring enough to run on the hosting you already pay for. We build and migrate MCP integrations against the current spec, and the migration triage above is the same one we run on day one of an engagement.
One caveat worth stating plainly: a protocol revision does not solve governance. Access control, audit trails for compliance and human approval steps remain yours to design — the spec moves your data reliably and stops there. Verified against the specification and SDK release notes as published on 28 July 2026; check the official changelog before committing to an architecture, since the ecosystem is still moving weekly.
