The Question This Research Is Working Through
MCP's 2026-07-28 specification removed the stateful session handshake that every MCP server built before it relied on, replacing it with a stateless request/response model designed to scale like ordinary web infrastructure. The protocol-level change is well documented — we cover what actually changed here. The open question we're working through is the one the spec update leaves to application builders: if the transport no longer holds state for you, where does state actually belong in an agent harness, and what does that do to how you should design tools in the first place?
The Old Assumption: State Lives in the Connection
Under the stateful model, it was easy — maybe too easy — to design a tool assuming the server remembered the last three calls in this session. A multi-step booking flow, a document being incrementally edited, a conversation being enriched with retrieved context: all of it could quietly live in server memory, keyed to a session ID the transport managed for you. That convenience had a cost most teams didn't feel until they tried to scale past one server instance, at which point the session-affinity requirement became a real infrastructure constraint — sticky load balancing, session replication, or a hard ceiling on horizontal scaling.
The New Pattern: State as an Explicit Handle
The replacement pattern the spec describes — a tool mints an explicit handle and the model passes it back as an argument — sounds like a small implementation detail, but it's actually a forcing function on tool design. State stops being something you can defer thinking about until you hit a scaling wall, and becomes something you have to design into the tool's argument schema from the first version. Practically, this means:
- Any tool that represents an ongoing process (a booking, a document, a multi-step form) needs to return an identifier for that process explicitly, not rely on the caller having "the same session" as a previous call.
- That identifier has to be treated as a real piece of your API surface — versioned, validated, and handled deliberately when it's invalid or expired — rather than an internal implementation detail the transport used to hide.
- The model calling your tools now carries more responsibility for correctly threading that identifier through a multi-step interaction, which puts more weight on clear tool descriptions and argument naming — a model that doesn't understand it needs to pass a handle back will simply drop the state.
What Multi Round-Trip Requests Change About Interactive Tools
The other half of the puzzle is interactivity. MRTR — the mechanism where a stateless call can return resultType: "input_required" and get retried with an answer — replaces what used to be a held-open stream during elicitation/create or sampling/createMessage. The architectural implication is that an interactive tool call is no longer one continuous operation from the harness's point of view; it's a short sequence of independent, resumable requests that happen to be about the same task. An agent harness built around the assumption of "start a tool call, wait, get the final result" has to be rearchitected around "start a tool call, possibly get an intermediate 'needs input' result, resolve it, resend" — a genuinely different control flow to build and test, not a drop-in replacement.
Where This Gets Hard: Backward Compatibility During Migration
The twelve-month deprecation window for Roots, Sampling, Logging, and the legacy HTTP+SSE transport means most production agent harnesses will run a mixed fleet for a while — some MCP servers already migrated to the stateless model, others still assuming session affinity. A harness that hard-codes an assumption about which transport model it's talking to will break the moment it's pointed at a server on the other side of that line. The more resilient design treats state-handle support as a capability to detect per-server (MCP's capability negotiation already gives you a place to do this) rather than something the harness assumes globally.
Our Working Position
Our current thesis, built out of the agent harness work we do: teams should treat this spec update as a forcing function to make state handling explicit in tool design now, even for MCP servers that aren't under any immediate scaling pressure — retrofitting explicit state handles onto a tool surface that quietly assumed session affinity is a much larger rewrite than designing for it from the start. The protocol removed the crutch; the tool design discipline it was hiding still has to get built, and it's cheaper to build it before you need the horizontal scaling than after.