MCP Tasks
Follow eligible MCP tool calls that continue asynchronously and retrieve their status and results.
MCP Tasks let an MCP server return a durable handle while an eligible tool call continues. When Tasks are enabled for a project with a supported tool profile, RouterMCP can proxy this flow for upstream servers that advertise the compatible Tasks profile.
Compatibility
For task-capable calls, RouterMCP uses MCP core version 2026-07-28 with the stable v2 io.modelcontextprotocol/tasks extension schema. The core version by itself does not enable Tasks. A client declares Tasks support in the per-request capabilities of each eligible tools/call and every tasks/get, tasks/update, or tasks/cancel request. RouterMCP independently declares its own support to the upstream and checks the upstream's current discovery response. RouterMCP supports tasks/get, tasks/update, and tasks/cancel.
Task creation starts with the ordinary tools/call request. The server decides whether each eligible call completes synchronously or returns a task handle. A task-capable client must be ready for either response. RouterMCP returns its own task ID and maps follow-up requests to the original project, caller, and upstream server; it does not expose the upstream task ID. For task responses, RouterMCP preserves standard Result _meta and bounded extension fields while identifying itself in server metadata. RouterMCP uses the task-aware path only when the request declares Tasks support and the project profile, feature gate, protocol version, and current upstream discovery qualify. On that path, it skips ordinary result-cache reads and writes, including when the upstream completes synchronously. Synchronous results still pass through normal response processing and project response limits. Only actual task envelopes and tasks/get recovery bypass generic truncation or compaction; ordinary fallback calls retain normal cache eligibility and response limits.
See the MCP protocol guide for connecting to RouterMCP. For the protocol contract, read the MCP core versioning specification, the stable Tasks extension specification, and its pinned schema.
Task status
| Status | Meaning |
|---|---|
working | The upstream is processing the request. |
input_required | The upstream is waiting for an input response. The dashboard labels this “Waiting for input.” |
completed | The request completed at the protocol level. Its tool result may still report isError: true. |
failed | The request ended with a JSON-RPC execution error. |
cancelled | The upstream reports that the task was cancelled. |
Use tasks/get to read task state. A completed task carries its final tool result; a failed task carries its JSON-RPC error. tasks/update can answer supported form-elicitation requests only when the original tools/call and the tasks/update request declare form support and the current upstream supports it. Other input interactions are not supported through Tasks. tasks/cancel asks the upstream to stop the work. Cancellation is cooperative: an acknowledgement means the request was accepted, not that the upstream has reached the cancelled state.
An unexpired retained terminal snapshot, including its result or error where present, may be read after the upstream's task TTL has elapsed, provided the original project access and upstream authorization still pass. An old nonterminal observation is not proof that the task has completed. Encrypted task payloads are retained for up to 24 hours from storage; task metadata and history are retained for up to 90 days while the project remains retained. Project deletion can remove them earlier.
Project dashboard
When the feature is enabled for a project, its Tasks view groups records by All, Pending, Completed, Failed, or Cancelled. Pending includes working and input_required. The independent Assigned filter shows tasks with a human assignee; assignment does not change protocol status.
Team members and people with direct project membership can review safe task metadata and the status and assignment timeline. Direct project access does not grant team-level mutation rights. In the dashboard, sensitive task inputs and results remain available only to the original user caller while that caller's project access and upstream authorization remain valid. Tasks started with an API key do not expose payloads or protocol controls in the dashboard. Assigning a task does not grant access to its payload or control over the upstream task.
If an upstream operation is unavailable or the original authorization no longer passes, RouterMCP returns an error rather than silently substituting another action.