You trigger an agent in your IDE at 2:47pm - "reindex the docs and summarise what changed." Forty seconds later the client times out. The task is gone. No result, no error, no way to know if it ran. You open a thread in Slack and ask a teammate if they know what happened.
That is the failure mode the MCP Tasks extension is designed to close, and it arrives in the final spec today.
What the MCP Tasks extension actually does
MCP tools are fundamentally request/response. Clients enforce their own tool-call timeouts - not standardized by the spec and varying per client, but often in the 30-60 second range. For fast lookups that is fine. For anything resembling real agent work - a code search across a large repo, a docs reindex, a multi-step research pass - it is not.
SEP-1686 introduces a task primitive to the Model Context Protocol. It is a clean "call-now, fetch-later" execution pattern that lets agents submit long-running operations, go do other work, and check back when ready.
Concretely:
a server responds to tools/call with a task handle instead of a synchronous result. The client then drives the lifecycle - and for long-running agent operations, this pattern is significantly cleaner than the previous experimental implementation.
The redesign 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.
That last part matters more than it looks: a server can now proactively push a handle to a client mid-conversation, not just in response to a call.
For long-running agent operations this pattern is significantly cleaner than the previous experimental implementation. The stateless model also means task state can live anywhere the server can reach - not in session memory. Sticky sessions were what made async tasks fragile before. Remove the sessions, and the task handle can survive a server restart.
Why Tasks was pulled out of the core spec
Tasks (io.modelcontextprotocol/tasks, SEP-2663) handles long-running work. Tasks first shipped as an experimental core feature in 2025-11-25, but production use led to moving it out of the core protocol and into an official extension.
This is worth dwelling on. The MCP team did not promote Tasks because it worked well in 2025 - they redesigned it because it did not. 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 spec introduces a formal extensions framework. Extensions get reverse-DNS identifiers, their own repositories, delegated maintainers, and versions that move independently from the main spec. Moving Tasks into that framework means it can iterate on its own schedule - retry semantics, result-retention policy, cancellation guarantees - without waiting for the next date-stamped core revision.
In the 2026 MCP roadmap, retry semantics and result-retention policy are still called out as open gaps. That is a clue that the shape is real, but the surrounding policy is still settling. Teams building on Tasks today should treat result-retention as application-layer concern for now.
OpenAI, Google, Microsoft, and AWS have all built MCP into their agent stacks, and more than 10,000 public MCP servers are running in production with monthly SDK downloads passing 97 million. Most of those servers are still synchronous. Tasks is the first clean path to making them not be.
What this changes for teams running agents in Slack and CI
The practical question is not "is Tasks interesting" but "which workloads actually need it."
Short answer: any tool call that is slower than your client's timeout, runs inside a CI pipeline, or needs human input partway through.
- Docs indexing and search reindexing - these routinely exceed 60 seconds on large codebases. With Tasks, the agent submits the job, returns a handle to the user in Slack, and posts the result when it is done.
- Multi-step research agents - a teammate like Beagle drafting a weekly digest pulls from several sources sequentially. A Tasks handle means the draft-and-approve flow can survive a transient disconnect without losing work.
- CI-triggered agents - a pipeline triggers an MCP tool on push, the connection closes after the pipeline step, but the task persists and posts its result to the right Slack channel when it completes.
- Approval-gated workflows -
tasks/updatelets a human send input back to a running task. This is the primitive that makes "draft → human reviews → agent continues" a protocol-level pattern rather than a bolt-on.
Beagle in action#eng-deploys, 3:02pmThe Tasks extension is built for long-running operations that need retries, expiry, and lifecycle tracking. If you have ever tried to wrap a 3-minute search index build inside a single MCP tool call and watched the client time out, Tasks fixes that.
The MCP Apps extension is the other thing worth watching
Tasks gets less press than the stateless-core story, but the other first-class extension in today's spec - MCP Apps - is the one that could change how teams interact with agents entirely.
MCP Apps (SEP-1865) 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 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.
In practical terms: an MCP server for your incident tracker could return a triage form instead of raw JSON. The form renders inside the chat client, the engineer fills it in, and the action fires through exactly the same authorization path as a typed command would. Clients like ChatGPT, Claude, Goose, and Visual Studio Code have already shipped support for this capability, with more clients coming soon.
The non-obvious consequence:
Tasks provide first-class support for long-running async work.
Pair Tasks with MCP Apps and you have the primitives for a workflow where an agent kicks off a long job, surfaces an approval UI when it needs a human decision, waits for the input via tasks/update, and then continues - all through one protocol, one consent path, one audit log.
MCP Tasks extension: common questions
What is the MCP Tasks extension?
The MCP Tasks extension (SEP-2663, identifier io.modelcontextprotocol/tasks) is a first-class extension in the 2026-07-28 MCP specification that gives servers a standard way to model long-running work. Instead of blocking on a synchronous tool response, a server returns a task handle. Clients poll via tasks/get, send mid-task input via tasks/update, or cancel via tasks/cancel.
Do I have to migrate Tasks if I used the experimental 2025-11-25 version?
Yes.
Anyone who shipped against the experimental 2025-11-25 Tasks API must migrate to the new extension lifecycle.
The redesign is not backward-compatible - blocking tasks/result is gone, replaced by polling, and task handles can now be returned by servers unsolicited. Check your internal servers before deploying clients that expect 2026-07-28 behaviour.
Which MCP clients support the Tasks extension today?
The final specification is published on July 28, 2026. The ten-week window is for SDK maintainers and client implementers to validate the changes against real workloads; under the SDK tier system, Tier 1 SDKs are expected to ship support within this window. That means the official Anthropic-maintained Python and TypeScript SDKs should have support by early October. Third-party clients will vary - check your client's changelog before assuming Tasks is available.
What is the difference between MCP Tasks and MCP Apps?
They solve different problems at the same layer. Tasks is about execution time - it lets tool calls outlive a synchronous connection. MCP Apps is about output richness - it lets servers return interactive HTML interfaces instead of plain text. They compose: a long-running task can surface an approval form via MCP Apps mid-execution and wait for user input before continuing.
Is the 2026-07-28 spec live yet?
The release candidate is available today and the final specification ships on July 28, 2026. If you are reading this on publication day, the spec is final. The SDK support window runs for ten weeks from May 21.