On July 28, 2026, the Model Context Protocol shipped the most consequential revision since remote MCP existed. The headline is easy to state and easy to underrate: MCP is now stateless at the protocol layer. The initialize/initialized handshake is gone. The Mcp-Session-Id header is gone. Every request is self-describing, carrying its protocol version, client identity, and capabilities inline.
Read that as an infrastructure change and you'll conclude, correctly, that you can now run MCP servers behind a round-robin load balancer with no sticky routing and no shared session store. Read it as an architectural statement and you'll notice something more interesting: the protocol just stopped pretending it could hold your state for you. That responsibility didn't disappear. It got promoted.
What actually changed
Six SEPs work together to get to a stateless core. The pieces worth knowing:
No handshake, no sessions. Each request travels alone. There's an optional server/discover RPC for clients that want capabilities up front, but nothing requires it. Any request can land on any instance.
Multi Round-Trip Requests (MRTR). Server-initiated calls - elicitation, sampling, roots - used to require a held-open bidirectional stream. Now a server returns resultType: "input_required" with what it needs, and the client retries the original call with answers attached. Interactivity without a socket.
Header-based routing. Mcp-Method and Mcp-Name are mandatory on Streamable HTTP. Your gateway, WAF, and rate limiter route and meter on headers instead of parsing JSON bodies.
Cacheable lists. tools/list, prompts/list, resources/list, and resources/read now carry ttlMs and cacheScope, with deterministic ordering.
Authorization hardening. RFC 9207 issuer validation, credentials bound to the issuer that minted them, and a formal shift away from Dynamic Client Registration toward Client ID Metadata Documents.
An extensions framework. Tasks moved out of the experimental core into a named extension, alongside MCP Apps and Enterprise Managed Authorization.
A deprecation policy with a twelve-month minimum window. Roots, Sampling, and Logging are deprecated; so is the legacy HTTP+SSE transport.
That last bullet is the least exciting and the most important. A protocol with a published deprecation policy is a protocol you can budget against.
The real story: state became explicit
If your server needs to carry something across calls, you no longer hide it in the transport. You mint an explicit handle from a tool and let the model pass it back as an argument.
This looks like a downgrade. It isn't. Session state hidden in a connection is state the model cannot see, cannot reason about, and cannot recover after a reconnect. A handle in the argument list is a first-class object in the agent's working context - inspectable, loggable, attributable, and portable across instances.
This is the same lesson every distributed system eventually learns, arriving on schedule for agents: implicit state is a scaling ceiling and a debugging tax. The fix is always to make it addressable.
The consequence for anyone building agent systems is that context stops being an ambient property of a connection and becomes an artifact you construct, name, version, and pay for. Which raises the question the protocol deliberately does not answer: who decides what goes in it?
Five second-order effects worth planning around
1. The gateway becomes a real product category
When method and tool names ride in HTTP headers, every piece of standard edge infrastructure suddenly speaks agent. You can rate-limit tools/call on a specific tool name, authorize per-method at the proxy, and meter per-tool spend without cracking the payload. Expect governance, observability, and policy enforcement to consolidate into an MCP control plane sitting in front of fleets of servers. That layer barely existed eighteen months ago and will be table stakes in twelve.
2. Tool catalogs became cacheable assets - which makes them a token-economics problem
ttlMs plus deterministic ordering means clients can cache tool catalogs and, critically, keep upstream prompt caches stable across reconnects. This is a quiet but material cost lever: a catalog that reorders on every reconnect invalidates the prefix and re-bills you for it.
It also sharpens a problem the ecosystem has been avoiding. Once catalogs are stable and cheap to fetch, nothing stops an enterprise from wiring 40 servers and 900 tools into one agent - and the model will drown long before the infrastructure does. Stable catalogs make selection the bottleneck. The question moves from "can I reach this tool?" to "which twelve of these nine hundred belong in this request, for this user, right now, within this token budget?"
3. Permissions have nowhere left to hide
List endpoints no longer vary per connection. If you were quietly filtering a user's visible tool set based on session identity, that trick is gone. Authorization has to be carried per-request and enforced explicitly - either by scoping servers per tenant, or by putting an identity-aware layer between the agent and the catalog that resolves what this principal is allowed to see on every call.
Enterprises will discover this the hard way, because it's the same problem as document-level ACLs in retrieval: the permission model belongs in the layer that assembles context, not in the transport that ships it. Point an LLM at a decade of latent permission drift and you have a permissions project wearing an AI costume.
4. Modularity moves competition up a level
Formalizing extensions means the core spec can stabilize while capabilities like Tasks, MCP Apps, and Enterprise Managed Authorization ship on their own timelines. That's the HTTP playbook - a boring, stable core and a Cambrian explosion on top. It also means "supports MCP" is about to stop being a meaningful claim on a vendor slide. The real questions become which extensions, which auth model, and what happens to your integration when the model behind it changes.
5. Security responsibility shifted to you
Statelessness removes whole classes of bugs: no session to hijack, no unsolicited server-initiated prompts. Akamai's analysis flags what replaced them, and the list is sobering. Server-minted handles are the new session IDs - if they're guessable, you've built cross-tenant access. Mapping anything sensitive into Mcp-* headers pushes secrets into every proxy and log along the path. Long-running Tasks are cheap for a client to spawn and expensive for a server to run, which is a clean asymmetric DoS. MCP Apps bring browser-grade risks like stored XSS into the agent surface.
None of this makes the protocol less safe. It makes your implementation the thing that determines whether the deployment is safe. Boundaries the protocol used to enforce are now yours to enforce.
What to do in the next quarter
If you operate MCP servers in production:
Audit for session dependence. Anything relying on Mcp-Session-Id or connection-scoped state needs an explicit handle design. Do the handle design deliberately - unguessable, scoped to a principal, expiring.
Move elicitation and confirmation flows to MRTR. If you skipped user confirmation because you ran stateless, that excuse is gone. Destructive tool calls should be asking.
Set honest TTLs on your lists and keep ordering deterministic. Free prompt-cache stability for your consumers.
Get off DCR. Plan the CIMD migration now; DCR works but is formally deprecated.
Instrument at the header layer. Per-tool spend, latency, and error rates are now trivially observable at the edge. Most teams still can't answer which tools their agents actually use.
Rate-limit Task creation before someone else discovers you didn't.
The part the spec leaves to us
The 2026-07-28 release makes MCP behave like the rest of the web: stateless, cacheable, routable, horizontally scalable, with a deprecation policy you can plan around. That's a genuine milestone and the maintainers deserve the credit.
It also finishes the job of defining what MCP is not. It is a transport and a contract. It moves tools and data between agents and systems reliably, at scale, with a coherent authorization story. What it does not do - deliberately, correctly - is decide which tools matter, which facts belong in the window, whose permissions apply, or what any of it costs per token.
HTTP didn't tell you what to put on the page either. That turned out to be where all the value was - and the layer modus exists to own.
This is what modus builds.
A context warehouse for data agents - the layer that decides which tools, which facts, for which user, within which budget.