MCP 2.0? What Changed, What Remained, and How it Impacts Practitioners

On 28 July, MCP shipped its first deliberately breaking revision. Nothing visible failed that day, because publication is not enforcement and the official SDKs kept both protocol generations alive.

But the revision starts several clocks, moves at least one security boundary, and quietly changes what kind of technology decision MCP is.

I have spent the weeks since reading the spec end to end, migrating parts of our estate, and answering some version of “is this a big deal” in most meetings I attend. These notes are the answer I have settled on.

They are not a changelog summary; the changelog is well written and you should read it. This is the layer under it: what changed for people who own an estate of these things, where my earlier assumptions turned out wrong, and what I have actually changed in our standards as a result.

A scoping note before anything else: everything here is from the vantage point of one large enterprise with an existing API gateway, an IdP, a central platform team and delivery teams that outnumber it. Where I generalise, I flag it. Where something is a guess, I say so.

These come up in almost every conversation, so I will settle them first.

1. There is no MCP v2. The project versions by date; the current revision is 2026-07-28. The "v2" in circulation comes from SDK major versions (TypeScript SDK v2, Python mcp 2.0.0) and headlines.

The distinction is worth making in your own documents because “v2” smuggles in an assumption of a release train, and there is none. The project dropped release-milestone planning from its roadmap this year and lets working groups set their own timelines.

The planning posture that follows: assume a breaking revision can arrive in any twelve-month window, with, on the one data point we have, about ten weeks of release candidate to validate against.

2. MCP did not move out of the Linux Foundation. I have now seen “MCP moved from the Linux Foundation to the Agentic AI Foundation” in two vendor decks. The Agentic AI Foundation is a directed fund inside the Linux Foundation; Anthropic donated MCP to it in December 2025. One move, inward.

The likely source of the confusion is A2A, which did move twice: to the Linux Foundation in mid 2025, then under AAIF in August 2026. That second move means MCP and A2A now report to the same board, which becomes relevant later.

3. Stateless does not mean state went away. It means the protocol stopped carrying it. The initialize handshake and Mcp-Session-Id are deleted, and every request now carries its own protocol version and capabilities.

But long-lived notification streams still exist, the Tasks extension is built on durable server-side state, and the spec’s own prescription for anything spanning calls is “explicit, server-minted handles passed as ordinary tool arguments.”

State moved from the transport into the data model. I will come back to why that relocation matters, because a handle in a tool argument sits inside model context, and a session ID in a header did not.

Put the headline changes side by side and they share a shape: each one removes a reason MCP needed special infrastructure.

The handshake is gone, so any request can land on any instance behind a plain load balancer. Protocol sessions are gone, so there is no session store; GitHub reported deleting the Redis tier behind their MCP server.

The standalone stream a client held open for server-initiated messages is gone, replaced by request-scoped streams and one optional listen stream. And the method and tool name are now mirrored into required Mcp-Method and Mcp-Name HTTP headers, with an opt-in mechanism (x-mcp-header) for mirroring chosen tool parameters, so a gateway can route, rate-limit and log without parsing JSON-RPC bodies.

The stated motivation for the session removal is load-balanced deployment, and the maintainers describe the outcome as making MCP “a first-class HTTP workload.”

I read the whole revision as the protocol conceding authority to the people who operate it. The 2025 design was interesting to implement and awkward to run. The 2026 design is dull to implement and fits the platform controls a regulated enterprise already owns: the gateway, the WAF, the autoscaler, the observability pipeline.

Two caveats stop this being a clean win. The subscriptions/listen stream is still long-lived, which keeps one awkward conversation with the serverless crowd alive.

And the cost direction is unclear. TTL-based caching of tool lists and better prompt-cache hits push cost down, but the new interaction pattern re-sends full requests (more on that below), Tasks replaces one blocking call with polling, and servers that used sampling now pay for their own inference. I have not seen anyone publish a before-and-after bill. Measure your own traffic shape before you put a savings number in a business case; I declined to put one in ours.

The sharpest critique came out of the developer reaction InfoQ collected: strip the sessions and the bidirectional messaging, and MCP decomposes into a REST-ish API, an OpenAPI-ish schema, and an authorization layer, of which only the authorization layer is novel.

These are forum commenters, not credentialed critics, so weight accordingly. But I have not seen the argument put better anywhere else, and having argued both sides in our own forums, I think the decomposition holds.

What I resist is treating it as a verdict, because the layer it waves through in four words, “only the auth is novel,” is the one I would least want to fund building. Walk through what actually survives the stateless turn.

A single auth profile, made normative. MCP did not invent OAuth. It picked one opinionated profile (resource server pattern, protected resource metadata, resource indicators, mandatory issuer validation, and portable client identity through Client ID Metadata Documents, where a client’s client_id is an HTTPS URL hosting its own metadata) and made it mandatory across clients and servers that have never met.

OpenAPI’s securitySchemes describes auth; it does not mandate a profile that makes zero-prior-relationship connection work. Every time I have estimated building the equivalent in-house, auth is where the cost concentrated.

A risk vocabulary a host can act on. Tool annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) let a host auto-approve reads from trusted servers and force confirmation on destructive calls.

The idea underneath them is the more useful import, and I have not found an equivalent in the REST toolkit: a session composed of tools from vendors that do not trust each other, where a tool’s risk depends on what else is loaded beside it. OpenAPI describes operations one at a time; it has no way to say “this call is dangerous because of what else is in scope.” We lifted that composition framing directly into our tool-approval policy, and it resolved arguments that per-tool review had been losing for months.

UI shipped into a chat client you do not own. MCP Apps lets a server deliver interactive HTML that renders inside Claude, ChatGPT, Copilot or VS Code, in a sandboxed iframe, under a CSP the host constructs, with the app’s tool calls flowing through the same audit path as the model’s. REST has no equivalent, and I am not aware of another standard that does this today.

Reach. The major AI clients your workforce already uses speak MCP. You are not selecting an architecture; you are selecting the interface those clients already have.

So the framing I now use in architecture reviews:

MCP stopped being a different kind of thing from a REST API and became a profile over HTTP plus an ecosystem. You adopt it the way you adopted OpenID Connect, not the way you adopt a database.

On those terms the “just REST” observation is not a reason to abstain. It is a reason to adopt without romance, for reach and for the auth profile, and to keep your own REST estate as the system of record underneath.

One study is worth carrying into the inevitable “can’t we just generate MCP servers from our OpenAPI specs” meeting. An academic analysis of automated OpenAPI-to-MCP wrapping (arXiv 2507.16044) measured a 76% out-of-the-box success rate, rising to about 94% with a repair pipeline, and found under 5% of sampled real-world MCP servers were spec-generated at all.

The failure classes are the ones your own specs have: undocumented runtime headers, missing security schemes, type mismatches. Generation is a decent starting point for a human. The remainder, tool granularity, naming, model-facing descriptions, auth wiring, is product work.

Our API product owners now own the MCP presentation of their domains, and making that ownership explicit was more useful than any tooling decision we made.

Two changes that read as unrelated line items combine into the sharpest correctness risk in the revision.

First, stream resumability is gone. Previously a dropped SSE stream could be resumed with Last-Event-ID; now a broken stream loses the in-flight request, and the client must re-issue it as a new request with a new ID.

Second, the replacement for server-initiated requests, called MRTR, is itself a retry pattern. When a server needs something from the client mid-call (a confirmation, a form, an external approval), it returns input_required, and the client re-sends the entire original request under a new ID with the answers attached.

So the protocol now structurally expects requests to arrive more than once, and it defines no idempotency key, no dedup semantics, and no retry limit. What it offers instead is requestState, an opaque blob the server can round-trip through the client, with a requirement to integrity-protect it and an explicit warning that even a protected blob does not guarantee single-use.

Make it concrete with the kind of tool that will exist in any customer-facing estate: process_refund.

The agent calls it. The server needs a supervisor confirmation, so it returns input_required. The confirmation happens; the client re-sends the full refund request. The network drops mid-response; the client, following the spec, re-issues with a fresh ID.

That refund has now been submitted three times under three request IDs, and whether the customer is refunded once or three times depends entirely on whether the tool’s implementer keyed the operation on something stable. A security write-up on the revision (Equixly) compressed this well:

Whether a retry duplicates a payment, a deployment, a message, or a deletion “depends entirely on whether the tool underneath was written to notice.”

The fix is old and cheap: an application-level idempotency key on every side-effecting tool, derived from the business operation rather than the request. We made it a hard rule in our server standard, and I would suggest making it a rule before your estate grows, because it costs a sentence now and an audit later.

Two adjacent rules went into the same standard:

• Classify cacheScope deliberately, and review it. The new mandatory cache hints include a "public" scope that permits shared intermediaries to serve a cached response across users. Set that on an authenticated, per-tenant tool list and you have built a cross-tenant disclosure that no scanner will flag, because it is a correctly-formed response with the wrong label. Classification is now a named reviewer responsibility for us.
• Bind state handles to the authenticated principal, server-side. The server-minted handles that replaced sessions travel through model context, which means prompt injection can reach them. The spec’s own guidance is the right one: a handle must be a name rather than a capability, bound to the principal so a leaked or injected handle is useless in anyone else’s hands. We test for that binding now, the same way we test authorisation on a REST endpoint.

The identity work is the part of this revision that reads like it was written by people who have run enterprise IT.

The baseline hardening first. Dynamic Client Registration is deprecated in favour of CIMD, which makes a client’s identity a URL it controls, portable across authorization servers. Issuer validation per RFC 9207 is now mandatory on clients, closing a mix-up attack that PKCE alone does not. Credentials must be keyed to the issuer that minted them.

And token passthrough, an MCP server forwarding the client’s token to an upstream API, is flatly prohibited. The spec’s stated reason is worth repeating to any team tempted by the shortcut: passthrough turns a server into a data-exfiltration proxy with the audit trail severed.

The piece with organisational consequences is the Enterprise Managed Authorization extension, stable since June. The default MCP consent model is per-user, per-server: workable at ten users and three servers, unworkable at ten thousand and forty.

Two scenarios show what EMA changes.

Onboarding: a new joiner signs in through SSO once, the IdP evaluates policy and issues an identity-assertion grant, and every approved MCP server is available with no consent screens, because the client exchanges that grant directly for tokens.

Offboarding, the scenario your security team cares about more: a contractor’s access is revoked at the IdP on their last day, and that revocation takes effect across every MCP client at once, instead of surviving in per-service grants that no offboarding checklist tracks.

Centralised grant, centralised revocation, and an authorization trail in one place for the auditors.

The caution I attach, from checking this myself: Okta is the only identity provider officially named as shipping the IdP side, with Anthropic’s clients and VS Code named as client implementers and Asana, Atlassian, Canva, Figma, Linear and Supabase on the server side.

If your organisation runs a different IdP, get that vendor’s answer in writing before you architect around EMA. “The spec supports it” and “my IdP ships it” are different sentences, and I have watched a quarter of roadmap disappear into the gap between them.

Read the official security guidance end to end, which I did, and a boundary emerges.

On one side, it is thorough: confused deputy attacks with hard requirements on consent and cookie handling, SSRF (a new emphasis, including against authorization servers, since CIMD makes them fetch attacker-supplied URLs), token audience validation, redirect and URL-scheme rules, and a rewritten section on state-handle hijacking that replaces the old session-hijacking guidance.

Mandatory Origin validation against DNS rebinding has been there since earlier revisions, which is worth knowing because “MCP has no rebinding protection” still circulates and is wrong. The recurring rebinding CVEs have been SDK implementation failures, not spec gaps.

On the other side, I found no section on prompt injection, none on tool poisoning, and none on the case where a tool passes your approval process and changes its description afterwards. Post-approval change appears in the Security Interest Group’s scope as an open item with no champion listed at the time of writing. Cross-server tool shadowing is addressed, but as a naming problem.

I do not read this as negligence. Wire-level requirements are testable, and the project’s own conformance rules exempt hardening guidance from testing for exactly that reason; “detect a malicious tool description” does not compile to a check.

But the practical consequence lands on you either way: the semantic layer is unstandardised, and every control there is one you build. For us that has meant:

• an approved-server catalogue, with human review of tool descriptions at admission
• hashing the tool list, and treating any change as a re-approval event rather than a notification
• egress restrictions on server workloads
• policy that evaluates the set of tools in a session, rather than each tool alone

None of it is exotic. All of it had to be decided, funded and owned, because no default provides it.

Two related expectations to set with stakeholders. The public MCP registry is a discovery aid, not a trust signal: still in preview, no artifact signing or provenance (publisher keys prove domain control at publish time, nothing about the code), scanning delegated to the package registries, private servers unsupported. The sanctioned enterprise pattern is to run your own registry implementing the published API, which the project supports, rather than forking their codebase, which they say plainly they will not support.

And from working through the published security advisories: most of what has actually gone wrong in MCP’s short history is ordinary web vulnerability classes in SDKs and servers, session binding failures, rebinding, path traversal, command injection, rather than protocol design flaws. Spend your assurance budget accordingly.

My expectation, flagged as expectation rather than finding, is that the semantic layer is where the more interesting incidents come from next, precisely because nothing governs it.

Roots, sampling and logging are deprecated, eligible for removal from July 2027. Logging’s migration is stderr and OpenTelemetry, and the revision reserves W3C trace-context keys in request metadata. If your estate is still small, mandate that propagation now, because retrofitting observability across fifty servers is a project and mandating it across five is an email.

Sampling deserves the longer note, because its deprecation relocates something subtle.

Sampling let a server run completions on the client’s model, under the client’s account: the server got intelligence without holding credentials, and the client kept control of model choice, cost and, critically, where the data went. In the implementations I have looked at it was rarely used and more rarely used well, and the deprecation reads like the maintainers following observed reality. Fair enough.

But the migration path, “integrate directly with LLM provider APIs,” means every server that used sampling now holds its own model credentials, pays its own inference bill, and becomes a place where data leaves toward a provider the client never chose.

In a regulated environment that last clause is the whole story. Each of those servers now needs a named model provider, a data-residency review and a cost owner. The usage is findable in advance with a grep, and I would do the grep this quarter, because this is precisely the kind of dependency that otherwise surfaces in a security review at the worst possible moment.

One more compatibility fact worth stating plainly, because it is easy to misread the calm of July as forward compatibility: a pure 2026 client and a pure 2025 server cannot talk, in either direction.

Nothing broke publicly, as far as I can tell, because the official SDKs implement both generations, and the TypeScript SDK still defaults to the old one. The specific failure worth a test case, because gateways can translate ordinary calls across generations but not this: an old client invoking a tool on a new server that needs to ask the user something mid-call.

Since August, MCP and A2A sit under the same foundation. The official positioning is tidy, MCP for agent-to-tool, A2A for agent-to-agent, and worth keeping, with two untidy observations underneath it.

First, the two projects now maintain near-identical task state machines; A2A’s differs mainly by adding refusal states. And MCP’s draft Server Card work looks, to my reading of two draft documents rather than any stated plan, like it is arriving at something close to what an A2A Agent Card already is: a signed, discoverable, capability-declaring metadata document.

Second, the vertical/horizontal framing is asserted entirely by the A2A project and the foundation; I could not find an MCP document that positions MCP against A2A at all.

Neither observation demands action. Together they suggest keeping reconciliation risk on the register and not building anything that depends on the boundary staying where it is.

The boundary question does arrive in real reviews, usually as “our vendor’s MCP server plans, holds state and asks questions, is that not an agent?” Neither spec will answer it for you, and with sessions gone the behavioural distinction has blurred: a server holding durable task handles and requesting input mid-call looks a lot like a peer agent on the wire.

The rule that has survived our reviews is to decide by ownership rather than capability:

If the counterparty is operated by someone else and can refuse the work, treat it as an agent and use the agent protocol. If it is a capability you invoke and you would raise a ticket when it misbehaves, it is a tool.

And hedge structurally rather than by prediction: one enforcement point in front of both protocols (a foundation-hosted gateway project now speaks both) means that if the duplicate primitives ever are reconciled, the change lands in one layer of your stack. No reconciliation has been announced and I am not putting a date on one; I would just rather not be exposed either way.

Distilled to the artifacts, this revision produced four changes to our standards and five questions I now put to vendors.

The standards changes:

• An idempotency key is mandatory on any side-effecting tool
• cacheScope classification is a named review responsibility
• State handles must be bound server-side to the authenticated principal, and we test for it
• OpenTelemetry trace propagation in request metadata is required on new servers

Each is one paragraph in a standard. Each closes a failure mode the protocol now permits by design.

The vendor questions, for anyone selling us an MCP server, client or gateway:

1. Which protocol revisions do you support, and what is your dual-generation policy?
2. Do you route and enforce on the new headers, and do you reject unvalidated headers from old-revision traffic?
3. How do your side-effecting tools behave under a re-sent request?
4. Do you support Enterprise Managed Authorization, and against which IdP have you tested it?
5. How do you notify us when your tool descriptions change?

The last one has produced the most revealing answers in our sessions so far, mostly silence, and it is the question the spec has quietly made important.

Through 2025 the governing question was whether MCP would last, and the honest answer was structured optionality: wrap it, abstract it, keep the exit cheap.

That question has closed, mostly through governance. When the major clouds, several banks and several payment networks fund the same neutral foundation, the standard’s survival is no longer the risk I would spend attention on.

The question that replaced it is about your own organisation: whether your platform can absorb a standard that has now demonstrated it will break compatibility when production experience argues for it, on no fixed schedule, with a twelve-month deprecation floor as the main guarantee.

Absorbing that is not one heroic capability but several dull ones: one gateway all MCP traffic crosses, generation handling done once in a shared layer, the official conformance suite in CI, an inventory you can query for “who still uses sampling,” and the semantic-layer controls the spec has told you, by omission, are yours.

The protocol spent this revision becoming ordinary. The work it leaves behind is ordinary too, which in infrastructure is usually what progress looks like from close up.

Spec references are to the 2026-07-28 revision at modelcontextprotocol.io; the changelog, the deprecated-features registry and the security best practices page repay direct reading. Two source cautions from writing this: at least one widely shared breaking-change summary describes the new Mcp-Method and Mcp-Name headers backwards, and a frequently cited rebuttal to the "MCP is just REST" argument rests on statefulness the spec has since removed. Where it matters, read the primary text. It is shorter than the commentary about it.