MCP Tasks v2 keeps the protocol stateless while requiring task state to persist on both the server and client sides.
2
V2 removes the server-side task list and uses task updates to return elicitation responses and continue processing.
3
Polling works for the demo, but notifications are needed to avoid wasting resources when many tasks remain idle.
Summary
Cornelia Davis explains MCP Tasks v2 through a purchase order workflow that records received goods, updates inventory, closes the purchase order, and processes an invoice. The invoice may take seconds, days, or weeks because it can wait for approvals, policy checks, backend checks, and user input. MCP tools can run synchronously or asynchronously, with asynchronous calls returning a task handle. The protocol is stateless, but each task is a durable state machine. Davis contrasts V1, where servers tracked all tasks and clients managed a complex elicitation flow, with V2, where task lists are removed, clients persist task IDs, and task updates carry responses back to the server. Her demo shows polling, approval, a cost-center request, and completion. She also explains why polling will not scale to large numbers of idle tasks and is working on notifications as a more efficient option.
MCP tasks let one tool run synchronously or asynchronously
Davis explains that a task is not a separate kind of tool. A tool can be invoked synchronously or asynchronously through an exchange between the client and server. An asynchronous invocation returns a task handle, which the client uses to interact with the long-running operation. The client can use that handle for actions such as checking progress and handling approvals. Her purchase order example includes invoice processing that may finish in a second or two, or may wait for approvals and backend checks for several days or weeks.
A stateless protocol still needs durable task state
MCP Tasks requires tasks to be durable state machines. Once a task starts, it must remain available and know which state it occupies while it moves through multiple steps. Davis separates the protocol's stateless communication from the task's stateful behavior. The task lifecycle includes working, input required, and terminal states. Terminal means completed successfully, failed, or canceled. This durability requirement affects server implementation, especially when the task can wait for input or resume after a long pause.
MCP Tasks V1 placed too much tracking and elicitation work on the server
In V1, the server had to retain all task handles because the client was not required to keep them. The protocol included task listing, status checks, cancellation, and task results. Davis found the client-side elicitation flow especially difficult because task results opened an SSE or standard I/O stream, and the client had to handle responses that could move a task back to working and then into input required again. She implemented the client side, but says the complexity explains why a general client such as Goose did not support V1 earlier.
V2 moves task persistence toward clients and simplifies updates
V2 removes task list and changes task result so it is no longer the channel for elicitation. The server no longer has to retain every in-flight task handle. Instead, the specification says clients should persist task IDs in durable storage, a point Davis is still discussing because she questions why it is not mandatory. The client polls for status, receives the information needed for an elicitation, waits for a user or another system to answer, and calls a task update API to continue the task.
The purchase order demo shows input-required states across several steps
Davis runs a purchase order process on a local open-source Temporal server. The client first polls while the task is working. It then receives an input-required state with the schema needed for an approval. After the user approves the invoice, the client updates the task and resumes polling. The invoice processor then asks for a cost center, which is submitted through the MCP client. The workflow completes after that response. Davis also points out an implementation bug where a failed invoice line item is being mixed with the MCP task lifecycle's failed state.
Clients must retain handles or tasks become orphaned
Davis advises teams using asynchronous MCP tools to make servers durable and ensure clients retain task handles. If a client loses a handle, the task becomes orphaned and cannot be recovered. She also says clients need a way to store large numbers of handles efficiently because an agent may execute many MCP calls and a deployment may have hundreds of thousands or millions of agent instances. The fixed purchase order flow is simpler than an agentic client, where many processes could be active at once.
Notifications are needed when polling would consume too many resources
Davis is implementing the notifications part of MCP Tasks because a million clients polling every few seconds against millions of tasks would use unnecessary network and compute resources. Many tasks may remain idle for long periods, so the desired behavior is to consume no resources while they wait. Notifications can provide a single push channel, but Davis says that channel still needs access controls so each client receives only events for tasks it can see. The notification protocol lets clients express interest in particular events, although she is still checking whether its security mechanisms are sufficient.
