MCP's 2026-07-28 spec goes stateless: what changes for tool builders
On July 28, 2026, the Model Context Protocol shipped a new spec revision. It is the largest structural change MCP has had. The headline, in the spec's own words: "MCP is transforming from a bidirectional stateful protocol into a request/response stateless protocol." If you build MCP servers or the agents that call them, this changes how you deploy. It also changes how you plan the next year.
From stateful streams to stateless requests
The original design kept a two-way stream open between client and server for the life of a session. That is simple to reason about and hard to scale. Each request depends on state held in memory by one connection. So a load balancer cannot freely route requests.
The 2026-07-28 revision moves to a request/response model. Each request carries what it needs. Streamable HTTP requests "now must include Mcp-Method and Mcp-Name" headers. The method and tool name travel in the request itself. A connection no longer implies them. A stateless server can sit behind an ordinary load balancer. Any instance can answer any request.
Multi Round-Trip Requests
A stateless model still has to handle the cases that made streams handy. One case: a tool that needs to ask the caller for more input partway through. The revision handles this with Multi Round-Trip Requests. Instead of holding a stream open, the server returns resultType: "input_required" with the requests it needs answered. The client then comes back with the answers in a new request. The spec frames this as "removing the need for constantly open bidirectional streams."
Two deprecations to plan around
Two existing pieces are now on the way out:
- Dynamic Client Registration "is now formally deprecated in favor of CIMD." It keeps working for backward compatibility but "will be removed in a future version."
- The legacy HTTP+SSE transport is "also considered to be officially deprecated," with a year-long offramp.
Neither breaks today. The revision pairs the deprecations with a formal policy. In its words: "a twelve-month minimum window so you can plan upgrades instead of reacting to them." That is the clock to put on the calendar.
What it means if you build on MCP
If you run an MCP server, the stateless model is the change to design toward. It is what makes it easy to scale out. If you maintain a client or an agent harness, watch two things: the new headers and the MRTR flow. If you depend on Dynamic Client Registration or the HTTP+SSE transport, nothing breaks today. You have a stated twelve-month window to move.
MCP is one half of the harness question we keep coming back to. The model does the reasoning. The tools and transport around it decide what it can actually do. We wrote about that split in harness versus model. We covered a self-improving harness in the Prime agent. For picking servers to build on, the MCP servers for coding agents list covers the current options. The MCP config generator writes the client config for you.
Common questions
What is the biggest change in the 2026-07-28 MCP spec? MCP moves from a stateful two-way protocol to a stateless request/response protocol. Servers can then scale behind an ordinary load balancer. Any instance can answer any request.
What are Multi Round-Trip Requests? A stateless way to handle tools that need more input mid-call. The server returns resultType: "input_required" with the requests it needs. The client answers in a follow-up request. No stream stays open.
Is Dynamic Client Registration removed? Not yet. It is formally deprecated in favor of CIMD. It keeps working for backward compatibility. Removal is stated for a future version, under a twelve-month minimum window.
Do I need to change my MCP server now? No immediate break. The legacy HTTP+SSE transport and Dynamic Client Registration both carry a stated year-long window. The near-term work is planning the move to the stateless model and the new Mcp-Method and Mcp-Name headers.