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.
This identifies durable task lifecycle—not merely asynchronous execution—as the missing contract for work that can outlive connections or await people. It clarifies the persistence, retry, restart, cancellation, and recovery obligations of MCP clients and servers, while the unfinished V2 and notification design mean large-scale interoperability remains unsettled.