Stateless, Yet Durable: MCP Tasks v2

Cornelia Davis explores the evolution of MCP Tasks, detailing the transition from v1 to v2. She highlights how v2's stateless protocol design supports durable, long-running agentic workflows by shifting durability responsibilities to the client and simplifying elicitation. The presentation includes a demo of a purchase order process and discusses future scalability enhancements through a notification-based approach.

August 19, 2026 4 min read

Stateless, Yet Durable: MCP Tasks v2 — source: https://www.youtube.com/watch?v=dGU0ibFPo9M

Cornelia Davis, a technologist at Temporal, delves into the intricacies of MCP (Microservices Communication Protocol) Tasks, specifically highlighting the advancements and architectural shifts introduced in v2. Drawing from her extensive background in distributed systems, including Cloud Foundry and Kubernetes, Davis emphasizes how MCP Tasks v2 addresses the challenge of building durable and reliable agentic workflows within a stateless protocol framework.

MCP Tasks Overview: Stateless Protocol, Stateful Tasks

Davis clarifies that ’tasks’ are not a special tool type but a mechanism for existing tools to be invoked asynchronously. The core concept is that a client receives a task handle to interact with a long-running process. While the protocol itself is stateless, the tasks are inherently stateful and durable. They are described as “durable state machines” because they need to persist their state over time, potentially for long durations across multiple steps. This durability requirement necessitates careful implementation on both the server and client sides.

MCP Tasks v1: The Durability Challenge

v1 of the protocol introduced a task lifecycle (working, input required, terminal – completed/failed/canceled). Key APIs included call tool, get status, cancel, list, and task results. A significant challenge with v1 was its complexity, particularly around handling elicitations (requests for input from the user/client). The task list API, which required the server to maintain a stateful list of all in-flight tasks, posed scalability and security issues. The task results channel for elicitation was notoriously complex for clients, involving polling loops, Server-Sent Events (SSE) streams, and intricate state management to handle responses and transitions (e.g., from input required back to working).

MCP Tasks v2: Simplifying for Scalability and Durability

Davis explains that v2 fundamentally simplifies the protocol. The task list API has been removed, shifting the responsibility of tracking in-flight tasks from the server to the client. The specification now explicitly states, “clients should persist task IDs to durable storage,” making client-side durability a critical requirement. The task result API has been redesigned, no longer serving as the elicitation channel. Instead, v2 introduces a simplified client-side protocol centered on polling and a new task update API. When input is required, the client polls, receives the necessary schema for the data, gathers the input, and then uses task update to provide the response, continuing the process.

Practical Demonstration: Purchase Order Processing

To illustrate v2’s capabilities, Davis presents a purchase order processing workflow. This long-running, multi-step process (e.g., validating against ERP, awaiting approval, reconciling, awaiting cost center) is ideal for asynchronous tasks. The demo, built on Temporal, showcases:

Workflow Execution: Submitting a purchase order that requires multiple elicitations.
State Transitions: The UI reflects changes from working to input required as the task progresses.
Client-Side Interaction: A visual task tracker demonstrates the task start, polling, receiving input required with a schema, and subsequently using task update to submit user decisions.
Durability in Action: The process reliably waits for external input and resumes processing.

Future Directions: Scaling with Notifications

Davis concludes by emphasizing the critical need for efficient scaling in agentic AI scenarios, where potentially millions of clients might be interacting with millions of tasks. The current polling mechanism, while simpler, becomes inefficient if many tasks are idle for extended periods, consuming network bandwidth and compute resources unnecessarily. Her ongoing work focuses on implementing the notifications part of the MCP Tasks protocol. This aims to enable a push-based model, where clients are only notified when a task state changes or input is required, allowing for zero resource consumption during idle periods. Davis also acknowledges the security implications of a single push channel for notifications, stressing the need for mechanisms to ensure clients only receive notifications for tasks they are authorized to access.