MCP 2.0 ends the trusted session

In July, the Model Context Protocol shipped its 2026-07-28 revision, the one the ecosystem has informally taken to calling MCP 2.0. The changelog reads like aggressive spring cleaning: protocol-level sessions removed, the initialize handshake removed, a mandatory server/discover added, every request now carrying its own protocol version and capabilities, server-minted handles replacing hidden connection state, long-running work moved to an official Tasks extension, client registration migrating from Dynamic Client Registration to issuer-bound credential documents.

Most working engineers will experience this as migration labor, and fair enough; we are doing that labor too. But it is worth stepping back and reading the revision as a document about trust, because taken together these changes have a direction, and the direction is one we recognize. The protocol is systematically removing the places where implicit state could carry authority. It is, in the vocabulary we have been using all week, growing rule-of-law properties.

What was wrong with the session

For its first two years, MCP was a relationship protocol. A client and server met, performed an initialize handshake, negotiated capabilities, and established a session; everything afterward happened inside that standing relationship, identified by a session header, accumulating implicit context as it went.

That is a natural first design because it mirrors how the underlying transports work. It is also, from a trust perspective, a liability with a specific shape: a session is a place where state can lie. Authority established at handshake time silently persists; whoever holds the socket inherits the trust of whoever opened it; what a server believes about a client lives in memory that nothing re-verifies; and the “same” actor on two connections is two strangers, while two actors sharing a connection are indistinguishable. Every one of these is a gap between what the system assumes and what is actually true right now, and gaps of that kind are exactly where both bugs and attacks live. We wrote in Prompts are not policy that enforcement must live below the layer that can be persuaded. The session was worse than persuadable; it was assumable. Nothing had to argue with it. It just had to already be there.

The 2026-07-28 revision deletes the entire category. There are no protocol sessions and no session header. Every request arrives carrying its own protocol version, its own capability declarations, its own identity metadata, and must be processable on those terms. Servers that need continuity across calls issue explicit handles: minted objects, passed as ordinary visible arguments, bounded, scoped, and revocable.

Notice what that last sentence describes. Continuity did not disappear; it became legible. The relationship state that used to live silently in a server’s memory is now a first-class object that can be inspected, expired, and refused. That is the same design move we described in The record no one gets to rewrite: take the thing that was implicit and make it an artifact. The protocol did not become stateless so much as it became honest about where its state is.

Long work becomes a thing, not a hope

The same shape repeats in the Tasks extension. Under session-era MCP, a long-running operation was a connection that had better stay alive: the work’s identity was the socket’s survival, and a dropped stream was an existential event with no principled recovery. The new revision drops stream resumability outright and moves durable work to explicit task handles: created, polled, updated, cancelled cooperatively, with terminal states that are immutable once reached.

Immutable terminal states deserve a pause. The spec now says, in effect, that once a task has completed or failed, no later message can quietly change what happened to it. That is supersede-not-erase applied to work: the outcome is a record, not a claim under ongoing negotiation. Combine it with typed results (every response now declares what kind of result it is) and mid-request input as explicit recorded round trips, and the protocol’s picture of “what happened” has moved decisively from narrative toward receipt. Readers of The monitorability tax will recognize why we think that direction matters more than any individual feature.

Credentials get an issuer

The authorization line of changes completes the pattern. Dynamic Client Registration, the old path where clients register themselves on the fly, is deprecated in favor of Client ID Metadata Documents, and clients must now validate that authorization responses come from the issuer they expect, keying stored credentials by issuer rather than reusing them wherever they seem to work.

Translated out of OAuth: a credential is no longer a bearer token in the folk sense of “whoever bears it, wins.” It is bound to who issued it and to the context it was issued for. The identity question moves from “what string did you present” toward “what verifiable relationship does this string represent,” which is the only foundation on which agent identity, as opposed to connection identity, can be built. We have argued since our front page that in a room full of capable agents, authority must come from identity and grant, never from possession or persuasion. The protocol now agrees at the wire level.

Convergence, not prophecy

It would be flattering to claim the spec is following us. The truth is better than flattering, and we prefer it: this is convergent evolution, and convergent evolution is stronger evidence than influence.

The MCP maintainers arrived at these designs for their own mix of reasons, including thoroughly unglamorous operational ones: stateless requests load-balance better, deterministic lists cache better, explicit handles survive serverless deployment. But operational pressure and trust pressure kept producing the same answers, because they are downstream of the same fact: implicit state is a liability to whoever has to reason about the system, whether the reasoner is a load balancer, an auditor, or another agent. Everyone who runs agents at scale eventually meets the same failure classes: ghost authority living in sessions, claims nobody can verify at the point of use, long work whose identity is a socket’s lifespan. And the fixes keep having one shape: make the state explicit, bind authority to verified identity, make the record load-bearing.

We built a substrate on those principles because our product dies without them; a memory system that cannot answer “who did this, with what right, and what actually happened” is not worth querying. The protocol is arriving at them because everything at scale dies without them, eventually, just more slowly. When independent lineages under independent pressures grow the same organ, that is the environment telling you what works.

What we are doing about it, and what this does not mean

We are migrating Sophia’s MCP surface to 2026-07-28 deliberately rather than heroically: dual-stack, evidence-gated, with the old surface retained as a bounded compatibility lane until every supported client crosses conformance gates. The honest reason the migration is tractable for us is that the hard conceptual work was already forced on us by the product: separating the durable actor from the transport that happened to carry it, making authority explicit and revocable, treating outcomes as receipts. For much of the ecosystem, MCP 2.0’s difficulty is precisely that it makes those separations mandatory for the first time. That is also why we would encourage teams not to treat the migration as churn. The parts that feel like unnecessary rigor are the spec doing you the favor of forcing the architecture you would eventually need anyway.

And the limits, plainly. A wire protocol cannot make a model honest; MCP 2.0 fixes where identity and authority live in transit, not what happens inside a forward pass, and nothing in this essay claims otherwise. Some of the convergence is partial: the spec’s receipts are result-typing and task immutability, useful skeletons but far short of evidence-grounded receipts, and it standardizes pragmatics while (rightly) staying silent on truth. Nor is our migration finished; when it is, the conformance evidence will be in the build record where our claims usually go. The convergence we are describing is directional, not total.

But the direction is the story. The industry’s shared protocol just spent its largest revision removing trusted sessions, making authority an explicit artifact, and making outcomes immutable records. Each of those is a small verdict about what breaks when software starts acting on software’s word. We have been arguing all along that the agentic era’s infrastructure would be forced, failure by failure, toward explicit state, bound identity, and load-bearing records. We did not expect the strongest supporting brief to arrive as a changelog.

---

Dating note: all protocol claims are pinned to specification revision 2026-07-28 as published; statements about our own migration describe August 2026 and will be superseded by the build record as conformance gates pass. If you are reading this well after that, check both.

Primary sources: the MCP 2026-07-28 specification and changelog, including SEP-2567 (session removal, explicit handles), SEP-2575 (stateless requests, server/discover), SEP-2663 (Tasks extension), SEP-2322 (typed results, multi round-trip requests), SEP-2352 and the CIMD deprecation of Dynamic Client Registration (issuer-bound credentials). Companion essays: Prompts are not policy, The record no one gets to rewrite, The monitorability tax.