Wiki · Concept · Last reviewed June 25, 2026

MCP Tasks

MCP tasks are the experimental Model Context Protocol feature for turning long-running request work into durable, identifiable state machines that can be polled, cancelled, and resolved later.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: MCP, Tasks, AI Agents, Deferred Results, Agent Security

Definition

MCP tasks are an experimental utility in the 2025-11-25 Model Context Protocol specification. They let a requestor augment a request so the receiver can return a durable task handle quickly while the underlying work continues. The actual result can be retrieved later. In plain terms, tasks give MCP a call-now, fetch-later pattern for work that should not have to finish inside a single synchronous response.

The task feature is deliberately symmetrical. A requestor may be a client or a server, and a receiver may also be a client or a server, depending on the direction of the task-augmented request. The official spec describes tasks as durable state machines with receiver-generated task IDs, intended for polling and deferred result retrieval. The feature is useful for expensive computations, batch processing, external job APIs, and other workflows where a normal request-response exchange is too short.

How It Works

Task support is negotiated during initialization through the tasks capability. The capability is granular: parties declare which operations support task augmentation. On the server side, the 2025-11-25 spec lists support for operations such as tasks/list, tasks/cancel, and task-augmented tools/call. On the client side, it lists task-augmented sampling/createMessage and elicitation/create. A requestor should only use task augmentation when the receiver has declared the relevant capability.

The response pattern has two phases. A normal request returns the operation result directly. A task-augmented request returns task data after acceptance, while the underlying operation result becomes available later through tasks/result. A requestor can inspect task status with tasks/get, enumerate retrievable tasks with tasks/list where supported, and request cancellation with tasks/cancel.

States and Results

A task record includes a taskId, current status, optional status message, creation time, time-to-live, suggested polling interval, and last-updated time. The status vocabulary in the current spec includes working, input_required, completed, failed, and cancelled. The input_required state is especially important for agent workflows because a long-running operation can pause to request more input instead of pretending it can continue safely without it.

Result retrieval is strict. For terminal statuses, tasks/result returns what the underlying request would have returned: either a successful response or the relevant JSON-RPC error. For non-terminal statuses, the receiver may block until the task reaches a terminal state. Cancellation has its own boundary: a receiver should try to stop work and must transition a valid cancellation to cancelled, but the spec does not define deletion behavior after cancellation or after the task time-to-live expires.

Governance Requirements

A governed task system should treat the task ID as a durable accountability handle, not merely a polling token. Logs should preserve the requestor, receiver, original method, task ID, creation time, requested time-to-live, polling interval, status transitions, progress notifications, cancellation attempts, final result availability, and any user-input request that occurred while the task was active.

Task governance also needs resource policy. Long-running tasks consume compute, model budget, external API quota, credentials, and human attention. Limits should cover maximum runtime, maximum number of active tasks per requestor, retry policy, cancellation guarantees, result retention, privacy class, and what happens when a task outlives the user session that started it.

Failure Modes

Orphaned authority. A task continues after the user closes the client, changes intent, or loses visibility into the operation.

Polling without oversight. A dashboard shows that a task is still working, but not which tool, model, credential, or external API it is using.

Cancellation theater. The task status changes to cancelled while background execution continues to spend resources or produce downstream effects.

Expired evidence. A receiver deletes completed or cancelled task records before an incident reviewer can reconstruct what happened.

Source Discipline

Claims about MCP tasks should cite the 2025-11-25 tasks specification and state that the feature was experimental in that version. Lifecycle claims should cite the lifecycle page because task support is negotiated capability by capability. Release-history claims should cite the key-changes page or the official November 2025 MCP release post, both of which describe task support as part of that specification release.

Spiralist Reading

MCP tasks make delay visible. They give a long-running action a name, a status, a lifetime, and a place to ask for cancellation.

That is valuable because agentic systems often hide time. A user sees one prompt, but the machine may run searches, tools, model calls, retries, and approvals after the interface has moved on. Spiralism reads the task ID as a small public memory for the machine's unfinished work. It does not solve authority, but it gives authority somewhere to be inspected.

Open Questions

Sources

Return to Wiki