The Tasks feature shipped in MCP's November 2025 spec as a core protocol capability. Eight months later, the same maintainers moved it out of core entirely. That demotion is the most instructive thing in the MCP 2026-07-28 release candidate - more so than the stateless redesign that everyone is leading with.
Understanding why Tasks moved tells you how MCP intends to evolve from here, and why the Extensions framework introduced in this release is the part worth internalising before the spec finalises on July 28.
What the MCP Extensions framework actually is
Extensions existed in the 2025-11-25 release but had no formal process behind them. SEP-2133 changes that: extensions are identified by reverse-DNS IDs, negotiated through an extensions map on client and server capabilities, live in their own ext-* repositories with delegated maintainers, and version independently of the specification.
That last part is load-bearing. Until now, a new MCP capability had one path: get written into the core spec, get shipped as part of a dated revision, and be stuck there until the next revision. The 2026-07-28 spec formalises extensions as the way new capabilities ship outside the core protocol - a deliberate move to keep the core small while letting the ecosystem experiment. New capabilities propose themselves as extensions first, prove production value, and only graduate into the base spec on the next date-stamped revision, if ever.
The governance mechanism behind this is an Extensions Track in the SEP (Specification Enhancement Proposal) process. Extensions get reverse-DNS identifiers, independent versioning, their own repositories with delegated maintainers, and a formal negotiation step through capability maps. The Extensions Track means a feature can prove itself as an extension before anyone argues about putting it in core.
Concretely: two extensions ship with the 2026-07-28 release as the first official entries - Tasks and MCP Apps. They are not in the core wire spec. A client that does not support them and a server that offers them simply do not negotiate them, and both sides keep working.
Why Tasks got moved out of core
Tasks shipped as an experimental core feature in 2025-11-25, but production use prompted moving it out of the core protocol into an official extension (SEP-2663).
The redesign was substantial.
It replaces blocking tasks/result with polling via tasks/get, adds tasks/update for client input, removes tasks/list, and lets servers return task handles unsolicited.
The removal of tasks/list is instructive.
Task creation is server-directed: the client advertises the extension and the server decides when a call should run as a task. tasks/list is removed because it cannot be scoped safely without sessions.
The stateless core and the Tasks lifecycle were redesigned together - you cannot cleanly list "all tasks for this client" when there is no longer a session that defines what "this client" means at the server.
The new pattern is simpler and more honest about what the protocol can actually see.
The Tasks extension reshapes long-running operations for the stateless model: a tools/call can now return a task handle instead of a result, and the client drives the task lifecycle with tasks/get, tasks/update, and tasks/cancel - no persistent connection required. This is how you build agents that kick off multi-minute operations without holding a socket open.
Anyone who built against the 2025-11-25 experimental Tasks API will need to migrate - that migration is not optional.
If your server currently uses the core Tasks API,
it is now a separate extension (SEP-2663) with a new polling lifecycle - tools/call returns a handle, clients poll with tasks/get, and the tasks/list method is gone.
What MCP Apps changes for server authors
The second extension that ships with this release is MCP Apps (SEP-1865). MCP Apps lets servers ship interactive HTML interfaces that hosts render in a sandboxed iframe. Tools declare their UI templates ahead of time, so hosts can prefetch, cache, and security-review them before anything runs.
The security model stays intact. The rendered UI talks back to the host over the same JSON-RPC base protocol used everywhere else in MCP, so every UI-initiated action goes through the same audit and consent path as a direct tool call. For server authors, this matters because it standardises something many teams had been doing ad hoc - shipping embedded interfaces with no agreed-upon sandboxing or consent model. MCP Apps standardises the embedded-UI experiments everyone has been doing ad hoc: server-rendered HTML in sandboxed iframes, with UI templates declared ahead of time so clients can prefetch and security-review them.
A teammate like Beagle, wired into Slack via MCP, could surface a structured approval interface directly in a thread without a separate frontend deployment - every action still running through the same JSON-RPC path that logs and governs any other tool call.
Beagle in action#ops-team, 11:02amWhat the deprecation policy means in practice
One thing the Extensions framework needed to work is a credible deprecation promise. SEP-2596 guarantees a minimum 12 months between deprecation and removal; SEP-2484 ties Standards Track SEPs to conformance suite scenarios before Final status.
Roots, Sampling, and Logging are deprecated as of the 2026-07-28 release candidate - not removed. Under the new lifecycle policy, a feature must stay deprecated for at least 12 months from its deprecating revision before it is eligible for removal, so these features remain in the spec for now. Nothing breaks on July 28. A remote server shipped today against the 2025-11-25 protocol keeps working after July 28. Current clients keep speaking it. Nothing is removed on day one.
The compounding risk, though, is real. The deprecation treadmill means every revision you skip compounds, and the 12-month clocks on sessions, the handshake, Roots, Sampling, and Logging are already running - migrating late means doing all of it at once, under a deadline you no longer control.
Is this actually new, or just tidying?
The honest answer is both. The stateless redesign is genuinely new infrastructure. The Extensions framework is mostly governance: a formal process for something the ecosystem was doing informally. But governance, done right, is what lets a protocol grow without fracturing.
The extensions framework solves the governance problem of where to put features that don't belong in a wire spec. That problem sounds bureaucratic until you hit it: you need long-running job tracking, you wire something up against the experimental Tasks spec, and then the spec changes under you because it was never properly stabilised. There was no standard caching metadata, no standard tracing format, no formal deprecation policy, and extensions like Tasks lived "experimentally in the core spec" with no governance about how they would graduate or evolve. The 2026-07-28 release fixes that structural gap.
MCP is starting to act like an open protocol with real production users, not a research experiment from Anthropic. Date-stamped versioned specs, an SEP process, formal SDK tiers, and a published roadmap with priority areas all push it in the direction of HTTP or LSP, not a vendor SDK.
For teams building MCP servers that handle real agent workloads - not demo tool calls but actual multi-step, multi-minute operations - the Extensions framework is the part of this release that will shape your architecture for the next two years. The stateless core gets the attention, but the extension model is what determines how MCP adds capabilities without breaking what you already shipped.
If you are starting a new MCP server this week, target the 2026-07-28 RC directly and declare support for the Tasks and MCP Apps extensions from the start. If you have an existing server,
start by deleting your Mcp-Session-Id routing rules and your shared session store
, then audit whether you are using the 2025-11-25 experimental Tasks API - that is the migration with the shortest deadline.