MCP protocol removes session state and changes how remote servers scale on AWS. The new specification shifts continuity into explicit identifiers and request context.
When MCP protocol removes session state, not only the request format changes. The cost of horizontal scaling itself changes. The old session-based mode required sticky routing, shared session store, and additional plumbing for observability if the server operated on multiple instances. For AWS, this meant that part of the infrastructure existed not for business logic but to compensate for the limitations of the protocol.
The new approach makes the protocol stateless, but it does not make the application “stateless” in the absolute sense. This is an important fork in the road. State is still permissible, but it moves to the datastore, and only the identifier is passed to the model and subsequent calls. This compromise is closer to conventional REST discipline: the server is no longer required to remember the user through the same instance, and any instance can handle the next request.
The choice here is pragmatic. Instead of being tied to a session, an explicit context is used at the level of each request. The first message from the client can be an immediate tool call. If the client needs to understand the server’s capabilities in advance, they call the new server/discover, which returns supported protocol versions, capabilities, and identity. This reduces the coupling between the client and a specific server instance. But there is also a trade-off: developers who built the system around session semantics need to rebuild the gateway, routing, and monitoring.
At the implementation level, this removes several familiar crutches. The old protocol required maintaining ALB stickiness, shared session stores like DynamoDB or ElastiCache, and separate routing rules. In the new protocol, this is not required if we are specifically talking about session infrastructure built for the old scheme. AWS directly recommends instrumenting the gateway to log the protocol version per request, and the legacy lane should only be turned off when traffic on the old version has dropped to zero.
The most noticeable change in system behavior is related to Multi Round-Trip Requests. Previously, the server could hold the stream and push requests to the client mid-call. Now, the server returns input_required with an inputRequests map and an opaque requestState token. The client completes elicitations, sampling calls, or root queries and then resends the original call with inputResponses. This removes the dependency on long-lived connections and shared session state. And this is why the scheme is suitable for AWS Lambda, where holding a connection for an intermediate step is unnatural.
From an operational model perspective, this looks like a cleaner separation of responsibilities. The server does not store the dialogue chain in memory, and resuming work is possible on any instance because requestState carries the necessary context. This design aligns better with observability, security, and reliability, which the AWS Well-Architected Agentic AI Lens considers critical for agentic workloads. At the same time, the protocol itself does not eliminate complexity. It simply shifts it from a hidden session layer to explicit request and state boundaries.
It is also important that the transition is not instantaneous. For clients of the 2025 era, a backward-compatible lane is maintained, so old and new versions can coexist. But this means that legacy infrastructure cannot be removed prematurely. Until the complete departure of old clients, ALB stickiness and session store must remain operational. There is no elegant shortcut: first measurement, then sunset date, then decommission.
Architecturally, the new version also disciplines changes. Long-lived streams have not disappeared, but now subscriptions/listen are used as an opt-in POST-response stream. This requires a closer examination of idle timeouts on load balancers, proxies, and compute tiers. Concurrently, deprecations have appeared with a strict window, a minimum of twelve months until removal, as well as a feature lifecycle policy, extension framework, and conformance suite. For the platform team, this means less risk of sudden drift in the protocol and more manageability during migrations.
The conclusion here is not that MCP has become “simpler.” The conclusion is that complexity has become explicit and better distributed. The stateless core eliminates an entire class of compensating infrastructure, but in return requires careful handling of identifiers, cacheScope, ttlMs, routing, and versioning. For remote MCP servers on AWS, this looks like a mature architectural solution: less hidden magic, more predictability, better alignment with the Well-Architected approach. If a server is being built today, the target version 2026-07-28 appears to be a more natural foundation than inheriting a session-based model.