Skip to content

MCP 2026-07-28 spec ships: stateless core eliminates sticky-session load balancers

· by Pondero Newsdesk

The short version

The Model Context Protocol's 2026-07-28 specification finalized today, removing the initialize handshake and Mcp-Session-Id that forced MCP servers onto sticky-route infrastructure. Two official extensions, MCP Apps and Tasks, ship alongside the breaking change.

MCP 2026-07-28 spec ships: stateless core eliminates sticky-session load balancers

The Model Context Protocol's 2026-07-28 specification finalized today, and the headline change is structural: the initialize handshake and session ID that once pinned every MCP client to a single server instance are gone. A deployment that previously required a shared session store, sticky routing, and deep packet inspection at the gateway can now run behind a plain round-robin load balancer, per the official MCP blog post.

The stateless core

In the 2025-11-25 specification, every client opened with an initialize exchange and the server returned an Mcp-Session-Id that tied all subsequent requests to one instance. Both are removed. The initialize/initialized handshake is gone (SEP-2575), the session ID header is gone (SEP-2567), and client info now travels in a _meta field on each self-contained request.

The Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers (SEP-2243) so load balancers can route on operation type without inspecting the JSON body. List responses carry a server-specified ttlMs field (SEP-2549) so clients know how long a tools/list cache stays valid without holding an open SSE stream.

Servers that need state across calls can issue an explicit handle from a tool (a basket_id, a session token) and have the model pass it back as an argument on follow-up calls. The MCP maintainers describe this pattern as giving the model more composability than session state hidden in transport metadata.

MCP Apps and Tasks

Two official extensions ship with the spec.

MCP Apps (SEP-1865) lets servers ship interactive HTML interfaces that hosts render in sandboxed iframes. Tools declare UI templates ahead of time for prefetch and security review; all UI actions route through the same JSON-RPC consent path as direct tool calls.

Tasks moved from experimental core feature to a first-class extension. A server can now answer tools/call with a task handle; the client drives the work with tasks/get, tasks/update, and tasks/cancel. Any server instance can pick up a follow-up call because nothing is pinned by session, per the MCP blog. The tasks/list method was removed because it could not be safely scoped without sessions. Anyone who shipped against the 2025-11-25 experimental Tasks API needs to migrate.

Authorization and deprecations

Six SEPs harden the authorization layer. Clients must now validate the iss parameter on authorization responses per RFC 9207 (SEP-2468), a mitigation for mix-up attacks specific to MCP's single-client, many-server deployment pattern.

Three features are deprecated: Roots, Sampling, and Logging. All three continue to work in this release and in any specification version published within 12 months, with removal requiring a separate SEP after that window.

Migration checklist

Any MCP server relying on Mcp-Session-Id or the initialize handshake has a breaking migration. The release candidate locked May 21, 2026, giving SDK maintainers a ten-week window before today's final release; Tier 1 SDKs were expected to ship support within that period. GitHub confirmed its MCP Server already supports the new spec as of July 23, per the GitHub Changelog.

The Tasks migration is the other near-term break. If a tool in your automation stack shipped experimental Tasks support against 2025-11-25, verify the vendor has updated before upgrading.

What to watch

The critical decision for teams running Sampling-dependent workflows: hold client upgrades until Claude Code, Cursor, or Copilot confirms spec support, since those are the hosts where a premature upgrade would break Sampling today. SDK maintainers had ten weeks from the May 21 RC. If your MCP host has not yet shipped the new spec, that delay now sits inside your own migration timeline.

Sources