MCP Tasks is an official MCP extension for work that cannot finish inside one short request. Instead of holding the connection open, the server creates a task with a state and lifetime. The client keeps its task ID, checks progress later, may provide additional input where supported, and retrieves the final result.
The One-Sentence Definition
MCP Tasks replaces “call a tool and wait in place” with “take a claim ticket, check back later, and collect the result when it is ready.”
Normal calls fit operations such as reading one file or fetching one record. Deep research, batch analysis, long code execution, and external approval can run for minutes or longer. Stretching a synchronous request across that work creates timeout, disconnection, and recovery problems.
Why It Is Getting Attention Now
Tasks first appeared experimentally, then were redesigned from early-adopter feedback and moved into the official SEP-2663 extension with the MCP 2026-07-28 release. The new MCP roadmap published in August again highlighted Tasks, event delivery, and a more complete long-running-work composition, pushing the term into current MCP development discussions.
It closes a practical infrastructure gap: agents increasingly perform long-horizon work, but a tool protocol that assumes every operation returns immediately will fail exactly where reliability matters most.
How It Works
Tasks is negotiated, not behavior a server can impose on every client. The client opts in through request metadata; only then may the server answer with a created task. The client subsequently uses tasks/get until the task reaches a completed, failed, cancelled, or otherwise terminal state.
A task needs an explicit lifecycle: state, creation time, expiration policy, cancellation behavior, and a result-retention window. The extension currently centers on long-running tool calls. Future webhooks or channels may reduce polling, but polling remains the simplest baseline across environments.
How It Differs from Tool Calling and a Queue
Tool Calling describes how a model expresses “use this tool.” MCP Tasks describes how the client and server manage that particular call when execution takes a long time. One is invocation intent; the other is execution lifecycle.
It is not a complete job queue either. The extension defines visible protocol state and operations, but the server may use a database, message broker, or in-process runner internally. Production implementations still own persistence, retries, idempotency, quotas, and crash recovery.
Good Use Cases
Tasks fit work that takes materially longer than a normal request and should survive a temporary disconnect: scanning a large repository, researching many documents, processing a media batch, waiting for a deployment check, or pausing for human approval.
Millisecond- or second-scale calls usually should remain direct. Turning every read into a task adds creation, polling, cleanup, and latency without a reliability benefit.
Limitations and Practical Rules
Both sides must support the 2026-07-28 protocol revision or later and the Tasks extension. The redesigned extension is not wire-compatible with older experimental Tasks implementations. Servers also need timeouts, expiration cleanup, concurrency limits, cancellation, and authorization that prevents one user from reading another user’s task.
Polling cadence matters. Poll too fast and background work becomes foreground load; poll too slowly and the interface feels frozen. A good client shows the latest state, a suggested next check time, and whether a failed task can be retried.