Back to News
Tools

AWS Ships Stateless MCP Spec, Dropping Sticky Sessions for Remote Servers

AWS Ships Stateless MCP Spec, Dropping Sticky Sessions for Remote Servers
Image: InfoQ

The latest Model Context Protocol revision eliminates protocol-level sessions, letting remote MCP servers behind load balancers route each request independently.

September 25, 2026 · 2 min read · VintuxAI Newsroom

AWS has published details on a revision to the Model Context Protocol that strips protocol-level sessions out of remote MCP servers, ending the sticky-session and session-storage requirements that had shaped how those servers were deployed. The change, described by AWS developer advocate Leela Kumili, means a request no longer has to land on the same backend instance that handled the client's previous call. For teams running MCP servers on AWS or any load-balanced infrastructure, that removes a constraint that had forced session affinity into routing layers.

Under the earlier design, a remote MCP server carried session state inside the protocol itself. Load balancers had to pin a client to one instance, and operators needed a shared store to hold session data so that a reconnect or a failover did not break the conversation. That pushed teams toward sticky routing rules, session caches, and capacity planning tied to individual server instances rather than to aggregate request volume. The new spec drops those protocol-level sessions, so each request can be handled by any healthy instance.

The practical effect is simpler horizontal scaling. Instances become interchangeable, which means autoscaling groups can add or remove capacity without draining sessions or coordinating a shared session store. Rolling deployments and instance replacement stop being disruptive events for in-flight clients, since there is no session to migrate. AWS frames this as independent request routing: the routing layer only needs to pick a live backend, not the right one.

The tradeoff is that the concerns the protocol used to absorb now belong to other layers of the stack. Application state has to live somewhere the team chooses, whether a database, a cache, or the client itself. Retry behavior, idempotency, and observability also move out of the protocol and into the application and infrastructure, which means duplicate tool calls and repeated side effects become a design problem rather than something the session layer handled. Teams that relied on the protocol to deduplicate or sequence work will need to rebuild that logic.

MCP has become the default way to connect AI assistants and agents to external tools and data, and its remote deployment story has been a sticking point for anyone running servers at scale. Session affinity is a familiar operational tax in distributed systems, and removing it from the protocol lowers the bar for hosting an MCP server behind standard cloud load balancing. The revision also aligns MCP with how most HTTP services already operate, which should make it easier to fit into existing deployment pipelines.

What to watch is how quickly server implementations and client libraries adopt the stateless model, and whether the ecosystem converges on shared patterns for idempotency keys and retry semantics now that the protocol no longer supplies them. The spec removes a constraint, but it does not answer where state should go. That decision now sits with each team building on MCP.

Written in-house by the VintuxAI newsroom, in our own words. The story was first reported by InfoQ.