MCP Drops Sticky Sessions to Scale Like the Web

Run an MCP server behind more than one machine and you hit the same wall every time. The protocol assumes a client and server are having one continuous conversation, pinned to whichever instance answered first. Scale that server to three replicas behind a standard load balancer, and the second request from the same client has to land on the exact same box that handled the first, or the session breaks. The fix MCP's maintainers just proposed is blunt: stop having a session at all.

How a Stateless MCP Request Actually Moves

Under the current spec, connecting to an MCP server means a round of initialize/initialized messages before anything useful happens, followed by a server-issued Mcp-Session-Id that the client has to echo back on every single request afterward. That's fine for one laptop talking to one local server. It's a headache for a company running MCP servers as a fleet, because every request has to find its way back to whichever instance remembers that session, which means sticky routing at the load balancer and a shared session store keeping every replica in sync.

The release candidate throws that model out. Here's what a tool call looks like once it ships:

1. The client picks any available server instance behind the load balancer, with no handshake required first.
2. It sends a standard JSON-RPC request over HTTP, with its own identity and capabilities embedded in a _meta field on the request itself.
3. The load balancer reads the Mcp-Method and Mcp-Name HTTP headers, mandated under SEP-2243, and routes on plain round-robin without inspecting the request body.
4. The instance that receives the request has no memory of this client and doesn't need any, because everything it needs arrived in this one message.
5. If the server needs external input mid-call, such as a permission prompt, it returns an InputRequiredResult carrying an inputRequests object instead of holding the connection open.
6. The client gathers the requested inputs and reissues the call, now carrying inputResponses plus the requestState the server echoed back.
7. That retry can land on a completely different server instance than the first request did, since it carries its own state with it.
8. Tool results and resource reads come back with ttlMs and cacheScope fields, so caching behaves like ordinary HTTP Cache-Control.
9. Interactive UI, if a tool needs it, renders through the new MCP Apps extension: server-rendered HTML inside a sandboxed iframe, with UI templates declared ahead of time for prefetching and review.
10. Long-running work goes through the rebuilt Tasks extension, using tasks/get, tasks/update, and tasks/cancel, each scoped to one task rather than a whole session.

No step in that list requires the server to remember the client existed before the message arrived.

Step by Step: What Changed and Why

Killing the Handshake

The initialize exchange and the Mcp-Session-Id header have been the backbone of every MCP connection since the protocol's first stable release. They also created the exact operational problem MCP inherited without meaning to: a chat-style protocol pressed into service as backend infrastructure. Nate Barbettini, founder of Arcade, an AI-agent infrastructure startup that raised $60 million in June 2026, described the shift plainly to TechCrunch: the protocol is moving to "a looser, 'stateless' approach to session IDs on the server side, similar to how most ordinary websites already work." That comparison is the point. Ordinary websites scaled past single-server assumptions decades ago; MCP is catching up.

A production network switch. Under the current MCP spec, a client's session has to keep tracking back to one specific server instance behind hardware like this - the new spec removes that requirement entirely. Source: unsplash.com

Where State Went Instead

Removing the header doesn't remove the information it carried, it just relocates it. Client info and capabilities that used to get negotiated once, at connection time, now travel with the request that needs them, inside a _meta field. The official release candidate notes, published by lead maintainers David Soria Parra and Den Delimarsky, put it directly: "any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments needed before are no longer required at the protocol layer."

The release candidate announcement on the official Model Context Protocol blog, listing a stateless core, extensions, tightened authorization, and a formal deprecation policy as the four headline changes. Source: modelcontextprotocol.io

A simplified version of what that request now looks like on the wire:

POST /mcp HTTP/2
Content-Type: application/json
Mcp-Method: tools/call
Mcp-Name: search_docs

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "search_docs",
    "arguments": { "query": "stateless mcp" },
    "_meta": {
      "mcp.client.info": { "name": "acme-agent", "version": "1.4.0" }
    }
  },
  "id": 42
}

No session ID anywhere in that request. Everything the receiving server needs to process it is already there.

The Interactive and Async Extensions

Two capabilities that used to live in MCP's core are being carved out into standalone, independently versioned extensions instead: MCP Apps, which lets a server render interactive HTML inside a sandboxed iframe rather than returning plain text, and Tasks, for work that outlives a single request-response cycle. Tasks in particular had to be rebuilt for the stateless world - the old tasks/list method is being removed outright, with no replacement, because the maintainers concluded it can't be safely scoped to a single client without the session state the rest of the protocol just gave up.

Old Pipeline vs New Pipeline

Where It Breaks

None of this migration is free. Anyone who built session-store infrastructure specifically for MCP, or who leaned on tasks/list to enumerate work in flight, has to rearchitect rather than bump a version number, and the clock on that's real: Roots, Sampling, and Logging carry only a 12-month minimum deprecation window before their methods stop working entirely, putting a hard deadline around December 2027 on anyone still depending on them.

The 10-week SDK validation window is also tight given how much the RC touches at once. Six separate SEPs tighten MCP's OAuth and OpenID Connect handling in this release, including issuer validation per RFC 9207, which means authorization code written against the current spec needs review, not just a dependency bump. And MCP Apps' sandboxed-iframe model is new enough that it hasn't faced the kind of adversarial scrutiny that broke MCP's STDIO transport earlier this year, when Ox Security disclosed a design flaw exposing 200,000-plus MCP server instances to arbitrary command execution. MCP's track record on shipping first and hardening later isn't spotless, and a brand-new UI-rendering surface is exactly the kind of feature that record should make people cautious about.

It's also worth remembering this is still a release candidate. The spec most production MCP servers run today is 2025-11-25, the stateful one, and it stays that way until 2026-07-28 is finalized and SDKs across all ten official languages actually ship support for it.

What the shape of this change says about MCP isn't that Anthropic, or the Agentic AI Foundation that has stewarded the protocol since Anthropic donated it to the Linux Foundation in December, decided statelessness was elegant for its own sake. It's that MCP stopped being a way to wire one assistant to one laptop and became infrastructure that companies run at a scale where sticky sessions show up as a line item on a cloud bill. A protocol built for a single Claude Desktop connection doesn't need round-robin load balancing. One built for the hundreds of thousands of production MCP server instances now sitting behind enterprise AI agents does, and that's the protocol MCP is being rewritten to be.

Sources:

• AI's most important protocol is getting a little bit easier to use - TechCrunch
• The 2026-07-28 MCP Specification Release Candidate - Model Context Protocol Blog
• MCP is growing up - Agentic AI Foundation Blog
• Model Context Protocol announcement - Anthropic
• Linux Foundation Announces the Formation of the Agentic AI Foundation - Linux Foundation