By ByteBot
On July 28, the Model Context Protocol published its biggest spec revision since launch. The session handshake is gone. The Mcp-Session-Id header is gone. If you run an MCP server, you no longer need sticky sessions, shared Redis stores, or load balancers that do deep packet inspection to pin clients to specific instances. The 2026-07-28 specification makes MCP stateless at the protocol layer — and that is the right call, even if the migration is not painless.
The Handshake Is Gone
Under the old model, every MCP connection began with an initialize/initialized handshake. The server returned an Mcp-Session-Id header. Every subsequent call had to carry that ID, which meant traffic from a given client had to route to the same server instance. Horizontal scaling required sticky sessions. Failover required session replication. Running on Cloud Run or Cloudflare Workers — platforms that spin instances up and down freely — was impractical.
The 2026-07-28 spec eliminates all of that. Client metadata (protocol version, capabilities, identity) now travels in a _meta field inline on every request. Each request is fully self-describing and independent. Any instance behind a plain round-robin load balancer can handle it.
// OLD: sticky session required after initialize
{ "method": "initialize", "params": { "protocolVersion": "2025-11-25" } }
// Server returns Mcp-Session-Id: abc123 → every call must hit the same instance
// NEW: every request is self-contained
{
"method": "tools/call",
"params": {
"name": "search",
"_meta": { "io.modelcontextprotocol/protocolVersion": "2026-07-28" }
}
}What You Get in Exchange
Statelessness is not the only thing in this release. The spec ships four meaningful additions alongside the architectural change. Multi Round-Trip Requests (MRTR) replace the server-initiated back-channel pattern: when a tool needs user input mid-execution, the server returns resultType: "input_required" with its questions attached, and the client retries the original call with answers in inputResponses — no persistent stream required. Header-based routing adds two mandatory HTTP headers, Mcp-Method and Mcp-Name, so gateways, WAFs, and rate limiters can route and throttle tool calls without parsing JSON bodies. Cacheable list results carry ttlMs and cacheScope metadata, reducing redundant refetching and stabilizing upstream prompt caches. And W3C Trace Context now propagates through _meta, letting traces follow a tool call through the client SDK, the MCP server, and whatever the server calls downstream.
Migration Is Not Just an SDK Bump
The 2026-07-28 spec is wire-incompatible in both directions. All four Tier 1 SDKs — TypeScript, Python, Go, and C# — shipped 2026-07-28 support on the day of final publication. But updating the SDK is not the whole job. If your server used elicitation (ctx.elicit() in Python), that pattern raises NoBackChannelError on a stateless connection and requires a rewrite to MRTR. Any state you stored in sessions must move to the application layer via explicit handles: the server returns a handle ID as a tool output, and the model passes it back as an ordinary argument on subsequent calls. That is actually more powerful — models can compose handles across tools and reason about them — but it is a real architectural change, not a find-and-replace. The Python SDK also renames FastMCP to MCPServer and changes import paths. The DEV Community migration guide is the most practical walkthrough available.
Is This Just a REST API Now?
The Hacker News discussion lit up with a pointed question: if MCP is now stateless and uses standard HTTP routing, what actually distinguishes it from a REST API? The skeptics have a point worth taking seriously. But the answer is in the headers. Mcp-Method and Mcp-Name give infrastructure layers first-class awareness of tool semantics — a rate limiter can treat tools/call:search differently from tools/call:execute_code without touching the JSON body. That is not something you get from generic REST. The structured tool-call model, the MRTR retry pattern, the extensions framework — these keep MCP distinct even with a stateless core. InfoQ covered the debate if you want the full range of reactions.
What’s Leaving, What’s Formalizing
Three features enter deprecation with 12-month minimum windows before removal: Roots (use tool parameters or resource URIs instead), Sampling (use direct LLM provider APIs), and Logging (use stderr or OpenTelemetry). On the other side, Tasks, MCP Apps, and Enterprise Managed Authorization move into a formalized extensions framework with reverse-DNS identifiers, independent versioning, and dedicated maintainers. This is what a maturing protocol looks like — moving experimental features into their own tracks instead of letting them bloat the core spec.
The Bottom Line
This is the spec change the MCP community asked for. Stateless infrastructure is dramatically simpler to operate, and the protocol’s tool semantics remain intact. What it is not is a painless upgrade. If you maintain a production MCP server, start with the official 2026-07-28 specification, audit your elicitation and session-state patterns, and plan for the architectural work — it is more than a version bump.
