MCP Stateless Scaling: What the July 28 Spec Actually Fixes

An engineer on a 12-person product team told this story last month: their Slack agent was dropping tool calls randomly, about once every 40 requests under load. Three days of debugging. The culprit was not a model failure or a prompt problem. Pod A handled the MCP initialize handshake and minted the session ID. The next request, routed by the load balancer to pod B, returned a 404. Pod B had never seen that session.

The failure mode was subtle: 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. It was not a network issue. It was a spec assumption baked into every MCP server built before this week.

The release candidate is available today and the final specification ships on July 28, 2026. It is, by a significant margin, the largest revision of the protocol since launch.

Why sticky sessions were the quiet killer for Slack AI agents

The original MCP spec required a session handshake on every new connection. Servers minted an Mcp-Session-Id that pinned each client to a specific instance. In a single-process dev environment, that works fine. In a production Slack integration - where a tool like a Notion lookup or a Jira query might be hitting an MCP server running across multiple pods - the wheels fall off fast.

The stateful handshake was incompatible with the way production HTTP is actually deployed: load balancers had to parse JSON-RPC bodies to route, sticky sessions blocked autoscaling, and a single server restart blew up every in-flight session.

The practical workaround was infrastructure duct tape: because the original spec requires an initialize handshake and pins sessions to a specific instance via the Mcp-Session-Id header, you are forced to configure sticky routing or a shared session store at the load balancer level. This makes scaling beyond a single process unnecessarily complex.

This is why the current setup assumes one server remembers you, but real companies spread traffic across dozens of servers that don't talk to each other by default - and that's been a significant headache for anyone running an MCP server at scale, and part of the reason we haven't seen more companies ship large-scale, first-party MCP integrations despite all the hype around agentic AI this year.

What the stateless core actually changes on July 28

The fix is architectural, not cosmetic. The 2026-07-28 revision removes both the initialize handshake and the protocol-level session. Every request is now self-contained. The protocol version, client information, and capabilities are included in each request rather than exchanged once at connection time.

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.

Two other changes travel alongside the stateless core that matter for teams running agents in Slack or Teams:

• Routable headers. The Streamable HTTP transport now requires Mcp-Method and Mcp-Name headers so load balancers, gateways, and rate-limiters can route on the operation without inspecting the body. This means your gateway can apply rate limits per operation type - tool calls versus list requests - without reading every JSON-RPC payload.
• Cache metadata. List and resource read results now carry ttlMs and cacheScope, modeled on HTTP Cache-Control. Clients know exactly how long a tools/list response is fresh and whether it's safe to share across users. For a Slack agent that calls tools/list on every message, caching that response for 60 seconds instead of re-fetching it cuts a meaningful slice of latency and cost.
• Distributed tracing. W3C Trace Context propagation in _meta is now documented, locking down the traceparent, tracestate, and baggage key names so distributed traces correlate across SDKs and gateways. A tool call that starts in Slack and fans out to Notion, Linear, and a CRM can now appear as a single readable trace.

One thing the stateless spec does not do: make your application stateless. A stateless protocol does not force your application to be stateless. If your MCP server needs to track which Jira board an agent is navigating, that state still needs to live somewhere - now explicitly in your application layer rather than hidden inside the protocol session. With this update, that state is handled explicitly by the application instead of hidden inside the protocol session. The difference is that the state becomes explicit. Instead of hiding state in transport metadata, the server can return a handle and the model can pass that handle back in later tool calls.

What this means if you're building on MCP today

The practical checklist before July 28 is short:

• Test your server behind a round-robin load balancer. If it breaks, find where you're relying on sticky sessions.

• Check your SDK versions. Beta releases of the Python, TypeScript, Go, and C# SDKs are available now.

Python v2 renames FastMCP to MCPServer but keeps the decorator API. TypeScript v2 splits the monolithic SDK into focused packages and is ESM-only.

• Add a version upper bound if you publish a library. If you publish a library that depends on the Python mcp package, add an upper bound such as mcp>=1.27,<2 so the stable v2 release does not surprise your users.

• Existing servers don't break on July 28. Existing servers and clients do not break today or on July 28. New clients that speak 2026-07-28 fall back to the initialize handshake when they reach a server on the 2025-11-25 spec. The backward compat window is generous - the feature lifecycle policy gives every feature an Active, Deprecated, and Removed lifecycle with at least twelve months between deprecation and the earliest possible removal.

The non-obvious thing here is what this spec change does to the adoption curve. The 2026-07-28 specification makes the protocol stateless: agent integrations that previously needed sticky sessions, a shared session store, and specialist infrastructure will now run on ordinary HTTP hosting behind a plain load balancer. For small and mid-sized companies, this is the moment MCP stops being early-adopter technology and starts becoming boring infrastructure - which is exactly when it becomes safe to build on.

Boring infrastructure is the goal. The teams spending three days debugging 404s from misrouted sessions are exactly the teams who stopped building MCP integrations and went back to custom Slack webhooks. The stateless spec removes that friction - not by making MCP more capable, but by making it less fragile.

A teammate like Beagle runs on this kind of plumbing: tool calls that need to be reliable across restarts, deployable without Redis session stores, traceable end-to-end. The July 28 spec is what makes that kind of always-on Slack integration a reasonable engineering bet rather than a gamble on your load balancer config.

MCP stateless scaling: common questions

What is the MCP stateless spec and when does it ship?

The 2026-07-28 MCP specification removes the protocol-level session and initialize handshake, making every request self-contained. It is the largest revision since MCP launched in November 2024. The final specification ships July 28, 2026; the release candidate has been locked since May 21, giving SDK maintainers a ten-week validation window.

Will the July 28 spec break my existing MCP servers?

Not immediately. New clients speaking the 2026-07-28 spec fall back to the initialize handshake when they connect to older servers. The formal deprecation policy guarantees at least twelve months between a feature being deprecated and its earliest possible removal. That said, you should test your server behind a round-robin load balancer now and identify any sticky-session dependencies before they become production incidents.

Why did MCP need sticky sessions in the first place?

The original spec required an initialize handshake that issued an Mcp-Session-Id. Every subsequent request from that client had to carry that ID, which pinned the client to a specific server instance. That was fine for single-process local deployments but became a scaling constraint in any multi-instance production environment - the load balancer had to route by session, not by capacity.

What should I do with application state that used to live in the session?

The stateless spec moves responsibility for state into the application layer. Your MCP server should return an explicit handle when it needs to track multi-step context - for example, which repository an agent is analyzing. The client passes that handle back in subsequent tool calls. State still exists; it just lives somewhere honest and observable, rather than hidden inside transport metadata.

Does the stateless core affect MCP Apps or the Tasks extension?

Both shipped as formal extensions under the new Extensions framework, which is part of the same release. The Tasks extension now uses a call-now, fetch-later pattern: a server answers a tools/call with a task handle, and the client polls or subscribes for results. This replaces the experimental Tasks API from the 2025-11-25 spec - teams using that API need to migrate to the new lifecycle before July 28.