MCP Tasks Extension: Async Tool Calls, Polling, Input, and Cancellation

The MCP Tasks extension gives a server a standard way to turn a long-running tools/call into a durable task handle. Instead of holding one request open until a batch job, approval flow, or external job completes, the server can return a task result. The client then polls tasks/get, follows the suggested interval, supplies mid-flight input through tasks/update when needed, and sends tasks/cancel when the user asks to stop.

This article is verified against the MCP Tasks extension documentation and SEP-2663 on September 12, 2026. Tasks were experimental in the 2025-11-25 core specification and are an extension in the modern 2026-07-28 ecosystem. Do not mix the two wire models in one implementation without a compatibility plan.

When to use a task

• The operation can take minutes or hours, such as a batch export or build.
• The underlying service already returns a job ID and supports status polling.
• The client may disconnect and still needs to retrieve the final result later.
• The operation pauses for human input or approval.
• The work produces meaningful intermediate status but should not keep one request open.

A normal tool result is still the right choice for a short operation. A task adds durable state, storage, authorization, cleanup, polling traffic, and compatibility work. It should not be added only because a tool has several internal function calls.

Extension negotiation comes first

A server must check that the client declared support for the Tasks extension before returning a task result. A client that does not understand the extension cannot be expected to poll tasks/get or interpret the task discriminator. A compatible server may use a normal synchronous result as a fallback, reject the operation with a clear error, or expose a separate tool contract depending on the product's needs.

{
  "_meta": {
    "io.modelcontextprotocol/clientCapabilities": {
      "extensions": { "io.modelcontextprotocol/tasks": {} }
    }
  }
}

Creating a task from tools/call

The server responds with a task handle instead of the final tool content. The task should be durably recorded before the response is sent. The task ID must be unguessable, bound to the correct authorization context, and treated as sensitive state because it may grant access to status or results.

{
  "jsonrpc": "2.0",
  "id": 10,
  "result": {
    "resultType": "task",
    "task": {
      "taskId": "task-opaque-9d3f",
      "status": "working",
      "createdAt": "2026-09-12T09:00:00Z",
      "lastUpdatedAt": "2026-09-12T09:00:00Z",
      "ttlMs": 3600000,
      "pollIntervalMs": 5000
    }
  }
}

Polling tasks/get

The client polls tasks/get with the task ID and should respect pollIntervalMs rather than creating a tight loop. The server returns the current state. On completed, the result contains the final tool result. On failed, the error contains the failure details. The client must tolerate status changes between polls and should not assume that a single status response is a transactionally complete view of every worker side effect.

{
  "jsonrpc": "2.0",
  "id": 11,
  "method": "tasks/get",
  "params": { "taskId": "task-opaque-9d3f" }
}

• working means the task is still executing.
• input_required means the server needs a response before continuing.
• completed means a final result is available.
• failed means the associated operation ended with an error.
• cancelled means cancellation was recorded as the task's terminal state.

Mid-flight input with tasks/update

A task can enter input_required when a tool needs approval or another piece of user information. The client sends the accepted, declined, or cancelled input through tasks/update. The server may accept partial responses and keep the task waiting for the remaining keys. This separates reading state through tasks/get from writing a response through tasks/update.

Why tasks/cancel is not a kill switch

Cancellation is cooperative. The server acknowledges intent and should try to stop the work, but the worker may already be finishing, may have committed an external side effect, or may be running in a system that cannot interrupt the current step. A task can therefore remain working briefly after the acknowledgement or reach a different terminal state if completion won the race.

The cancellation path must be idempotent from the application's perspective. Repeated user clicks, network retries, or duplicate delivery should not create a second destructive operation. The worker should check cancellation state at safe points, release resources, and record which side effects already happened.

Durability, TTL, and authorization

• Persist task state outside the request process when tasks must survive disconnects or restarts.
• Expire task state according to ttlMs and document whether results are deleted immediately or retained for a bounded period.
• Authorize tasks/get, tasks/update, and tasks/cancel against the caller and task owner on every request.
• Do not treat a task ID as a substitute for authorization. If it acts as a bearer handle, make it high entropy and short-lived.
• Keep the task result bounded and apply the same privacy and redaction rules as a synchronous tool result.
• Use a poll interval that protects the task store and reflects how quickly the underlying work can change.

The current extension is not the old task model

The 2025-11-25 experimental task design included a different set of methods and fields. In the current Tasks extension, the core flow is tools/call returning a task, tasks/get for state and results, tasks/update for input, and tasks/cancel for cancellation. The extension documentation does not make every historical method interchangeable with the modern flow. Pin the protocol and extension versions in tests and SDK configuration.

Testing a task implementation

• Client does not advertise the extension: the server returns a synchronous result or a clear unsupported response.
• Task is durably created before the create response is sent.
• Duplicate tasks/get calls are safe and do not advance the underlying job.
• The poll interval is honored and a client handles a delayed or missing poll response.
• Input_required accepts a partial update and resumes only after required input is complete.
• Cancellation races with completion and produces a documented final state.
• Unknown, expired, or cross-tenant task IDs are rejected without revealing task data.
• A worker restart can recover or fail the task according to a documented policy.

What TrackMCP can and cannot tell you

TrackMCP can show that a server received the task-creating tool call, returned a task handle, received later polls or updates, and emitted explicit application outcomes when the application reports them. Those events help a server team understand whether the protocol path is being exercised and where observed latency accumulates.

TrackMCP cannot inspect a private worker queue, know whether an external provider committed a side effect, or infer that a task's completed status means the customer's business goal succeeded. Emit a deliberate workflow outcome when that stronger claim matters.