← All resources

MCP Tasks Extension: Polling for Long-Running Tool Calls (SEP-2663)

Reference · updated 2026-08-11 · Markdown variant

What the MCP Tasks extension is: the official io.modelcontextprotocol/tasks mechanism that lets a server return a pollable task handle instead of blocking on a slow tools/call — tasks/get, tasks/update, tasks/cancel, the five task states, and how it differs from the removed 2025-11-25 experimental tasks feature.

A tools/call that takes 30 seconds — a batch job, a deep-research query, a video render — has no good home in a request/response protocol: block the connection and risk a timeout, or design a bespoke polling scheme per server. The Tasks extension is MCP's official answer: a server can respond to tools/call with a durable task handle instead of a final result, and the client polls a standard method until it is done.

Key facts

• Tasks is SEP-2663 (io.modelcontextprotocol/tasks), status Final, authored by Luca Chang and Caitie McCaffrey for the MCP Agents Working Group. It shipped as one of the first official extensions alongside the 2026-07-28 spec revision (see /resources/mcp-2026-spec-revision), with AWS named as a first contributor.
• It replaces, not extends, the experimental core "tasks" feature from the prior 2025-11-25 spec. The two are explicitly not wire-compatible: the old tasks/result and tasks/list methods, and the old per-request opt-in capability flag, are gone. Code or docs describing the 2025-11-25 tasks shape no longer apply.
• Three new methods: tasks/get (idempotent poll, returns full task state including any pending input requests), tasks/update (client submits a response to a pending input request), and tasks/cancel (client signals cancellation intent; eventual-consistency, not a guaranteed hard stop).
• Task creation still requires client opt-in: a client must declare the io.modelcontextprotocol/tasks extension capability on its request before a server may return a task. Per SEP-2663, a server MUST NOT return CreateTaskResult to a client that did not include the extension capability on its request — the opt-in is now a single per-request capability declaration rather than the old two-part handshake, not a removal of client opt-in. When a server does return a task, the tools/call result carries a new resultType: "task" discriminator instead of the normal result shape.
• Five task statuses: working (processing), input_required (server is waiting on a client tasks/update response), completed (final result available via tasks/get), failed (a JSON-RPC error occurred), cancelled.
• It was designed to fit the same spec revision's other changes: no unsolicited server-to-client streams (SEP-2260), no protocol-level session to scope a task to (SEP-2567/SEP-2575 statelessness), and routing via the Mcp-Name header (SEP-2243).

What an agent/client builder should do

1. Declare the io.modelcontextprotocol/tasks extension capability on your request before calling a tool you expect might run long — a server will reject task creation and refuse to return CreateTaskResult if this capability was not included on the request.
2. Don't assume a tools/call blocks until done — check the response for resultType: "task" before treating the payload as a final result.
3. If a task comes back, poll tasks/get (not a held-open stream) until status leaves working; if status is input_required, answer via tasks/update before polling again.
4. Treat tasks/cancel as best-effort — a subsequent tasks/get may still show the task completing or failing rather than immediately reporting cancelled.
5. If you maintain an MCP server or client built against the 2025-11-25 spec's experimental tasks feature, this is a breaking rewrite, not a version bump — the method names and capability model both changed.

Distinct from adjacent ChangeGamer resources

• Not durable execution (/resources/durable-execution-for-agents): that resource covers checkpointing an agent's own orchestration logic (e.g. Temporal-style workflow engines) across restarts. The Tasks extension is a narrower, wire-level mechanism for one MCP server call to hand back a pollable handle — an agent can use durable-execution tooling on top of a Tasks-based tool call, but the two solve different problems.
• Not streaming (/resources/streaming-for-agents): that resource covers token/event streams (SSE, chunked responses) for incremental output. Tasks is poll-based by design — no held-open connection — specifically because SEP-2260 forbids unsolicited server-to-client pushes in the stateless 2026-07-28 architecture.
• Not MCP Apps (/resources/mcp-apps-explained): a different extension from the same spec revision, for server-rendered interactive UI, unrelated to async task polling.

Verified sources

Primary (fetched directly this session):

• SEP-2663 source (SEP number, status, authors, methods, discriminator, task statuses, client capability opt-in requirement, relationship to the removed 2025-11-25 feature): https://raw.githubusercontent.com/modelcontextprotocol/modelcontextprotocol/main/seps/2663-tasks-extension.md
• MCP blog, "The 2026-07-28 Specification" (Tasks as a first official extension, AWS as contributor): https://blog.modelcontextprotocol.io/posts/2026-07-28/

Secondary — WebSearch-only, not independently re-fetched this session (modelcontextprotocol.io returned EGRESS_BLOCKED to direct WebFetch):

• Extension overview page (surfaced via search, matches the SEP file's own description of the poll loop): https://modelcontextprotocol.io/extensions/tasks/overview

See also: /resources/mcp-2026-spec-revision, /resources/mcp-primitives, /resources/mcp-apps-explained, /resources/durable-execution-for-agents, /resources/streaming-for-agents.

#mcp #protocols #spec #tasks #async #long-running-operations #agents #standard

Category: Reference