The Model Context Protocol’s 2026-07-28 specification is out, and it is not a point release. The core protocol moves from a stateful, session-oriented model to a stateless request/response model, and the changes are not backward compatible in both directions: a server built against 2026-07-28 will reject or confuse an older client, and an older server will not understand several of the new request shapes. If you run or integrate MCP servers in production, this is a migration, not an upgrade.
What Changed in the Protocol Core
The previous MCP transport model assumed a long-lived session: a client connected, the server allocated session state, and every subsequent request depended on that state being available on the same server instance. That assumption is gone. The 2026-07-28 revision routes each request independently using an Mcp-Method header, which means a server no longer needs sticky sessions, a shared session store, or deep packet inspection at a gateway to keep requests pinned to the right backend. A plain round-robin load balancer is now a valid deployment target for a remote MCP server, which it was not before.
Three changes matter most for a working integration:
- Stateless core with Multi Round-Trip Requests. Multi-step exchanges that used to rely on session continuity are now modeled as explicit round trips the client manages, instead of implicit state the server holds open.
- Cacheable list results.
tools/listand similar list responses can now be cached by the client, which cuts how often a server needs to serve them and changes the blast radius of a bad cache if your server’s tool set changes at runtime. - Tasks moved out of core. The Tasks feature, used for long-running operations, is now a formal extension rather than a core capability. If anything in your integration polls or awaits long-running MCP tasks, it needs the extension explicitly declared and supported by both ends.
Compatibility Matrix Before You Touch Anything
| Pairing | Result | Action Needed |
|---|---|---|
| 2026-07-28 client → 2026-07-28 server | Full compatibility | None — this is the target state |
| 2026-07-28 client → pre-2026-07-28 server | Partial or broken — header-based routing and list caching assumptions won’t be honored | Pin client to prior spec version until server is upgraded, or run version negotiation if your SDK supports it |
| Pre-2026-07-28 client → 2026-07-28 server | Likely broken for stateful flows and Tasks | Upgrade client SDK before upgrading server, not after |
| Server relying on session-scoped state (auth context, in-memory tool state) | Breaks under stateless routing | Move session state to an external store keyed by a request-level identifier, not a transport-level session |
A Migration Sequence That Avoids a Production Break
Upgrading the server before the client — or the reverse, without checking — is the most common way this migration goes wrong. A safer order:
- Audit for hidden statefulness first. Grep your server implementation for anything that reads request N and expects context from request N-1 without an explicit identifier passed in the payload. This is usually auth context, partially-built tool responses, or in-memory rate limiting keyed by connection rather than by client ID.
- Move that state to an external store — Redis, a database row, or a signed token the client round-trips — keyed by something durable, before you touch transport code.
- Upgrade the Tier 1 SDK on the client side and run it against your current (pre-2026-07-28) server. This confirms the client can still negotiate the older spec, which tells you your rollback path works.
- Upgrade the server behind a version flag or a separate route, and run both old and new server versions side by side against the upgraded client during a transition window.
- Declare the Tasks extension explicitly if any tool call is long-running, and test the failure path — a client that doesn’t know about the extension should get a clear capability-negotiation error, not a silent hang.
The Enterprise-Managed Authorization extension, now stable and already being adopted by Anthropic, Microsoft, and Okta, is worth adding to this same migration window if you operate more than one MCP server for the same organization — centralizing auth once, during a migration you’re already doing, costs less than doing it as a second project later.
What Breaks Silently If You Skip the Audit
The failure mode to watch for isn’t a hard error — it’s a tool call that appears to succeed but used stale cached list data, or an auth context that leaks across unrelated requests because it was keyed to a transport session that no longer means what it used to. Load test the cache invalidation path specifically: change your server’s available tools at runtime and confirm connected clients pick up the change within your expected window instead of serving a cached tools/list indefinitely.
