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

The Challenge of Long-Running Operations in Distributed Systems

Cornelia Davis, a veteran in distributed systems and author on cloud-native patterns, addresses a critical gap in Machine Learning and AI tooling: the inability of agents to effectively handle long-running, asynchronous tasks. While tools are invoked expecting an immediate answer, real-world operations, such as invoice processing, can take significant time, leading to inherent challenges: network blips, connection drops, human input delays, and process crashes. The MCP tasks specification aims to close this gap by providing a durable interaction model for such operations.

The Imperative of Durability in MCP Tasks

The core problem with traditional request-response models for long-running work is their fragility. The longer an operation runs, the higher the probability of infrastructure issues like network interruptions or server failures. Additionally, tasks often require human interaction, introducing unpredictable delays. The MCP tasks specification mandates durability: once a task is launched, it must survive client disconnections, server outages, and human delays, allowing for seamless resumption of interaction when infrastructure recovers. This concept is central to the specification.

Illustrative Use Case: Invoice Processing Demo

To ground these abstract concepts, Davis demonstrates an invoice processing flow. A purchase order triggers a series of steps:

1. Record goods received.
2. Parallel processing:
   • Back office tasks (inventory update, notifications).
   • Invoice processing via an MCP tool. The invoice processing itself is a multi-step, long-running task: ERP validation, human approval request, reconciliation, and further human input. This scenario highlights the need for an asynchronous model where the tool reports progress, pauses for human input, and can be signaled to continue, rather than a single request-response cycle. Crucially, the demo shows tasks persisting and progressing even if the backend server was not running at the initial submission, emphasizing durability.

MCP Tasks V1: Architectural Limitations and Client Implementation Hurdles

The initial MCP tasks V1 specification, released in November and marked experimental, introduced a lifecycle for tasks (Working, Input Required, Completed/Canceled/Failed) and specific tool semantics (tools/call for async initiation, task get, task cancel, task list, task result). However, V1 presented two significant architectural challenges that deterred client implementation:

1. task list Endpoint Scalability: This endpoint allowed clients to query the server for all outstanding tasks, crucial for resuming work after a client disconnection. However, it lacked filtering capabilities. For systems with a large number of tasks (e.g., millions), clients would have to iterate through an immense list to find their specific task, rendering it unscalable and practically unusable for production environments.
2. task result for Human Interaction: Handling human input (e.g., approval/rejection) in V1 involved establishing a long-running, stateful connection between the client and server. The server would elicit a response from the client, creating a complex protocol for interactivity. This approach was highly susceptible to connection failures; if the connection dropped, re-establishing and resuming the interaction precisely where it left off was exceedingly difficult, significantly complicating client-side durability logic. The complexity led to an “ugly” client-side protocol handler.

MCP Tasks V2: Embracing Statelessness and Extensibility

Recognizing the limitations of V1, a new V2 specification, anticipated for July, introduces radical changes aimed at simplifying implementation and improving scalability:

1. Stateless Core and Extensions: V2 refactors MCP into a stateless core, with tasks now defined as an extension. This modular design aligns with modern distributed systems principles, promoting a cleaner, more maintainable architecture.
2. Simplified Interaction Model:
   • The problematic task list endpoint is removed entirely, eliminating the scalability bottleneck.
   • The complex, stateful task result mechanism for human input is replaced by a client-initiated task update endpoint. This allows clients to “signal” into a long-running task with updates, akin to how Temporal workflows handle external signals. This shift dramatically simplifies the client-server interaction for human-in-the-loop scenarios.
3. Unchanged Task Lifecycle: Despite these architectural shifts, the fundamental life cycle management of tasks (Working, Input Required, etc.) remains conceptually sound and consistent between V1 and V2. This mapping from task lifecycle states to the application’s domain state machine is a critical part of implementing tasks.
4. Client-Side Persistence Mandate: With the removal of task list, clients are now explicitly required to persist task IDs. Without this client-side durability, there is no mechanism to retrieve or resume interaction with a previously initiated task.

Remaining Challenges and Future Outlook

Even with the significant improvements in V2, implementing MCP tasks remains involved due to the inherent complexity of distributed, durable long-running operations. Davis highlights two key areas for ongoing work:

1. Scaling Notifications: While task list is gone, continuously polling individual tasks for status updates by millions of clients is still inefficient. A proposed notifications protocol is under development to allow clients to subscribe to changes, receiving specific task updates without constant polling, significantly improving scalability.
2. Simplified Implementation with FastMCP: To lower the barrier to adoption, efforts are underway to integrate the MCP tasks specification into FastMCP, aiming to provide a simpler framework for developers to implement these sophisticated capabilities.

In essence, the lack of widespread MCP task support stems from their initial experimental nature, the profound complexity of ensuring durability in distributed environments, and the rapid evolution of the specification from V1 to V2, addressing crucial architectural flaws. The ongoing work promises to make these powerful capabilities more accessible and scalable for the ML and AI community.

• Tags:
• Microservices
• Distributed Systems
• Temporal
• Cloud Native
• Asynchronous Programming
• API Design
• Human-in-the-Loop
• Durability
• Workflow Management
• MCP Tasks
• Long-Running Processes
• Stateless Protocols
• FastMCP
• Agent Programming