MCP Tasks (async): Why Aren't Any Agents Supporting Them? — Cornelia Davis, Temporal
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
6:43
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
17:15
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
129s
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
730s
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
1035s
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
1340s
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.
Mentioned resources
- Temporal
- Agoric AI Foundation (MCP)
Channel & topics
Watch on YouTube · Back to latest
This independent, AI-assisted summary is provided for commentary and informational purposes. It may contain errors or omit important context. Please watch the original video for the creator's complete presentation. Video, thumbnail, and related copyrights belong to their respective owners.