AI NewsInfrastructureAnnouncement
AWS says the new MCP specification drops session affinity and lets remote servers run behind a plain load balancer
AWS says the latest Model Context Protocol specification drops protocol-level sessions, so a remote MCP server no longer needs sticky routing or shared session storage, and can run behind any load balancer or on AWS Lambda.
Image: InfoQ
Why it mattersTeams running remote MCP servers can retire the sticky-session layer and the shared session store the old spec required, and pick a Lambda-style request-response deployment instead of a long-lived stateful one.
A team running a remote Model Context Protocol server today has to keep every request from one client on the same server instance, and share the session across instances if a client reconnects. AWS says the newest MCP specification removes that constraint at the protocol layer.
In an AWS Architecture Blog post first published on 1 September and covered by InfoQ on 25 September, Anand Komandooru, Steven DeVries and Haleh Najafzadeh describe how the updated specification removes the initialize and initialized handshake and the Mcp-Session-Id header. Requests can now be routed to any server instance behind a conventional load balancer. AWS says the spec also adds an optional server/discover operation for clients that want to read server capabilities before making tool calls.
What the deployment loses
AWS says the change eliminates infrastructure that existed only to keep MCP protocol state. Session-affine routing at the load balancer, and the shared store used to hand a session off between instances, are both no longer required by the protocol. AWS calls out AWS Lambda as a deployment option that now fits, because the request-response model no longer needs a persistent session connection.
Stream resumability has also been removed. AWS says clients may need to retry interrupted operations themselves, and that idempotency for tool calls with side effects is now more important than it was under the old spec.
What the deployment still owns
The AWS authors quote software engineer Michael Madsen on LinkedIn: "The protocol is stateless. Your application doesn't have to be." AWS maps the change to its Well-Architected guidance for agentic AI, which covers monitoring, tracing, security and tool integration. Application state, retries and observability all shift out of the protocol and into the surrounding infrastructure.
A new pattern in the spec, MRTR, replaces server-initiated requests that used to hold streams open. Multi-step interactions run through input_required responses followed by the client's next request. New Mcp-Method and Mcp-Name headers give gateways enough information to route and throttle by tool call, and W3C Trace Context lets a request thread through a distributed tracing system. Caching gets two new controls, ttlMs and cacheScope.
The migration window
Existing MCP servers still need a transition path. InfoQ points to the Apify MCP server project, which is adding a stateless implementation next to its existing sessionful server so routing and conformance tests can cover both protocol versions at once. AWS says its own recommendation is to track protocol versions at the gateway and keep the session infrastructure in place until traffic on the older clients has drained. The MCP project has also published a feature lifecycle policy that gives deprecated capabilities a defined migration window.
For a team running a remote MCP server, this is a protocol change that lands mostly in the deployment rather than in the application code. The sticky-session layer at the load balancer, and the shared session store that made client reconnects work under the old spec, are the two operating pieces that come out.
Source
This item was written by an AI system from the linked source. Reveneau is responsible for what it publishes.
Get AI News in your inbox
New developer tools, model and agent releases, and how teams are actually using them to release software. Short, and only when there is something worth reading.
