The release candidate for the next Model Context Protocol specification has been public for a month. The MCP team locked the 2026-07-28 spec on May 21, 2026, with the final publication targeted for July 28, 2026. That is not a distant roadmap item. It is five weeks from today, and this release contains breaking changes.
The change that matters most for anyone running a remote MCP server is the one to session state.
Before this release, every MCP session began with an initialize from client to server, an initialized reply, and an Mcp-Session-Id header that all subsequent requests echoed. The server held that session in memory. If a request landed on a different replica later, things broke. In 2026-07-28, that whole dance is gone.
The 2025 spec required sticky sessions. The 2026 spec assumes you don't have them.
Every request now carries its own protocol version, client identity, and negotiated capabilities inside the _meta object on the JSON-RPC envelope.
The practical result:
a remote MCP server that previously needed sticky sessions, a shared session store, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer, route traffic on an Mcp-Method header, and let clients cache tools/list responses for as long as the server's ttlMs permits.
That is genuinely good news for production deployments. But it also means that any server built around the old session lifecycle will behave incorrectly once clients start advertising the new spec version.
Most MCP server failures in production stem from assumptions about session state that the protocol never guaranteed. The 2026-07-28 release candidate eliminates this entire class of problems by making the protocol stateless at the core. The cost of getting there is that your existing server may have baked those assumptions in - not maliciously, but because the old spec encouraged it.
What else is in this release
The stateless core is the structural change, but the full release also delivers an Extensions framework with server-rendered UIs through MCP Apps and long-running work through the Tasks extension, authorization that aligns more closely with OAuth and OpenID Connect deployments, and a formal deprecation policy so the protocol can evolve without breaking what you've built.
The Extensions framework deserves a beat. 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. That is not a feature most teams will use on day one, but it signals the direction: MCP servers are growing from tool endpoints into something closer to small applications with their own UI surface.
The Tasks extension handles long-running work
- the case where a tool call kicks off something that takes minutes rather than milliseconds. That has been a friction point in agentic workflows since the beginning, and encoding it in the protocol is the right answer.
On authorization:
six SEPs align MCP with mainstream OAuth 2.1 and OpenID Connect deployments, including iss-parameter validation per RFC 9207.
If you've been hand-rolling auth for your MCP server, this is a good moment to stop and align with what the spec now formally requires.
The planning window is concrete
The Python SDK timeline makes the window explicit: v2.0.0a1 was published on June 11, 2026, beta is targeted for June 30, 2026, and stable v2 for July 27, 2026.
The PyPI release metadata says pre-releases are published as 2.0.0aN, each pre-release may contain breaking changes, and v1.x remains the stable line recommended for production.
So the alpha exists to test against, not to ship.
The ten-week window is for SDK maintainers and client implementers to validate the changes against real workloads; Tier 1 SDKs are expected to ship support within this window. When those SDKs ship, clients will start advertising the new spec version. If your server doesn't handle it, the failure mode is not a clean error - it's silent misbehavior around session state that looks like flakiness until someone digs in.
There is a straightforward decision rule here. The 2026-07-28 specification eliminates complexity for teams running MCP servers in distributed environments. Migrate if your deployment uses multiple server instances, requires horizontal scaling, or struggles with session state management - the stateless core provides immediate value. Hold off if your server runs as a single process for a single client, where the stateful model works fine and migration overhead exceeds the benefits.
For teams running an AI assistant - something like Beagle - behind an MCP server that routes requests across multiple processes, the stateless core removes an entire category of infrastructure workarounds. The session pinning tricks that made multi-pod deployments work before become unnecessary. That is not a small thing when you're operating at the scale where those workarounds start to cost real engineering time.
The official release candidate post from lead maintainers David Soria Parra and Den Delimarsky is the right primary source. Read the changelog against 2025-11-25 before touching your implementation. The surface is frozen - what you test against today is what ships on July 28.