Most protocol updates are a list of things you can now do. The 2026-07-28 revision of the Model Context Protocol — in release candidate now, with the final spec due July 28 — is mostly a list of things the protocol no longer does. That inversion is the story. MCP's biggest revision since launch is, at heart, a deletion: of the session, of the handshake, and of a surprising amount of what made MCP feel like an agent protocol in the first place.

If you only remember one thing, make it this: MCP got smaller, and that was the point.

The session is gone#

The old wire model — the 2025-11-25 revision — assumed a session. A client opened with an initialize/initialized handshake, the server handed back an Mcp-Session-Id, and every later request carried that header. Behind a load balancer, that meant sticky routing or a shared session store, because request two had to land on the same brain that handled request one.

The new spec deletes that whole apparatus. A cluster of SEPs do the work together: SEP-2575 removes the handshake and moves protocol version and client info into _meta on every request; SEP-2567 eliminates the Mcp-Session-Id header and protocol-level sessions entirely. The stated payoff in the release-candidate notes is blunt: you can now put a server "behind a plain round-robin load balancer." Any request can hit any instance. No affinity, no shared store.

A few smaller changes fall directly out of that decision. SEP-2243 adds Mcp-Method and Mcp-Name headers so a gateway can route on the envelope without parsing the body. SEP-2549 lets list and resource results carry ttlMs and cacheScope so clients can cache instead of re-asking. SEP-414 wires in W3C Trace Context (traceparent, tracestate, baggage) so a tool call shows up as a span in your existing OpenTelemetry backend. None of these are glamorous. All of them are what "scales horizontally" actually means in practice.

The interesting part is the subtraction#

Here's the move almost everyone will miss while reading the feature list. The same release formalizes a deprecation lifecycle — SEP-2577, Active → Deprecated → Removed, minimum twelve months — and then uses it to retire three of MCP's most agent-flavored capabilities:

Strip out Sampling and Roots and you've quietly redrawn the line: the model and the filesystem belong to the host, and MCP is the stateless tool surface in between.

Read those three together and a thesis appears. The 2025 version of MCP flirted with being a two-way agent loop — the server could reach back through the client to borrow its LLM and its file roots. The 2026 version says no: the host owns the model and the trust boundary, and the server is a tool you call. That settles a question we've poked at before — whether MCP is really different from a REST API — by making the answer architectural rather than rhetorical. It's a narrower, more honest contract, and it's the kind of narrowing that's hard to do after a protocol has 200-plus implementations in the wild. They're doing it anyway, behind a one-year window.

Long-running work moves to polling#

If the session is gone, how does a tool that takes ten minutes report back? Not over a held-open stream. The experimental Tasks primitive from 2025-11-25 graduates into a standalone Tasks extension, redesigned around the stateless model. A server can answer tools/call with a task handle; the client then drives it with tasks/get, tasks/update, and tasks/cancel, polling for progress through a small state machine — working, input_required, terminal completed/failed/cancelled. Once a task is terminal, it never moves again.

Two details matter for builders. First, tasks/list was removed — without a session there's no safe per-client task registry to enumerate, so you hold your own task IDs. Second, this is the clean way to get concurrency: fire several tasks, keep the handles, poll each independently, instead of serializing slow work behind one blocking call. The redesign is also a migration: task code written against 2025-11-25 will need rework.

And servers can now ship a UI#

The one genuinely additive headline is MCP Apps (SEP-1865): a server can ship interactive HTML that the host renders in a sandboxed iframe. Tools declare their UI templates ahead of time, so the host can prefetch, cache, and security-review them before anything runs — and every action the UI takes goes back over the same JSON-RPC path as a direct tool call, through the same consent and audit trail. It's a real capability, but notice the framing: even the new surface is bent to fit the audited, request-shaped model. The UI doesn't get a side channel.

What to actually do#

If you ship an MCP server: the plain request/response ones change least. Audit anything that leaned on long-lived sessions, SSE streaming, Sampling, or Roots — those are your migration costs, and Tasks is the one most likely to need a rewrite. You have a year of overlap, not a cliff.

But don't file this under "routine spec bump." The useful way to read 2026-07-28 is as MCP deciding what it is. For two years the open question was whether MCP would grow into a full agent runtime or stay a tool protocol. This release answers it: stateless transport, host-owned models, no live back-channel, work tracked by polling. MCP is choosing to be plumbing — and leaving the agent-to-agent layer to protocols like A2A. Good plumbing is exactly what the agent stack has been short on.