MCP's Stateless Spec Changes More Than Your Load Balancer

Since the November 2025 release, MCP's Tier 1 SDKs have been seeing close to half a billion downloads a month, with both the TypeScript and Python SDKs crossing the one-billion total downloads threshold. That is a lot of production servers built on a stateful, handshake-first protocol - which is exactly why the July 28, 2026 specification is the largest revision since the protocol launched.

The short version: the new spec makes the protocol core completely stateless. The handshake is gone. The initialize/initialized exchange and the Mcp-Session-Id header have been removed entirely. If you run a remote MCP server in production, some of this is a real code change - not a version bump you can ignore until next quarter.

What the old stateful design actually cost

For eighteen months, running a remote MCP server meant fighting your own infrastructure. You had a bidirectional, stateful protocol sitting on top of HTTP, which meant sticky sessions, a shared Redis for session state, or a gateway doing packet inspection to route requests to the one box that held the connection. Every horizontal scaling story started with an apology.

Under the 2025-11-25 specification, clients established a session at connection time and the server used the session ID to retrieve the client's metadata, capability set, and negotiated protocol version. Every stateful remote MCP server therefore needed a session store to share state across instances, sticky-session routing at the load balancer, and logic to expire or recover sessions.

None of that was load balancing overhead in the abstract - it was real infrastructure you had to provision, monitor, and pay for, just to route agent traffic to the right process.

What stateless MCP actually means (and does not mean)

Every request now carries its own protocol version, client identity, and capabilities, which means any server instance can serve any request behind a plain round-robin load balancer.

A stateless MCP server is now an ordinary HTTP workload. Any request can land on any server instance. There is no persistent session, session affinity, or shared storage - which means serverless and edge deployment, horizontal scaling, and a meaningful drop in the cost of running a remote MCP server.

The thing most coverage is glossing over: stateless MCP is a scalability fix, not a security fix.

Statelessness relocates state, not risk. Applications that need continuity mint explicit handles that travel through model context as ordinary arguments. If your tool calls chain together and depend on shared context, you now own that state explicitly - it does not disappear, it just moves out of the protocol layer and into your application.

The two new extensions worth understanding: Tasks and MCP Apps

Tasks handles long-running work. It first shipped as an experimental core feature in the 2025-11-25 spec, but production use led to moving it out of the core protocol and into an official extension. The redesign matters because the Tasks extension reshapes the lifecycle around the stateless model: a server can answer a tools/call with a task handle, and the client drives it with tasks/get, tasks/update, and tasks/cancel. Task creation is server-directed - the client advertises the extension and the server decides when a call should run as a task.

If you built against the November 2025 experimental Tasks API, this is not a soft migration - the poll-based tasks/get, tasks/update, cooperative tasks/cancel redesign is an explicit breaking change for anyone who shipped against the 2025-11-25 experimental API.

MCP Apps is the other new addition. MCP Apps (SEP-1865) is a named extension that lets servers ship interactive HTML interfaces, which hosts render in a sandboxed iframe. Tools declare their UI templates ahead of time so hosts can prefetch, cache, and security-review them.

The rendered UI talks back to the host over the same JSON-RPC base protocol used everywhere else in MCP, so every UI-initiated action goes through the same audit and consent path as a direct tool call. For anything involving human approval flows - think a confirmation step before an agent posts to a channel - that consistent consent path matters more than the iframe itself.

A teammate like Beagle, for example, sits exactly at that approval boundary: the agent drafts, a human confirms, and MCP Apps gives that confirm interaction a spec-blessed way to render without a bespoke front end.

Authorization hardening: the part you cannot defer

The core authorization specification now follows production OAuth 2.0 and OpenID Connect deployments more closely. The release adds issuer validation, binds client credentials to their authorization server, and starts moving away from Dynamic Client Registration toward Client ID Metadata Documents.

Issuer verification (RFC 9207) requires public clients to validate the iss parameter on authorization responses, protecting against session hijacking and redirect-based attacks in multi-server architectures. Resource Indicators (RFC 8707) require clients to explicitly specify which MCP server a token is intended for, solving the "confused deputy" delegation problem.

The confused deputy issue is worth pausing on. In a multi-server MCP deployment - one client, several servers with different data access - a token meant for a low-privilege server could previously be replayed against a high-privilege one. RFC 8707 closes that gap at the protocol layer. If your MCP deployment sits in front of real production data (a database, a CRM, a file store), this is the change to prioritize, not the load balancer story.

There is also an Enterprise-Managed Authorization extension. It lets an organization manage MCP access through an existing identity provider such as Okta or Microsoft Entra ID. An administrator can define which MCP servers employees may access. Joining, changing roles, and leaving the company can then follow the organization's normal identity policies.

What to do before a client upgrades on you

The specification is final, but July 28 is a publish date, not a switch-off - publication does not turn anything off for implementers still on 2025-11-25, and the deprecation policy buys at least twelve months for anything being phased out.

That twelve-month window is not an excuse to wait. The deprecation clock is the planning horizon. Roots, Sampling, Logging, and DCR keep working for at least twelve months - eligible for removal no earlier than a revision released on or after July 28, 2027 - almost exactly one enterprise budget cycle. The estates that inventory now migrate calmly; the ones that do not will meet the removals as incidents.

A practical order of operations for server authors:

• Audit session reliance first. Remove any code paths that read or write Mcp-Session-Id. Check your load balancer config for sticky-session rules that now serve no purpose.

• Migrate Tasks if you shipped the 2025-11-25 experimental API. Rewrite to the poll-based extension lifecycle: tasks/get, tasks/update, tasks/cancel.

• Implement server/discover. A client that wants server capabilities can call the new server/discover RPC. Calling it is optional for clients. Implementing it is not - every 2026-07-28 server must support it.

• Harden auth. Authorization gets stricter and more standards-aligned around OAuth and OIDC. The direction is tighter validation of tokens and issuers and cleaner client registration - which matters because MCP servers increasingly sit in front of real systems and real data.

• Replace protocol Logging with distributed tracing. Distributed tracing keys are now standardized across SDKs, so requests can be traced across a chain of MCP servers with a common context. With protocol Logging deprecated, this is the sanctioned observability path.

MCP stateless spec: common questions

What is the MCP 2026-07-28 specification?

The 2026-07-28 spec is the largest revision to the Model Context Protocol since it launched. It removes protocol-level sessions and the initialize handshake, making every request self-describing and stateless. It also adds a formal extensions framework, the Tasks and MCP Apps extensions, tighter OAuth/OIDC authorization, and a formal deprecation policy.

Does stateless MCP mean my server no longer needs state?

No. Statelessness means the protocol layer holds no session state - not that your application can avoid it. Any cross-call context your tools depend on must now be passed explicitly as a handle in tool arguments, rather than retrieved from a session store the protocol managed for you. Application-layer state is unchanged; its ownership just shifted to you.

What breaks when upgrading from the 2025-11-25 spec?

Three areas introduce breaking changes: the removal of the initialize handshake and Mcp-Session-Id header; the redesigned Tasks extension lifecycle (poll-based, incompatible with the 2025-11-25 experimental API); and tighter authorization requirements. Roots, Sampling, Logging, and Dynamic Client Registration are deprecated - not removed yet, but on a twelve-month clock.

When will deprecated MCP features actually be removed?

The formal deprecation policy sets a minimum twelve-month window. Roots, Sampling, Logging, and DCR are eligible for removal no earlier than a revision published on or after July 28, 2027. HTTP+SSE has its own separately published removal schedule. Nothing was removed on July 28, 2026 itself.

What is the MCP confused deputy problem and how does 2026-07-28 fix it?

In a deployment where one MCP client talks to multiple servers with different permission levels, a token issued for a low-privilege server could previously be replayed against a higher-privilege one. The 2026-07-28 spec requires clients to declare which specific server a token is intended for (RFC 8707 Resource Indicators), so a replayed token is rejected at the authorization layer rather than silently accepted.