Most of the coverage of the 2026-07-28 Model Context Protocol release candidate is a subtraction story. The handshake is gone. Three primitives — Sampling, Roots, and Logging — are on the way out. Session state evaporated so a remote server can finally sit behind a boring load balancer. All true, all worth knowing before you ship.

But run your eye down the other half of the diff — the parts that add rather than remove — and a different protocol comes into focus. This revision is the one where MCP quietly stops being a fixed protocol you either implement or don't, and becomes an extensible platform with a governance layer. That is the sleeper story, and for anyone building a product on top of MCP it is the more consequential one.

Extensions became first-class#

Until now, a new MCP capability had exactly two fates: land in the core specification — at which point every client and every server had to carry it — or not exist. That is a brutal tax on experimentation. It means the spec grows only as fast as its most conservative implementer, and every good-but-niche idea competes for space in a document everyone has to support in full.

The 2026-07-28 revision replaces that with an Extensions Track. An extension gets a reverse-DNS identifier, lives in its own ext- repository with its own delegated maintainers, and versions independently of the core spec. Two peers negotiate which extensions are live through an extensions map on their respective capabilities — so support is opt-in, per connection, and explicit. A capability can ship as an extension, harden in real use, and only later — if ever* — be promoted into the core.

A protocol that can add capabilities without forcing them on everyone, and remove them on a published clock, isn't a spec anymore. It's a platform.

The immediate proof that the model is real: Tasks, the protocol's long-running-work feature, didn't get crammed into the new stateless core. It moved out, into an extension.

Tasks: long work that survives statelessness#

The stateless rewrite created an obvious problem. If any request can hit any server instance and there is no session to hang state on, how does a call that takes four minutes work?

The answer is the redesigned Tasks extension, and it is stateless by construction. A server can answer a tools/call not with a final result but with a task handle. The client then drives the work by polling tasks/get and, when it needs to, issuing tasks/update or tasks/cancel. Because the handle carries its own identity, any server instance behind the load balancer can answer the next poll — no sticky routing required. Task creation is server-directed: the client advertises that it can handle tasks, and the server decides which calls are heavy enough to run as one. (tasks/list, present in earlier drafts, was cut over scoping concerns — a small tell that the redesign was willing to ship less to ship clean.)

If you run agents that kick off real work — a build, a deep search, a batch — this is the primitive that lets that work outlive a single stateless request.

MCP Apps: your server gets a face#

The change with the most product surface is MCP Apps (SEP-1865). It lets a server ship interactive HTML that the host renders inside a sandboxed iframe. A tool call could always return text or structured data; now it can return an interface — a form, a picker, a small dashboard — that lives inside any compliant host.

The design is careful about the obvious objection, which is that letting a server inject UI into a host sounds like a security incident waiting to happen. Two constraints defuse it. First, servers declare their UI templates in advance, so the host can prefetch them and put them through security review rather than rendering whatever arrives at runtime. Second, every action the user takes inside that UI is dispatched as an ordinary JSON-RPC message that flows through the same consent and audit path as a direct tools/call. The interface is new; the trust boundary is the one you already reason about. It pairs naturally with the URL-mode elicitation flows the same spec keeps for OAuth and payments — the surfaces where a server needs to reach the human without ever touching the model context.

For a founder, this is the line item that changes what an MCP server is. It was a backend capability. It can now be a backend capability with a front end that renders wherever your users already are.

The governance layer is the actual news#

Underneath the extensions, the Apps, and the Tasks sits the piece that makes all of it safe to depend on: a formal feature lifecycle. Every feature now moves through Active → Deprecated → Removed, with a floor of at least twelve months between a feature being marked deprecated and the earliest point it can be removed — and deprecation and removal are separate proposals, so nothing disappears just because a clock ran out.

That sounds like paperwork. It is actually the load-bearing part. An extension ecosystem is only useful if you can tell what is stable, what is provisional, and how much runway you have when something is put on notice. Without the lifecycle, "first-class extensions" would just be a nice way to say "the spec fragments." With it, you can build on the core, treat extensions as versioned dependencies, and plan a roadmap that survives the next revision.

What to actually do about it#

Here is the part where the excitement meets the calendar. The specification is a release candidate and goes final July 28; the four Tier-1 SDKs are already in beta — Python mcp 2.0.0b1, TypeScript v2, Go 1.7.0-pre.1, C# 2.0.0-preview.1 — but they lead with the stateless core, not the platform layer. Apps, Tasks, and the extension machinery are specified; SDK support for them lands after. So the honest sequencing for a builder is:

The subtraction half of this release made MCP cheaper to run. The addition half decided what it becomes. A stable core, opt-in governed extensions, real server-side UI, and a deprecation clock you can plan against — that is not a protocol tightening its scope. That is a platform announcing itself, quietly, in the same diff that everyone read for the part about load balancers.