9 min read - Stateless MCP Migration: Keep State Explicit and Retries Safe

On 1 September 2026, AWS published a new architecture guide for the stateless Model Context Protocol. It turns the MCP 2026-07-28 revision into deployment advice: remove sticky routing and shared session stores once older clients have left, let any server instance handle a request, and make tools safe to retry.

The advice is useful, but the word "stateless" can invite a bad shortcut. A team may see removable infrastructure before it has identified what the old session was carrying. The official MCP release is precise on this point. MCP removed protocol-level sessions; it did not make business workflows, approvals or long-running jobs stateless.

For a startup or SME operating its own MCP servers, the buyer question is not "Can we delete the cache?" It is "Can every request reach another instance without losing context, repeating an action or crossing a tenant boundary?" Answer that first. Infrastructure savings come later.

Stateless protocol, stateful work

Revision 2026-07-28 removes the initialize and initialized exchange and the Mcp-Session-Id header. Each request carries its protocol version and client capabilities. Servers expose a server/discover method, although a client does not have to call it before sending a tool request. The specification changelog also says that list results no longer vary by connection.

Those changes separate transport continuity from application continuity. A quote request may still need a draft identifier. A support workflow may need a case number, and an export job may need a job handle. The new model asks the server to mint an explicit identifier and the client or model to return it as an ordinary tool argument.

Explicit state is easier to inspect, but visibility is not authorization. A model can repeat, alter or present an identifier that belongs to another request. Each tool must resolve the identifier under the current user, tenant and permission context. Treat a handle as untrusted input, not as proof that the caller owns the underlying record.

Our earlier guide to MCP permissions and safe tool access covers the wider server-trust question. The migration adds a specific check: any state that was implicitly bound to a session now needs an explicit owner and validation rule.

Inventory what the session was hiding

Do not start by deleting load-balancer rules. Trace one real workflow across several calls and write down every fact that later calls assume. Some facts belong in durable business records; others are short-lived continuation data. The distinction controls recovery, retention and access.

This table is an Exceev migration aid, not a structure required by MCP. Its purpose is to expose design work that session middleware may have hidden. If a team cannot name where a fact will live, it is too early to remove the old path.

Avoid putting a whole business record into a continuation token merely to avoid a datastore. Tokens reach models, clients, logs and tracing systems. Use an opaque reference for durable records. For short-lived protocol continuation, the specification uses requestState; AWS notes that servers must treat it as untrusted and protect its integrity with HMAC or authenticated encryption.

Run two protocol eras before retiring one

An SDK upgrade does not prove that traffic uses the new revision. The official TypeScript migration guide says that hand-built v2 clients and servers keep the 2025-era wire behaviour by default. Speaking 2026-07-28 requires an explicit opt-in.

The same guide documents an automatic negotiation mode that probes with server/discover, then falls back when it positively identifies a legacy peer. It also treats an authentication failure, server error or HTTP timeout as a failure rather than evidence that the peer is old. That distinction prevents an outage from being misreported as a compatibility result.

Plan a dual-era window for an existing service. Log the protocol version on each request and separate modern traffic, legacy traffic, negotiation failures and authentication failures. Exercise the combinations you actually operate: new client with new server, new client with old server, old client with a dual-era server, and calls that pass through the production gateway.

Keep session affinity and the old session store while any supported client still depends on them. AWS's 1 September guide gives the same warning. Choose a retirement condition based on observed traffic and support commitments, then remove the compatibility infrastructure in a controlled change. A calendar date without traffic evidence is weak proof.

Design retries around business effects

The transport change also alters recovery. AWS explains that broken response streams can lead clients to re-issue a call, so write tools need idempotent execution. A retried read is usually harmless. A retried create_invoice, send_message or approve_order may not be.

Give each business operation an idempotency key that survives a network retry and, when appropriate, an agent retry. Store the key beside the outcome before returning success. A repeated call with the same key and compatible arguments should return the stored outcome instead of applying the effect again. If the arguments differ, reject the reuse rather than guessing which request the caller intended.

Protocol request IDs, trace IDs and business idempotency keys solve different problems. A trace follows execution. A JSON-RPC ID matches a response to a request. The idempotency key prevents a business effect from occurring twice. Do not substitute one for another because they happen to be unique in a test.

Build the failure test around the awkward moment: the external system accepted the action, but the MCP client never received the response. Cut the connection there, resend the call through another server instance and inspect both the MCP result and the target system. A unit test that mocks the external side effect cannot establish this property by itself.

Rebuild evidence per request

Removing the session changes the unit of observation. Record the protocol version, authenticated caller, tenant, tool name, result type, business operation key and trace link for each call. Do not put credentials, full tokens or sensitive tool arguments into general logs.

The new Streamable HTTP binding requires MCP-Protocol-Version, Mcp-Method and, for named operations, Mcp-Name headers. The transport specification also requires the protocol header to match the version in the request body. These fields can support routing and metrics without parsing every tool argument, but they do not replace an audit record for the resulting business action.

Link the request trace to the durable operation record. That gives support and security teams a path from "the agent called a tool" to "the order changed once under this identity." Our article on the minimum agent audit trail goes deeper into evidence for autonomous actions.

A migration rehearsal for a small team

Use a contained workflow with a reversible or sandboxed side effect. First, capture the current session path, supported client versions and every store or routing rule it touches. Then expose a dual-era server and measure which clients negotiate the modern revision.

Move application state to explicit records or protected continuation tokens. Send successive calls to different instances and restart one instance between steps. Test another tenant's identifier, an expired handle and an altered requestState token. Each should fail without revealing whether the referenced record exists.

Next, interrupt a write after the target accepts it but before the client sees success. Retry through another instance and confirm that the target records one effect. Check that logs connect both attempts to the same business operation without exposing the state token.

Only after the legacy traffic reaches the agreed retirement condition should the team disable affinity and remove the session-only store. Watch error, latency and duplicate-effect signals during the change. Keep the rollback path until the observation window closes.

Sources and limitations

• The MCP maintainers' 2026-07-28 release note, reviewed 2 September 2026, establishes the removal of protocol sessions, handshake changes and explicit state-handle pattern.
• The official MCP specification changelog, reviewed 2 September 2026, supplies the normative change list for sessions, discovery and Multi Round-Trip Requests.
• The official TypeScript SDK migration guide, reviewed 2 September 2026, documents explicit opt-in, negotiation and failure behaviour for that SDK. Other SDKs can differ.
• AWS's 1 September architecture guide, reviewed 2 September 2026, independently maps the revision to deployed server architecture, compatibility, retries and operations.

The MCP revision dates from 28 July; the current trigger is AWS's 1 September deployment analysis. The sources do not measure migration cost, performance or reliability across representative SME systems. Managed MCP hosts may preserve compatibility or application state differently. The inventory, tests and retirement conditions above are Exceev's operational synthesis, not an MCP or AWS migration standard. Validate them against the SDKs, hosts, data duties and change process in your own system.

Remove infrastructure only after the evidence exists

A stateless protocol can simplify scaling and failure recovery. It also makes hidden assumptions visible. Keep business state explicit, authorize every handle, make writes safe to repeat and observe the protocol version in real traffic. Then remove the session infrastructure that no supported path uses.