# MCP Tasks (async): Why Aren't Any Agents Supporting Them? — Cornelia Davis, Temporal

## Executive summary

Cornelia Davis discusses MCP Tasks, a specification designed to enable durable, long-running asynchronous interactions for tools and agents that cannot complete in a single request/response cycle. The core challenge is maintaining state and functionality across infrastructure failures (network blips, process crashes) or human delays. While the initial V1 protocol was complex and stateful, the evolution to V2 significantly improves scalability by moving toward a stateless core and structured extensions, making it more viable for large-scale distributed systems.

## Key takeaways

- The Problem of Long-Running Tasks: Traditional request/response models fail when work takes time. MCP tasks solve this by allowing an agent to invoke a tool, receive a handle, and interact with that handle asynchronously, surviving disconnections and crashes.
- Durability is Paramount: For the task to be reliable, it must be durable—meaning its state survives client disconnects, server outages, or human delays. This requirement adds significant complexity.
- V2 Moves Toward Statelessness: The major improvement in the MCP Tasks V2 specification is its move toward a stateless core and structured extensions, addressing the inherent difficulties of managing stateful protocols in large-scale distributed systems.

## Technical details

- MCP Task Flow: Instead of a direct response, invoking an MCP tool returns a handle. This task can progress through defined life cycle states (e.g., `working` $\rightarrow$ `input required` $\rightarrow$ `complete`/`fail`). The process involves server-side state machines mapping the task's lifecycle to the application's domain logic.
- V1 Protocol Limitations: The V1 protocol was criticized for being highly stateful and having limitations like `TaskList`, which lacked filtering, making it impractical for managing a large number of tasks (e.g., millions). The `task result` mechanism also involved complex long-running connections.
- V2 Architecture Improvements: The V2 specification eliminates the stateful `TaskList` endpoint. It introduces a stateless core and structured extensions, replacing long-session protocols with dedicated endpoints for signaling updates (analogous to signals in other systems). This significantly simplifies implementation.
- Scaling Challenge: Even V2 does not scale indefinitely if every client must poll or perform a `get` against millions of individual tasks. The future solution involves implementing a dedicated notifications protocol to allow clients to query for changes efficiently.

## Practical implications

- Building agents that handle complex business processes (like invoice processing) requires adopting durable task patterns to manage failures and human intervention.
- Implementing MCP tasks is technically involved due to the need to maintain state durability across all layers (client, server, network).
- Developers should prioritize using V2's stateless core design over older protocols for better scalability.

## Topics

Distributed Systems, Asynchronous Messaging, Protocol Design, State Management, Cloud Native Patterns, MCP Tasks, Temporal, Agoric AI Foundation (MCP)

Source: https://www.youtube.com/watch?v=s4r6nk5WsZw
