The MCP Tasks Extension

Status in the 2026-07-28 spec: extension (official, io.modelcontextprotocol/tasks)

The MCP Tasks extension lets a server answer a slow tool call with a task ID instead of making the client wait. The client then checks on the task with tasks/get, sends any input the task needs with tasks/update, and collects the result when the task is done.

Tasks used to be an experimental part of the core spec. The 2026-07-28 changelog moved them "out of the core protocol and into an official extension" and redesigned them around polling. This page explains how the extension works, as of October 2026.

Why Tasks exist

Some jobs take minutes or hours: a CI pipeline, a bulk import, an approval that waits on a manager. Holding a request open that long breaks easily. The Tasks overview lists the problems Tasks solve:

• No long-lived connections. Many clients and proxies time out after a few seconds.
• Crash resilience. "A task ID is a durable handle." A client can resume polling after it restarts.
• Progress visibility. Each task carries a status and optional status message.
• Mid-flight interaction. A task can pause for user input without the server sending its own requests.

Tasks also fit servers that wrap an API which already uses job IDs, such as cloud deployments or queued work.

How Tasks work

1. Opt in. The client includes io.modelcontextprotocol/tasks in the extensions field of its per-request capabilities. The server lists the same extension in its server/discover response.
2. Create. When a supported request will be slow, the server returns a CreateTaskResult with resultType: "task", a taskId, a status, a time-to-live and a suggested polling interval.
3. Poll. The client calls tasks/get with the task ID, respecting pollIntervalMs.
4. Answer questions. If the status becomes input_required, the response includes an inputRequests map, such as an elicitation. The client answers with tasks/update.
5. Finish. At completed, the result field holds what the tool would have returned directly. At failed, the error field holds the JSON-RPC error.
6. Cancel (optional). The client can send tasks/cancel at any time.

Example: a task handle

This response is from the Tasks extension specification:

{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "resultType": "task",
    "taskId": "786512e2-9e0d-44bd-8f29-789f320fe840",
    "status": "working",
    "statusMessage": "The operation is now in progress.",
    "createdAt": "2025-11-25T10:30:00Z",
    "lastUpdatedAt": "2025-11-25T10:40:00Z",
    "ttlMs": 60000,
    "pollIntervalMs": 5000
  }
}

Task statuses

The last three are terminal. Once reached, the task's state does not change.

Rules worth knowing

• Only tools/call for now. The extension spec says tools/call is currently the only method that supports task-augmented execution.
• Durable before reply. A server "MUST NOT return CreateTaskResult until the task is durably created," so a tasks/get would succeed.
• Never surprise a client. Servers must not return a task to a client that did not declare the extension.
• Cancellation is cooperative. The server acknowledges tasks/cancel but is "not obligated to stop the work."
• Push is optional. Servers can send notifications/tasks through subscriptions/listen. Polling is the default.

What changed across spec versions

The 2026-07-28 changelog lists four redesign points:

• The blocking tasks/result method was replaced by polling with tasks/get.
• A new tasks/update method carries client input to a running task.
• tasks/list was removed.
• Servers can return task handles "unsolicited without per-request opt-in," once the client has opted in to the extension.

The extension spec lives in the ext-tasks repository. Extensions in general are covered in how MCP extensions work.

Tasks vs progress notifications

Progress notifications need the original request to stay open. If the stream breaks, the request is lost. Tasks survive that, because the handle lives on the server. Use progress for seconds and Tasks for minutes or more.

Client support

The extension support matrix, read on 28 October 2026, marked Tasks support in Claude (web), Claude Code and MCPJam. The matrix is community-maintained, so check each client's docs before you rely on it.

Common mistakes

• Returning tasks to clients that did not opt in. The overview says "Never return a task to a client that did not declare support."
• Polling too fast. Respect pollIntervalMs. Servers may rate-limit clients that poll faster.
• Losing the task ID. Clients should store task IDs durably so they can resume after a crash.
• Assuming cancel stops the work. A cancelled task may still finish as completed or failed.
• Using old 2025-11-25 methods. tasks/result and tasks/list are gone in the extension.
• Ignoring TTL. Servers may mark a task failed and delete it after its time-to-live passes.

Next step

Tasks handle long jobs. To give users a rich screen for the result, read the MCP Apps extension. For a hands-on walkthrough, see Lesson 29: Long-running tasks and MCP Apps. If you are planning a server that needs Tasks, our MCP development team can help scope it.

Frequently asked questions