Stateless MCP Spec Lets AWS Servers Drop Sticky Sessions

The protocol no longer remembers you

The Model Context Protocol published the biggest revision in its history on July 28, 2026. The new version takes protocol-level sessions out of MCP, the standard that connects AI agents to external tools.12 Two proposals do most of the work. SEP-2575 removes the initialize/initialized handshake, and SEP-2567 removes the Mcp-Session-Id header and the protocol session it stood for.12 Each request now carries its own protocol version, client identity and capabilities in a _meta field. That means any server instance can answer any request.812

For teams running remote MCP servers on AWS, the practical effect is now becoming clear. AWS Architecture Blog authors Anand Komandooru, Steven DeVries and Haleh Najafzadeh have published guidance that compares the new spec with the AWS Well-Architected Agentic AI Lens. They argue that sticky-session routing and session stores, which existed only to hold MCP protocol state, can be removed.1112 This is the main operational effect of the spec change, and it changes how MCP servers get built and paid for.

What session affinity used to cost

Under the 2025-era protocol, a client opened with initialize. The server replied with a session ID, and the client had to send that ID back on every later call. Only the instance that issued the ID could honor it.18 On AWS that left operators two options. They could turn on Application Load Balancer stickiness to pin each session to one instance, or they could move session state into Amazon DynamoDB or ElastiCache.12 AWS says plainly that this design "fought horizontal scaling."12

Sticky routing also failed in a specific way. When a pinned instance restarted, was drained during a rolling deploy or fell over under load, every session on it was lost. A routine instance recycle became an outage that clients could see.18 Microsoft's App Service team described the same problem. Even the older "stateless HTTP" mode still started with a handshake and handed out a session ID, so teams either kept affinity on or did real work to share session state across instances.3

The new AWS guidance lists the changes item by item. Load balancer stickiness gives way to plain round-robin routing. The DynamoDB or ElastiCache session store is replaced by identifiers the server mints and passes as tool arguments. Gateways that read request bodies to route by method can route on the new Mcp-Method and Mcp-Name headers instead.12 AWS Lambda used to need workarounds for the stateful handshake. AWS now calls it "a natural fit" for the request-in, response-out model.12

The industry agrees on the problem

Coverage lines up closely on the core facts. Google, Microsoft and AWS all describe the change in nearly the same terms: no handshake, no session header, and any request can land on any instance behind an ordinary load balancer.2312 Google called it "the biggest change to MCP spec since launch." It also noted beta SDKs for Python, TypeScript, Go and C#.2 The project's own blog says sticky routing and shared session stores "are no longer required at the protocol layer."1

The reason sessions were dropped matters as much as the decision. According to one developer's account of SEP-2567, the session concept never settled on a single meaning. ChatGPT reportedly opened a new session for every tool call. Most desktop IDE clients kept one session for the whole process. Web clients opened one per page load, and almost no client resumed a session after a disconnect.7 If that account is right, the session was not a reliable continuity guarantee. It was a pinning mechanism whose scope server authors could not predict, so removing it takes away very little that servers could depend on.

The same write-up gives migration figures, which this article has not verified independently. About 90 percent of servers reportedly made no application-level use of the session ID. About 2.5 percent kept application state keyed to it, and 0.7 percent used it for proxy or gateway sticky routing.7 If those numbers hold, most servers need an SDK upgrade and little else. A small group of gateway and stateful-tool operators will carry most of the migration work.

State moves out of the protocol, not out of the system

Every serious account repeats one point: a stateless protocol does not mean a stateless application. The MCP project says so directly.1 InfoQ cites developer Michael Madsen's summary: "The protocol is stateless. Your application doesn't have to be."11 The replacement is the explicit handle pattern. A tool returns an opaque ID, such as a basket or ticket ID. The model passes it back as an ordinary argument on later calls, and the real state stays in the operator's datastore.912 AWS compares this to a coat check: a numbered ticket that any attendant can serve, instead of a valet who has to recognize your face.12

Interactive flows work differently now too. Multi Round-Trip Requests (MRTR) replace server-initiated requests that used to need held-open streams. A server returns an input_required result, and the client answers and re-sends the original call.611 In the AWS version, an opaque requestState value carries the context the server needs, so any instance can pick up the resumed call without a shared store.12

The responsibility shifts with the state. Stream resumability is gone. Clients have to retry interrupted operations, which makes idempotency much more important for tools with side effects.11 AWS says the fix is the idempotent task execution pattern from its Lens: tools should be built so that a repeated request does not cause a duplicate action.12 Security firm Equixly makes the same point from an attacker's angle. Its guidance is to protect explicit state handles, sign and expire requestState, reject requests whose headers don't match their bodies, and block duplicate side effects.4 AWS's own self-check asks whether servers enforce ownership for each identifier "rather than trusting the identifier itself."12 The risk has moved: an opaque handle that is not bound to the authenticated caller is now a likely way in.

Where the coverage diverges

The sharpest disagreement is about how much is lost. Bex.co, which sells hosting, says statelessness "costs you nothing per request." But it also lists what disappears: server-to-client push, confirmations in the middle of a call over an open channel, and sampling. Long-running or human-gated operations such as deploys and rollbacks have to be redesigned as polled tasks.16 Appwrite reads it differently. It says MRTR lets elicitation and sampling work over the stateless transport.8 Both partly hold up. The spec deprecates Sampling, Roots and Logging, keeping them until at least July 2027, while MRTR covers the interactive cases.412 The result is that the old features still exist for now, but in a different form and on a deadline.

Workato, which sells integration software, is more skeptical. It argues the spec is "silent" on where state lives, what happens when a worker dies mid-call and what a gateway can enforce per tool. Removing one set of workarounds, it says, did not remove the key architecture decisions.20 That is fair, and AWS largely agrees: its guidance spends most of its length on monitoring, tracing, security and idempotency, not on the parts it lets teams delete.11

AWS's own documentation has not fully caught up. A September 11 AWS containers post on running MCP servers on Amazon ECS still describes a stateful mode built on the Mcp-Session-Id header for long-lived sessions.17 Developers on AWS re:Post have also discussed how Bedrock AgentCore Runtime routes requests to microVMs by session ID.15 AWS says teams behind AgentCore Gateway get protocol management and backward compatibility handled for them.12 The mix of messages shows how far the move from sessionful to stateless MCP still has to go.

Don't delete the session store yet

The most useful part of the AWS guidance is a warning. The 2026-07-28 spec keeps a backward-compatible lane with session behavior for older clients. ALB stickiness rules and DynamoDB or ElastiCache session stores "must remain in place" until pre-2026-07-28 traffic is gone.12 AWS's advice is to log the protocol version of each request at the gateway, set a sunset date for the legacy lane, and only remove session infrastructure once old-version traffic reaches zero.1112 Apify's MCP server project shows what that looks like. It is building stateless support alongside its existing sessionful server, with routing and conformance tests for both protocol versions.11

Equixly notes that the handshake and session header were removed outright, not deprecated, so older clients keep working only if operators run the old path next to the new one.4 Supporting the old lane is the operator's choice, and so is deciding when to drop it.

The takeaway

The 2026-07-28 spec turns MCP servers from a special-case workload into something load balancers, autoscalers and Lambda already handle well. A self-hosting operator reports cutting about 2.2 GB of per-session memory across 36 sessions down to one daemon of roughly 80 MB after switching. That is a single anecdote, but it shows where the savings come from.16 The tradeoff is that work the protocol used to do implicitly is now the developer's job: storing state, retrying safely and checking authorization on every handle. On AWS, teams can delete the session infrastructure, but only after they have built idempotent tools, ownership checks on every identifier and gateway-level version tracking, and after legacy traffic has stopped.