MCP 2026-07-28 spec: what a stateless protocol core means for agent architecture

The most important change in the Model Context Protocol (MCP) 2026-07-28 specification is not a new tool type or an SDK convenience. It is a change in where the protocol keeps meaning. MCP is moving from a bidirectional, stateful protocol toward a request/response core in which each request carries enough context to be handled independently.

That sounds like a transport detail until you operate an agent system behind a load balancer. Under the older model, a remote MCP server could establish a protocol session, retain the session identifier, and rely on the next request returning to the same logical connection or to a backend with access to shared session storage. The new model removes that protocol-level dependency. A request can reach any healthy instance, just like an ordinary HTTP API request.

The result is not “all MCP applications must now be stateless.” It is more useful than that: protocol state and application state are separated. The protocol no longer hides conversation continuity in a transport session. If an agent workflow needs continuity, the application must represent it explicitly and choose how to store and secure it.

What the 2026-07-28 core removes

The release announcement retires the initialize/initialized exchange and the Mcp-Session-Id header for the new protocol mode. Instead of negotiating client information once and then referring to an implicit session, each request carries its protocol version, client identity, and client capabilities in _meta. Clients that want capability information before making a normal call can use the new server/discover RPC, but discovery is optional.

A simplified request from the official announcement looks like this:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
 "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

The important property is not that every field is repeated for its own sake. It is that a server instance does not need to reconstruct protocol context from a connection that it did not create. A plain round-robin balancer can distribute calls without sticky sessions, and an instance can be replaced without first migrating its MCP session table.

This also clarifies a common misunderstanding. “Stateless protocol” does not mean “the server cannot remember anything.” It means that memory required by the application is no longer smuggled in through the protocol lifecycle. A shopping basket, browser handle, approval record, or long-running job can still exist. It should be identified explicitly and passed as data that the application understands.

Horizontal scaling becomes a normal HTTP problem

For a remote MCP deployment, the immediate architectural gain is simpler horizontal scaling. A stateless MCP endpoint can sit behind a conventional load balancer, gateway, CDN edge, or serverless HTTP runtime. New instances can start and stop without a session-draining ritual specific to MCP. Capacity can be added by increasing the number of replicas, and a failed instance does not strand every client session attached to it.

That does not eliminate operational design. The service still needs authentication, authorization, rate limiting, observability, idempotency, and a durable data layer where the product requires one. It does remove one awkward constraint: the load balancer no longer has to preserve an invisible protocol conversation.

The architecture therefore looks closer to a normal API tier:

1. An MCP-aware edge or gateway terminates TLS and applies identity and policy.
2. Routing sends requests to any compatible MCP instance.
3. Instances validate the request, call tools, and read or write external services.
4. Durable state lives in a database, object store, queue, cache, or another explicit system of record.
5. Logs and traces correlate individual requests and application handles rather than assuming a single open stream explains the workflow.

This is especially useful for agent platforms that host many tenants or dynamically select tools. Capacity planning can focus on request rates, tool latency, concurrency, and downstream limits instead of the number of protocol sessions held open on each worker.

There are still reasons to use affinity in a particular application. A local cache may make a sticky route faster, or a specialized worker may own an expensive in-memory model. But affinity becomes an optimization or an application choice, not a requirement imposed by the MCP protocol core.

Sessions have not disappeared; implicit sessions have

The migration question most teams should ask is not “How do we recreate Mcp-Session-Id?” It is “What state did we accidentally store there?”

Some integrations used a protocol session as a convenient container for user identity, selected workspace, authorization context, tool results, or a partially completed workflow. Those values have different lifetimes and security properties. Putting them behind one opaque identifier made it easy to overlook expiry, tenancy boundaries, replay behavior, and recovery after a worker restart.

The stateless model encourages a more explicit design. A tool can return a handle such as basket_id, browser_id, workspace_id, or task_id. The model or client passes that handle to the next tool call. The service resolves it against a durable store and checks that the caller is allowed to use it.

Making the handle visible to the model can be useful: the agent can carry a browser or basket identity between tools instead of depending on hidden transport state. It also creates a prompt and authorization surface. Bind handles to the authenticated caller, enforce ownership, define expiry, and decide whether retries must be idempotent. For durable workflows, use a database or task system; for large artifacts, store the artifact externally and pass a reference with explicit access rules.

Transport choices: Streamable HTTP gets the production path

The announcement also changes what operators can do at the HTTP edge. Streamable HTTP requests must include Mcp-Method and Mcp-Name headers. A gateway, WAF, rate limiter, or metrics layer can route and meter requests from headers without parsing JSON-RPC bodies. Servers reject requests where the headers and body disagree, which prevents the edge from authorizing one operation while the payload asks for another.

For production MCP services, that makes Streamable HTTP a better fit for ordinary infrastructure. It remains compatible with HTTP tooling, while the protocol no longer depends on a permanently held-open bidirectional stream for every interaction. The legacy HTTP+SSE transport is officially deprecated with a year-long transition window, so new deployments should avoid building their long-term architecture around it.

MRTR, or Multi Round-Trip Requests, fills an important gap created by the stateless design. Some tools need a confirmation or another value while a call is in progress. The old pattern used server-initiated requests over a held-open stream for operations such as elicitation and sampling. Under MRTR, the server can return resultType: "input_required" with the requests it needs answered. The client then retries the original call with the answers in inputResponses.

For an agent architecture, this is a meaningful change in control flow. “Ask the user and continue” becomes an explicit resumable protocol exchange, not a hidden dependency on a live connection. Clients and orchestrators need to persist enough information to resume safely, display the request, validate the answer, and avoid executing the original action twice.

Externalize the state that agents actually need

A stateless MCP core does not solve workflow durability by itself. It makes the boundary visible. Agent builders should decide which state belongs in which layer:

• The MCP request carries protocol metadata and the arguments for this operation.
• The agent runtime owns conversation history, planning context, model calls, and user interaction policy.
• The MCP server owns tool implementation and the application records needed to execute it safely.
• A task or job system owns long-running work, retries, progress, and cancellation.
• Databases and object stores own durable business data and large outputs.
• Observability systems own traces, audit records, and operational events.

The 2026-07-28 release moves Tasks into the io.modelcontextprotocol/tasks extension. A server can return a task handle for work that should not complete in one request, and the client can use tasks/get, tasks/update, and tasks/cancel. This is a better place for long-running state than an open protocol session. It also gives operators a concrete lifecycle to monitor: created, progressing, completed, failed, expired, or cancelled.

The same principle applies to caching. Responses from tools/list, prompts/list, resources/list, and resources/read now carry ttlMs and cacheScope, with deterministic ordering. Clients can cache catalogs and resource results according to the server’s hints instead of treating every reconnect as a complete rediscovery. Stable list output also helps upstream prompt caches: a tool catalog that changes order for no reason can cause needless cache misses in an agent system.

What integrators need to change

A practical migration plan should be more specific than “upgrade the SDK.” Start by inventorying every place the integration depends on the old lifecycle.

First, test protocol negotiation and compatibility. A new client or server may need to serve 2026-07-28 and continue to interoperate with older implementations. Confirm how the SDK you use selects the revision, whether it falls back to the earlier handshake, and which transport mode is enabled explicitly. The release notes emphasize that SDK behavior differs by language and version; do not infer the wire behavior from a package upgrade alone.

Second, remove assumptions about initialize, initialized, and Mcp-Session-Id from middleware, tests, metrics, and routing. If a reverse proxy keys a session table on that header, decide whether it should become ordinary request routing or be replaced by an explicit application handle.

Third, make HTTP edge policy header-aware. Validate Mcp-Method and Mcp-Name, log them as structured fields, and ensure a gateway does not trust a header without checking the request body. Add method-level rate limits and authorization rules where the risk profile requires them.

Fourth, model state and retries. Identify every tool that assumes a previous call happened on the same worker. Give it an explicit handle or move the state to a durable service. Define idempotency behavior for retries, especially for writes, payments, provisioning, and destructive operations. Exercise instance termination between two calls; that failure test is more valuable than a happy-path test that keeps one process alive.

Fifth, implement MRTR and Tasks according to their actual semantics rather than emulating old server-initiated calls. Test approval prompts, missing input, reconnects, duplicate responses, task polling, cancellation, and expiry. Agent runtimes should persist resumable state outside the MCP transport.

Finally, review authorization. The revision adds issuer validation guidance aligned with RFC 9207, binds client credentials to the issuer that minted them, and formally deprecates Dynamic Client Registration in favor of Client ID Metadata Documents. These are not consequences of statelessness alone, but they are part of the same integration release and should be included in the migration test plan.

A better foundation for agent infrastructure

MCP 2026-07-28 does not turn every agent into a stateless function. It gives agent systems a cleaner protocol boundary. Requests can be routed like HTTP requests, services can scale without shared protocol sessions, and application state can be designed as visible, testable data with an owner and a lifecycle.

That shift matters because agent workloads are not single conversations inside one process. They are distributed workflows with retries, approvals, background tasks, tool catalogs, identity, and partial failure. A hidden session can make a demo feel simple while making production recovery difficult. The stateless core asks integrators to pay the complexity where it belongs: in explicit application state, durable workflow systems, and observable request handling.

For a new remote MCP service, start with stateless Streamable HTTP, ordinary load balancing, explicit handles, and a durable state model. For an existing service, migrate incrementally: keep compatibility where necessary, remove sticky-session assumptions, test failure between calls, and adopt Tasks or MRTR for workflows that used to depend on a held-open connection. The payoff is not only more replicas. It is an agent architecture that behaves predictably when a worker disappears, traffic moves, a user returns later, or a tool call must be retried.