MCP Tasks (async): Why Aren't Any Agents Supporting Them? — Cornelia Davis, Temporal
MCP Tasks aim to make long-running tool calls durable across disconnects and crashes. The proposed V2 removes session-heavy state, but polling scale and implementation complexity remain unresolved.
MCP Tasks gives a long-running tool invocation a durable handle and lifecycle spanning working, input-required, completed, canceled, or failed states. **V1**, released as experimental in November, requires tasks to survive client, server, connection, and human delays.
If an agent launches work that may outlive a request, persist the task and design for retries, restarts, human input, and result recovery. The proposed **V2** moves toward a stateless core, removes task listing, and replaces long-session input handling with a client update endpoint.
MCP Tasks gives a long-running tool invocation a durable handle and lifecycle spanning working, input-required, completed, canceled, or failed states. **V1**, released as experimental in November, requires tasks to survive client, server, connection, and human delays. If an agent launches work that may outlive a request, persist the task and design for retries, restarts, human input, and result recovery. The proposed **V2** moves toward a stateless core, removes task listing, and replaces long-session input handling with a client update endpoint. V2 is described as cleaner but still involved, and the talk says it was expected in **July** rather than presenting a finalized release. Per-task polling also does not scale to millions of tasks; a notification mechanism was promising but unfinished.
MCP Tasks defines durability as a protocol-level lifecycle rather than merely running work in the background. It clarifies the persistence, retry, recovery, cancellation, and human-input obligations behind long-running tools, while narrowing near-term adoption because V2 was not finalized and per-task polling still lacks a scalable replacement.