The Model Context Protocol's session-based architecture has been a quiet production liability since day one - and in eight days, it's gone. The 2026-07-28 release candidate, locked since May 21, eliminates Mcp-Session-Id, the initialize handshake, and sticky routing requirements in one sweep.
If you have MCP servers connected to Slack, GitHub, your CRM, or any internal tool, you need to know what changes, what actually breaks, and what you can safely leave alone for now.
What the MCP 2026-07-28 breaking changes actually remove
The biggest technical change is that MCP is becoming stateless at the protocol layer. In previous MCP versions, a Streamable HTTP client established a session first. The server returned an Mcp-Session-Id, and the client carried that ID into later requests. That meant deployments had to care about sticky sessions, shared session stores, and gateway behavior that understood enough about MCP to route traffic correctly.
The failure mode was subtle and nasty: pod A handled initialize and issued the session ID, then the SDK's long-lived SSE GET stream silently hashed to pod B - which knew nothing about that session - and returned a 404. Teams spent days debugging what looked like a network issue.
The fix is clean.
As of the 2026-07-28 spec, there is no handshake. Protocol version, client identity, and capabilities travel in a _meta object on every request. Any server instance can handle any request. You can run MCP behind a plain round-robin load balancer, route traffic on the new Mcp-Method header, and scale horizontally without sticky sessions or shared session stores.
Application state didn't disappear - it moved somewhere more honest. Tools now return explicit opaque handles (think a basket_id or job_id). The model can see these handles, reason about them, and pass them forward on subsequent calls. Your server stores actual state in Redis, PostgreSQL, or wherever makes sense. The state is visible to the agent, which makes debugging substantially easier and agent behavior more predictable.
The three deprecated features and their replacements
Deprecation annotations land on Roots, Sampling, and Logging. This is advisory only, as the deprecated methods, types, and capability flags keep working in this release and in every specification version published within a year of it. You have until mid-2027 minimum before anything stops working. But every revision you skip compounds, and the 12-month clocks on sessions, the handshake, Roots, Sampling, and Logging are already running - migrating late means doing all of it at once, under a deadline you no longer control.
Here is what each deprecated feature did and where it goes:
| Feature | What it did | Replacement |
|---|---|---|
| Roots | Client advertised filesystem or workspace scope to the server | Pass as tool parameters or resource URIs per request |
| Sampling | Server asked the client's model to generate a completion | Call the LLM provider API directly from server code |
| Logging | Structured logs emitted from server to client over MCP | Write to stderr or ship to OpenTelemetry |
| HTTP+SSE transport | Older streaming transport | Streamable HTTP (already the standard path) |
The biggest real change is Sampling. Roots and Logging have straightforward replacements you may already be halfway to. Sampling moves the model call from client to server, which is an architectural shift, not a rename. If your server currently issues sampling requests - asking the connected client to run inference on its behalf - that logic needs to move to a direct LLM API call. For most teams, that means wiring in an Anthropic or OpenAI SDK call server-side.
Beagle in action#engineering, 2:07pmsampling and listRoots calls, drafts a summary of affected files with line numbersWhat the spec adds that you actually want
The 2026-07-28 release is not only subtractive.
The release also ships purely additive features: ttlMs and cacheScope on tools/list so clients can finally cache tool lists instead of re-fetching them; W3C trace context in _meta under traceparent, tracestate, and baggage for distributed tracing across the agent boundary; and full JSON Schema 2020-12 for input and output schemas.
The caching change is the one most teams will feel immediately. Every connection on the current spec re-fetches the tool list from scratch.
Routing moves to an Mcp-Method header, so gateways can make routing decisions from headers instead of parsing request bodies. And tools/list responses become cacheable through a ttlMs field, so clients and infrastructure can hold the tool list for a defined window instead of refetching it on every connection.
For a Slack agent calling a busy MCP server dozens of times a minute, that alone is meaningful.
Two new extensions also ship with the spec:
MCP Apps (SEP-1865): lets servers ship interactive HTML interfaces that hosts render in a sandboxed iframe. Tools declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them before anything runs. The rendered UI talks back to the host over the same JSON-RPC base protocol, so every UI-initiated action goes through the same audit and consent path as a direct tool call.
Tasks extension: reshapes the lifecycle around the stateless model - a server can answer
tools/callwith a task handle, and the client drives it withtasks/get,tasks/update, andtasks/cancel. Task creation is server-directed: the client advertises the extension and the server decides when a call should run as a task.
There is also a new security concern worth noting.
Akamai warns that if developers accidentally map sensitive inputs like API keys, tokens, or PII to the new MCP-specific headers, "those secrets are pushed straight into the headers. Once there, they become visible to every load balancer, proxy, and logging system along the path."
Review what you route through Mcp-Method and Mcp-Name before you ship.
What to do this week
The action items are straightforward: read the full RC announcement and identify which features you use that are changing; check your SDK release notes - Tier 1 SDKs have the ten-week window to ship support; audit your transport code for the initialize handshake and Mcp-Session-Id usage; start supplying the iss parameter in authorization responses if you are not already; leave Roots, Sampling, and Logging alone until your SDK guides you through the migration.
The migration checklist from the official SDK beta post covers the mechanical steps. The non-obvious one:
upgrading your server does not strand existing clients - a v2 server answers the legacy initialize handshake alongside server/discover, so clients on 2025-11-25 keep connecting.
You can ship the update before every client has upgraded.
Every change points the same direction: away from protocol cleverness, toward boring, scalable HTTP - stateless requests, header-based routing, standard error codes, standard schema, standard tracing. Each of those choices makes an MCP server cheaper to run and easier to put behind infrastructure you already have.
The formal deprecation policy - new to this version - is the quiet gift in the release. For the first time, MCP has a formal deprecation policy: a minimum 12-month window between deprecation and removal, guaranteed by SEP-2596. Enterprise teams can finally plan migrations without guessing when the protocol will change under them.
MCP 2026-07-28 breaking changes: common questions
What actually breaks on July 28 if I don't update my server?
Nothing breaks immediately - v1 servers keep working, and
a v2 server answers the legacy initialize handshake alongside server/discover, so clients on 2025-11-25 keep connecting.
The real risk is forward compatibility: clients that upgrade to negotiate 2026-07-28 will expect stateless behavior, and servers that still depend on sticky sessions or session-ID routing will degrade silently before they fail outright.
Are Roots, Sampling, and Logging gone on July 28?
No. Roots, Sampling, and Logging are deprecated as of July 28. They still work. The spec guarantees a minimum 12-month window before removal, meaning nothing breaks until at least July 2027. New servers should not use them; existing servers should plan the migration during that window, not at its end.
What replaces Sampling if my server uses it?
Sampling moves the model call from client to server, which is an architectural shift, not a rename. Your server code makes the LLM API call directly instead of asking the connected client to do it. That means wiring an Anthropic, OpenAI, or other provider SDK into your server - more control, but a real code change.
Where do I get the beta SDKs?
The v2 line is a rework of the package you already know: FastMCP becomes MCPServer, and the decorator API carries over. Beta releases of the Python, TypeScript, Go, and C# SDKs are now available with support for the 2026-07-28 MCP specification release candidate.
The official MCP blog post from June 29 lists the install commands and per-SDK migration notes.
Does the stateless change affect stdio-based MCP servers?
No. If you have been running a stateless remote MCP server already, or if your usage is purely stdio, the migration footprint is small. The stateless core change only affects remote servers running over Streamable HTTP - the servers most likely to sit behind a load balancer and the ones most affected by the old sticky-session requirement.