MCP Went Stateless: What Changes for Agent Tooling

What MCP 2026's stateless core, explicit state handles, MRTR, caching, Tasks, and OAuth changes mean for production agent tooling.

MCP Went Stateless: What Changes for Agent Tooling

If you deployed a remote MCP server before July 2026, the transport session could quietly become part of your application architecture.

The client initialized a connection. The server returned an Mcp-Session-Id. Later requests carried that ID, and server-to-client interactions often depended on a stream staying open. It was convenient when one client talked to one server process. It became less convenient when you added load balancers, rolling deployments, retries, or multiple server instances.

The MCP 2026-07-28 specification changes that model. The protocol core is now stateless: no initialize handshake, no protocol session ID, and no assumption that the next request reaches the same server instance.

This is not just protocol news. It changes where agent-tooling engineers keep state, how approvals work, what gateways can see, and which failures the application must handle explicitly.

In my earlier article, Claude Code is not a Chatbot... It Is an Execution Engine, I argued that reliable agent workflows come from deliberate context, rules, skills, and tools. The new MCP architecture applies the same principle at the protocol boundary: make important state visible and intentional instead of hiding it inside a connection.

Hidden sessions looked convenient—until production

The older Streamable HTTP lifecycle looked roughly like this:

1. The client sent initialize with its version and capabilities.
2. The server optionally created a session and returned Mcp-Session-Id.
3. The client repeated that ID on later requests.
4. Some server-to-client requests relied on the active connection or response stream.

That model was not automatically bad. Sessions are useful when you truly need connection-scoped context. The problem was that protocol state and application state were easy to mix together.

A server might keep a selected workspace, temporary credentials, a browser instance, or a partially completed operation inside the session. Once it did, the infrastructure had to preserve that invisible relationship. Teams often needed sticky routing, a shared session store, or recovery logic for sessions that disappeared during a deployment.

The session also made failures ambiguous. If a client reconnected, which state still existed? If a request reached another instance, could that instance reconstruct the context? If a stream broke after a side effect but before the response arrived, was it safe to retry?

MCP 2026 does not answer those questions for your application. It removes the protocol mechanism that allowed you to avoid answering them.

Every request now has to stand on its own

In the modern lifecycle, each request carries the information needed to interpret it. For Streamable HTTP, the protocol version and routing information also appear in headers:

POST /mcp HTTP/1.1
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search_repo

{
  "jsonrpc": "2.0",
  "id": 41,
  "method": "tools/call",
  "params": {
    "name": "search_repo",
    "arguments": {
      "query": "Mcp-Session-Id"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "engineering-agent",
        "version": "3.2.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

A server must implement server/discover so clients can inspect supported versions and capabilities. A client does not have to call it before every operation—or at all—but it is useful for version selection, UI, and compatibility probing.

The operational benefit is straightforward: any request can reach any compatible instance. You can use ordinary round-robin balancing without preserving a protocol session or teaching every worker about every connected client.

There is a cost. Metadata that used to be exchanged once now travels per request. More importantly, transport continuity no longer protects application continuity. The official changelog notes that if a response stream breaks, the in-flight request is lost and the client reissues it with a new JSON-RPC ID.

Stateless does not mean retry-safe. A tool that creates a deployment, charges an account, or deletes a resource still needs idempotency keys, operation records, or another way to recognize a repeated intent.

State is now a handle, not ambient context

Removing protocol sessions does not require your application to forget everything between calls. It requires the state to have an explicit address.

Imagine an agent that opens a repository workspace and then runs several tools against it. The first tool can return an opaque handle:

{
  "resultType": "complete",
  "structuredContent": {
    "workspaceHandle": "ws_7f3d9a..."
  },
  "content": [
    {
      "type": "text",
      "text": "Workspace is ready."
    }
  ],
  "isError": false
}

The agent passes that handle to the next tool as an ordinary argument:

{
  "name": "run_checks",
  "arguments": {
    "workspaceHandle": "ws_7f3d9a...",
    "suite": "integration"
  }
}

The actual workspace can live in a database, object store, job system, browser service, or another MCP server. The handle only identifies it.

This is more explicit than a session variable. The model can see which state belongs to which operation, the host can log the relationship, and a workflow can pass the handle between tools or resume later.

It is also easier to misuse. A state handle should be treated like a reference to protected server-side data, and sometimes like a bearer credential:

• Generate handles with enough entropy to resist guessing.
• Bind every lookup to the authenticated user, tenant, and allowed operation.
• Apply expiry and cleanup rules.
• Keep secrets and sensitive state on the server, not inside the handle.
• Avoid placing meaningful internal IDs in a model-visible value.
• Recheck authorization on every use instead of trusting possession alone.

The protocol made the state visible. It did not make the state secure for you.

MRTR turns missing input into a retry protocol

Agent tools often need more information after they start. A destructive action may need approval. A deployment may need a target environment. A third-party connection may require the user to finish an authorization flow.

Older MCP versions handled these cases with server-initiated requests such as elicitation/create. The server asked the client a question while processing the original call, which fit a bidirectional session but did not fit a stateless request/response core.

Multi Round-Trip Requests, or MRTR, changes the shape. The server returns an interim input_required result:

{
  "jsonrpc": "2.0",
  "id": 51,
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Delete the three generated files?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "approved": { "type": "boolean" }
            },
            "required": ["approved"]
          }
        }
      }
    },
    "requestState": "opaque-server-state"
  }
}

The client gathers the answer and retries the original method with a new request ID:

{
  "jsonrpc": "2.0",
  "id": 52,
  "method": "tools/call",
  "params": {
    "name": "delete_generated_files",
    "arguments": {
      "workspaceHandle": "ws_7f3d9a..."
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "approved": true
        }
      }
    },
    "requestState": "opaque-server-state"
  }
}

Now every round trip is independently routable. Another server instance can continue the operation if it can validate or resolve requestState.

The implementation challenge moves into the tool handler. It must be safe to enter the same operation more than once. It must not delete the files before approval and then delete them again after the retry. It must handle accept, decline, and cancel, limit repeated input rounds, and expire abandoned state.

The elicitation specification also draws an important security boundary: form mode must not collect passwords, API keys, access tokens, or payment credentials. Sensitive interactions belong in URL mode, where the user interacts directly with the external page and the secret does not pass through the MCP client.

MRTR makes approvals possible without a hidden session. It does not turn an approval dialog into a transaction system.

Routing, caching, and Tasks move MCP closer to normal infrastructure

The stateless core is the headline, but several smaller changes make it practical.

Gateways can route on headers

Streamable HTTP requests now include Mcp-Method and Mcp-Name. A gateway can route, meter, and apply policy to tools/call for a specific tool without parsing the JSON body first.

Servers must reject a request when the headers disagree with the body. That validation matters. A gateway should not treat a caller-controlled header as proof that the body contains a harmless operation.

Discovery and lists are cacheable

Results from tools/list, prompts/list, resources/list, resources/read, and resources/templates/list now include ttlMs and cacheScope. Tool lists should also have deterministic ordering.

This sounds minor, but it can remove a lot of repeated discovery traffic and keep tool catalogs stable for upstream prompt caches. A client can know how long a result is fresh and whether a shared intermediary may cache it.

The dangerous mistake is marking user-specific discovery data as public. The other mistake is choosing a long TTL for a tool catalog that changes frequently. Caching is now defined by the protocol, but invalidation is still an engineering decision.

Long-running work has a durable shape

Tasks moved from the experimental 2025 core into the io.modelcontextprotocol/tasks extension. A server can return a task handle for a long operation, and the client can drive it with tasks/get, tasks/update, and tasks/cancel.

That fits CI pipelines, cloud deployments, batch imports, and human review steps far better than holding one HTTP response open for twenty minutes. The Tasks extension also lets work pause at input_required, receive an answer through tasks/update, and continue.

There are two migration warnings here.

First, a task still requires durable state. If the task handle survives a disconnect but the task record lived only in one worker's memory, the durability is imaginary.

Second, the new extension is not wire-compatible with the experimental Tasks API from 2025-11-25. The old tasks/result, per-call task parameter, and tasks/list lifecycle do not simply roll forward. Clients and servers that shipped the experimental API need an explicit compatibility path or a coordinated upgrade.

Authorization hardening is part of the migration

Authorization remains optional in MCP, but protected remote HTTP servers should treat the 2026 changes as production requirements, not cleanup work.

The updated authorization specification tightens several weak edges:

• Authorization servers should include iss in authorization responses, and clients must validate a present issuer before sending the code to a token endpoint.
• Persisted client credentials must be bound to the issuer that created them. They cannot be reused with another authorization server.
• Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents, while remaining available for backward compatibility.
• Clients using Dynamic Client Registration must set an appropriate application_type, which matters for desktop and CLI redirect URIs.
• Servers can challenge for operation-specific scopes, allowing clients to request the minimum initial access and step up later.

These changes reduce mix-up risks and overbroad authorization, but they also expose assumptions in existing clients. If your credential cache is keyed only by MCP server URL or client name, it deserves another look.

Some features are leaving the center

Roots, Sampling, and Logging are deprecated in the 2026 release. They remain available during the deprecation window, but new implementations should not build around them.

The recommended directions are deliberately ordinary:

• Pass working directories through tool arguments, resource URIs, server configuration, or environment variables instead of Roots.
• Integrate with an LLM provider directly instead of asking the MCP client to perform Sampling.
• Use stderr for stdio servers or OpenTelemetry for structured observability instead of protocol Logging.

The legacy HTTP+SSE transport is also deprecated in favor of Streamable HTTP. The specification's new feature lifecycle guarantees at least a twelve-month deprecation window, so this is a migration signal rather than an immediate shutdown.

A practical migration checklist

I would migrate a production MCP integration in this order:

1. Inventory state before changing transports. List everything currently stored by session ID: user identity, selected resources, temporary files, browser sessions, pending approvals, and in-flight jobs.
2. Separate transport state from application state. Remove the state that only existed to maintain a connection. Give real application state an explicit handle and a durable owner.
3. Choose a version strategy. Upgrade to an SDK that supports 2026-07-28, then decide whether to pin the new version or probe with server/discover and fall back for older peers.
4. Make tool side effects retry-aware. Add idempotency keys or operation records anywhere a lost response could cause a duplicate deployment, payment, message, or deletion.
5. Implement the complete MRTR loop. Support new request IDs, exact requestState echoing, multiple input rounds, decline and cancel paths, expiry, and user-bound state validation.
6. Set routing and cache metadata deliberately. Validate Mcp-Method and Mcp-Name, choose honest TTLs, and never mark personalized results as publicly cacheable.
7. Redesign long-running operations as Tasks. Use a durable task store, respect polling intervals, make cancellation cooperative, and migrate away from the 2025 experimental wire format.
8. Update authorization storage and validation. Key credentials by issuer, validate iss, review redirect registration, and test step-up scope challenges.
9. Plan exits from deprecated features. Remove new dependencies on Roots, Sampling, Logging, and HTTP+SSE even if compatibility support remains.
10. Test the failures you previously hid with sessions. Send consecutive calls to different instances. Restart a worker between rounds. Drop a response after the side effect. Reconnect during a task. Exercise both modern and legacy clients.

This is a good place for contract and integration tests. My Test Driven Development overview covers the basic feedback loop, but protocol migration tests should focus on observable behavior across process boundaries rather than internal SDK methods.

When a CLI or skill is still simpler than MCP

A better MCP does not mean every command needs an MCP server.

Use a skill when the agent mainly needs reusable instructions: how your team releases an app, reviews a migration, or validates a database change.

Use a CLI when the capability is local, deterministic, scriptable, and already fits the operating system's process model. In Claude Code Meets Android CLI: Build, Run, and Test, the useful boundary is simple: the agent plans the workflow, while a CLI exposes Android-specific operations.

MCP earns its extra surface when a capability must be shared across different agent hosts, discovered dynamically, protected across a remote trust boundary, or resumed through approvals and long-running tasks.

A practical rule is:

• Procedure only: write a skill.
• Local executable capability: expose a CLI.
• Reusable capability across hosts or trust boundaries: consider MCP.

Protocol flexibility is valuable, but the cheapest reliable interface is usually the best one.

Final thoughts

MCP 2026 did not remove state. It moved state out of the protocol session and made applications name it, secure it, and recover it deliberately.

It also replaced held-open interaction with retried requests, gave long-running work a task handle, made discovery cacheable, exposed operations to normal HTTP routing, and tightened authorization around real OAuth deployments.

I like the direction because the failure modes become easier to see. The trade-off is that server authors now own more of the semantics that a connection used to hide: idempotency, durable state, authorization binding, expiry, and recovery.

Where is state hiding in your current agent tooling—in the transport, inside tool arguments, or in an external job system? I would be interested to hear which part of this migration looks straightforward and which part will require a redesign.