The 2026-07-28 MCP revision
The largest change to the specification since authorization was added. If your mental model of MCP is “a stateful session over SSE”, it’s a year out of date.
Verified against the spec dated 2026-07-28. Re-check before quoting — this area moves.
The headline: a stateless protocol core
Transport-level session management is removed. Earlier revisions maintained a session between client and server, which meant every request from a given client had to reach the same server process.
That is exactly the property that makes a service hard to scale. It forces sticky sessions, complicates load balancing, breaks on redeploy, and turns a horizontally scalable HTTP service into something closer to a stateful connection pool.
With a stateless core, an MCP server is an ordinary HTTP service. Any request can go to any instance. You scale it behind a normal load balancer with normal autoscaling, and a rolling deploy doesn’t drop conversations.
For a backend engineer this is the most important thing about the revision, and framing it as “they removed the thing that prevented horizontal scaling” is the answer that lands.
What came with it
| Change | What it does |
|---|---|
| Stateless core | no transport session; any instance serves any request |
| Multi round-trip requests | a server can come back to the client mid-request for more input |
| Header-based routing | routing metadata in HTTP headers, so proxies and gateways can route without parsing bodies |
| Cacheable list results | tools/list and friends become cacheable, cutting chatty startup traffic |
| Authorization hardening | tightened auth requirements |
| Extensions framework | a formal mechanism for capabilities outside the core |
| Tasks moved to an extension | long-running operation management left the core protocol |
Multi round-trip requests
Previously a request was one exchange. Now a server can pause mid-request and ask the client for something — additional input, a confirmation, a credential — then continue.
This is what makes human-in-the-loop and elicitation work cleanly: a refund_order tool can ask for approval before proceeding, within the same logical request, instead of the client having to model an approval state machine itself.
Header-based routing
Routing information moves into HTTP headers. That means an API gateway, a service mesh or a reverse proxy can route MCP traffic on headers alone, without deserialising JSON-RPC bodies.
Ordinary infrastructure practice, and combined with statelessness it’s what makes MCP servers deployable like any other microservice. See ../../backend/12_protocols/nginx/06_upstream_load_balancing.md.
Cacheable list results
Clients call tools/list, resources/list and prompts/list at startup and often repeatedly. Making those responses cacheable removes a lot of redundant traffic, which matters when a client connects to a dozen servers.
The operational consequence: tool definitions can now be stale in a client’s cache. If you change a tool’s schema, clients may use the old one until their cache expires. Version your tools and treat schema changes as you would any API change.
The extensions framework
Rather than growing the core, capabilities live in named extensions that clients and servers negotiate. Tasks — managing long-running operations — was moved out of core into an extension as the first significant application of this.
The design intent is a small stable core with optional capabilities evolving independently, which is a sensible protocol trajectory and the same instinct behind HTTP’s extension model.
Migration reality
If you’re running a server written against an older revision:
- Remove session assumptions. Anything stored in server memory keyed by session must move to a shared store or into the request itself.
- Check your SDK version. Tier 1 SDKs were updated for this revision.
- Negotiate versions. Clients and servers advertise supported protocol versions; a mixed fleet is normal during migration.
- Re-check auth. Authorization requirements were hardened.
Interview angle
- “What changed in the 2026-07-28 MCP spec?” — the protocol core became stateless: transport-level session management was removed. Plus multi-round-trip requests, header-based routing, cacheable list results, hardened authorization, a formal extensions framework, and Tasks moving out of core.
- “Why does statelessness matter operationally?” — sessions forced request affinity, which means sticky routing, awkward load balancing and dropped state on redeploy. Without them an MCP server is a normal HTTP service you can scale horizontally and deploy with a rolling update.
- “What do multi-round-trip requests enable?” — a server pausing mid-request to ask the client for input, which is how approval gates and elicitation work without the client implementing its own state machine around it.
- “Any downside to cacheable list results?” — clients can hold stale tool schemas. Treat tool definitions as a versioned API surface and don’t assume a schema change propagates immediately.
- “How would you deploy an MCP server in production?” — as a stateless HTTP service behind a load balancer: no session affinity, shared state externalised, header-based routing at the gateway, standard authn/authz, and normal autoscaling. That answer is only correct post-2026-07-28, which is the point.