AI’s most important protocol is getting a little bit easier to use

The Model Context Protocol is getting a foundational transport change: remote servers are moving from hidden protocol sessions to a stateless request model. The TechCrunch report describes the change as mostly invisible to end users but important for the companies running MCP at scale. The official MCP release-candidate announcement confirms that 2026-07-28 removes the protocol-level handshake and Mcp-Session-Id while adding routing, caching, tracing and other infrastructure changes.

Definition: Stateless MCP means the protocol server does not need to remember a hidden session between requests; each request carries the information needed for the server instance that receives it.

Example: A load balancer can send two tool calls from one agent to different server instances without first finding the machine that issued a session ID.

Key takeaway: The update makes large remote MCP deployments easier to operate, but every existing implementation needs a compatibility plan because the transport change is breaking.

Why does MCP need a stateless transport?

MCP is the interoperability layer that lets an AI client discover and call external tools and data services through a common protocol. A local server can keep a session in process memory without much trouble. A remote server serving many users across regions cannot assume that the next request will return to the same machine.

Under the older Streamable HTTP flow, the client initializes a connection, the server returns an Mcp-Session-Id, and later requests carry that identifier. The server farm then has to preserve or share the associated session state. Teams can use sticky sessions or a shared session store, but those add routing constraints and operational dependencies to a protocol that otherwise looks like ordinary HTTP.

The Arcade explanation of MCP going stateless makes the scale problem concrete: an MCP server running for thousands or millions of employees may sit behind a load balancer that routes each request to any available instance. If the protocol assumes one instance remembers the conversation, the load balancer is working against the protocol rather than helping it.

What does the new MCP session model do?

The 2026-07-28 specification removes the initialize/initialized handshake and the protocol-level Mcp-Session-Id for the new Streamable HTTP design. Protocol version, client information and capabilities travel with requests instead of being negotiated once and stored as hidden session state. A new server/discover method lets clients fetch server capabilities when they need them up front.

This is a smaller conceptual change than it sounds. The agent still has a conversation, and the application can still maintain state. What disappears is the protocol’s assumption that the server must remember the transport session. A request can arrive at any healthy server instance because the request itself contains the metadata needed to interpret it.

The change is similar to the web’s move away from server-pinned sessions. Stateless does not mean “nothing is remembered.” It means the infrastructure does not rely on one particular machine remembering it on behalf of every later request.

Does stateless MCP remove application state?

No. Applications that need continuity can keep state explicitly. A tool can return a handle such as a basket identifier, browser identifier or task identifier, and a later call can pass that handle back as an ordinary argument. The server can store the associated application state in a database or another explicit system.

That separation is useful because it distinguishes two kinds of continuity. Protocol state answers “which transport session is this?” Application state answers “which basket, browser, workflow or long-running job does the user mean?” The new MCP model removes the first dependency without forbidding the second.

Explicit handles can also make workflows easier to reason about. A model can carry a resource identifier between tools, compose it with another operation and expose the state transition in the tool arguments. Hidden session metadata is convenient until a gateway, region change or retry makes the hidden assumption fail.

What will developers have to migrate?

The release is a breaking change, not a transparent server optimization. A client built only for the 2025-11-25 protocol expects the initialization handshake and session ID. A server built only for that version expects the same behavior. Neither side can assume that upgrading one component will make the other understand the new transport automatically.

Version negotiation supplies a transition path when a client or server supports more than one version. A client can declare the version it speaks, and a compatible server can continue serving older clients while accepting newer ones. That reduces the risk of an ecosystem-wide cutover, but it does not remove the engineering work of testing, documenting and maintaining the compatibility matrix.

The first work item is therefore not “turn on stateless mode.” It is an inventory: which clients, SDKs, gateways and servers speak 2025-11-25, which can test 2026-07-28, and where protocol version negotiation is enforced. Teams should test failed retries, load-balancer hops, authorization flows and server-initiated requests rather than only checking that a simple tool call returns successfully.

What other infrastructure changes arrive with MCP 2026-07-28?

Stateless sessions are the headline, but the release groups several changes around production operation.

Routing becomes visible to infrastructure. Streamable HTTP requests use Mcp-Method and Mcp-Name headers so load balancers, gateways and rate limiters can route on the operation without inspecting the JSON-RPC body. Servers reject requests when headers and body disagree, which gives intermediaries a clearer and safer signal.

Tool and resource results become cache-aware. List and resource-read responses can carry ttlMs and cacheScope. Clients can learn how long a tools/list result is fresh and whether it can be shared across users. That matters for large deployments because capability discovery is a different workload from executing a user-specific tool call.

Distributed tracing gets a common vocabulary. The specification documents W3C Trace Context propagation in _meta, including the traceparent, tracestate and baggage keys. A trace can therefore follow a tool call from the host application through the MCP client and server into downstream services, provided each layer propagates the context.

Server-to-client requests are redesigned for statelessness. A server can request input while it is actively processing a client request, and the client can receive an InputRequiredResult, collect the answer and re-issue the call with the response and request state. The interaction no longer depends on holding an open server stream as the only way to complete a multi-step exchange.

These changes are not decorative protocol features. They address the practical questions that appear when an MCP server becomes a shared company service: Can the load balancer route it? Can the gateway cache safe discovery results? Can an operator trace one action through multiple services? Can a retry continue after another instance receives it?

What changes for MCP Apps and long-running tasks?

The release also gives extensions a more formal path. MCP Apps can let a server provide interactive HTML interfaces that hosts render in a sandboxed iframe, while tool actions still travel through the same JSON-RPC and consent path. The Tasks extension moves long-running work toward a lifecycle designed for the stateless model, with task handles and explicit get, update and cancel operations.

The distinction matters because not every capability belongs in the protocol core. A stateless transport can remain stable while UI and long-running workflow features evolve as negotiated extensions. The official release notes describe this as part of a broader feature lifecycle: extensions can mature independently, and deprecated features receive a defined window before removal.

For implementers, that creates a better place to experiment than repeatedly adding one-off behavior to the base transport. For users, it can eventually mean richer agent interactions without every MCP client having to understand every optional feature by default.

Is MCP actually easier to use after the breaking change?

For a developer building a remote MCP server from scratch, the protocol should be easier to reason about because there is less hidden session bookkeeping. The server does not need to coordinate protocol sessions across a fleet, and ordinary load-balancer behavior becomes a better fit. Session expiry and reconnection bugs have fewer protocol-level places to appear.

For a team that already runs MCP infrastructure, the near-term experience is the opposite: a breaking migration creates code changes, version testing and compatibility decisions. The protocol becomes easier after the rebuild, not necessarily during it.

That trade-off is normal for foundational infrastructure. A compatibility-friendly design can preserve old assumptions indefinitely, but eventually the cost of those assumptions becomes visible in every gateway, SDK and deployment. MCP’s change spends migration effort once to remove a constraint from every future remote deployment.

What should an MCP team do before July 28?

Map the protocol boundary. Record the versions spoken by every client, server, SDK and gateway. Do not assume that a package update changes the wire behavior of the whole stack.

Test without affinity. Run the same conversation across multiple server instances and regions. Verify that retries, tool discovery and authorization do not depend on returning to the instance that handled the first request.

Make application state explicit. Identify every behavior that currently relies on session metadata. Replace hidden transport assumptions with explicit, scoped handles where the application genuinely needs continuity.

Plan dual-version support. Use version negotiation where practical, but define an end date for old-version support. A compatibility layer without ownership can become permanent infrastructure nobody knows how to remove.

Instrument the migration. Add request-level tracing, record protocol-version mismatches and monitor session-expiration failures before and after the change. A successful local tool call does not prove that a distributed fleet is ready.

For a broader explanation of how MCP fits into an agent’s tool boundary, use the MCP overview linked above and see the discussion of MCP inside a coding-agent harness in Grok Build’s open-source agent architecture.

Why this protocol update matters for AI adoption

AI models receive most of the attention because benchmark scores and product launches are visible. MCP’s stateless rewrite is less glamorous: it changes handshakes, headers, routing and state boundaries. But those details determine whether an agent can reach a company’s real systems reliably, not just demonstrate a tool call on a laptop.

The most important result may be more first-party integrations. Companies can be enthusiastic about an MCP demo while hesitating to operate a server across regions, users and security boundaries. If 2026-07-28 removes enough transport friction, more teams may decide that an official MCP integration is maintainable rather than a permanent custom gateway project.

The protocol is not becoming simple because the AI problem is solved. It is becoming more honest about where state belongs. The transport should be routable and replaceable; the application should own the state it actually needs; the gateway should be able to observe and govern requests without decoding hidden session assumptions.

That is why this quiet standards update matters. Users may not notice the new handshake because there will no longer be one. Developers will notice the migration. If the ecosystem gets through it cleanly, the next generation of AI tools may feel more dependable not because the models changed, but because the plumbing finally stopped fighting the way production systems run.