MCP tasks let a tool run in the background, return a handle, report progress, wait for human input, and later return a result.
2
Durability is the hard part because tasks must survive disconnected clients, failed processes, unavailable servers, and delayed human responses.
3
MCP Tasks V2 moves toward a stateless core, removes task listing, replaces long-lived input sessions with client updates, and keeps task lifecycle management intact.
Summary
Cornelia Davis explains why asynchronous MCP tools are harder to implement than their simple interface suggests. A tool call returns a task handle instead of an immediate result, but the task must keep working across dropped connections, crashed clients, unavailable servers, and human delays. Her invoice-processing demo shows task states moving from working to input required and then completion after an approval arrives. She compares Tasks V1 with the planned V2 design. V1 uses a stateful task-list endpoint and a long-lived connection for input elicitation. V2 moves toward a stateless core, makes tasks an extension, removes task listing, and lets the client send updates into a running task. Davis also warns that polling each task does not scale to millions of tasks. A notifications protocol may reduce that load, and she is working toward a simpler Fast MCP implementation.
MCP tasks turn an immediate tool call into a durable background process
Davis defines an MCP task as a tool invocation that runs in the background and eventually produces a response. Instead of receiving the result from the initial call, the client gets a handle and can interact with it. Her purchase-order example includes invoice validation against an ERP, approval from a person, another reconciliation step, and payment. The invoice tool cannot use a simple request-response exchange because the work may pause between steps. The task handle gives the client a way to follow the process while the backend continues operating.
Long-running tasks must survive failures and delays
The longer a task runs, the more chances it has to encounter an infrastructure problem. Davis names network blips, disconnected clients, crashed agents, unavailable MCP servers, and people who take time to respond. The specification therefore requires launched tasks to be durable. A task must survive clients or servers going away and remain available when the infrastructure returns. This changes the implementation from holding a request open to recording enough state that the client can reconnect and continue interacting with the same work.
The invoice demo connects task states to real workflow steps
Davis submits a purchase order through a dashboard even before starting the backend and client servers. The submission is retained, and once the services run, the invoice task moves through work submitted, working, and input required. The backend dashboard shows that the invoice was validated against the ERP and is waiting for approval. Davis approves it from the interface, the signal reaches the backend, retries occur while contacting the ERP, and the invoice is paid. The purchase order and its parallel back-office work then complete.
Tasks V1 defines a lifecycle but uses awkward stateful interactions
Tasks V1 defines states including working, input required, completed, canceled, and failed. Its tool semantics add task get, cancel, list, and result operations around an asynchronous call. Davis objects to task list because a reconnecting client may have to search through every task on the server. There is no filter on that endpoint, so finding one task among a very large collection becomes impractical. Task result also creates a difficult interaction when the server needs input, because the protocol opens a long-lived connection and elicits a response through it.
V2 separates a stateless core from the task extension
Davis says the V2 design is moving toward a stateless protocol, which she prefers for large distributed systems. MCP has a core with extensions, and tasks become an extension rather than behavior embedded in the core. Task list goes away. The lifecycle remains, because Davis considers its state model sound. The task result operation stays but no longer depends on the long session-based input protocol. Clients can send an update to a running task, which provides a cleaner way to deliver input such as an approval.
Clients must preserve task IDs because V2 removes server-side discovery
With task listing removed, a client needs to retain the IDs of tasks it may need to resume. Davis says the specification currently tells clients that they should persist task IDs, while also admitting that a lost ID cannot be recovered. She questions why this is not expressed as a stronger requirement. This detail matters when many agents are processing purchase orders at once. A client that disconnects must have its own record of the task identifier before it can reconnect and continue the interaction.
Davis says V2 is cleaner but still does not scale to millions of tasks if every client repeatedly sends get requests for its task. She is investigating a notifications protocol with a single endpoint that can report which tasks changed. Clients would then fetch only the task that needs attention instead of polling every task independently. She also says she is working toward an implementation in Fast MCP so developers can use the same framework for task-enabled servers that they already use for ordinary MCP servers.
"MCP tasks are allowing you to have an MCP tool that you can invoke and then it is long-running in the background, and then eventually you can get back some response."03:53
Who should watch
You are building an MCP client or agent that needs tools to wait for approvals, retries, or work that takes longer than one request.
Your system must resume tasks after a client disconnect, process crash, server outage, or delayed human response.
You are deciding whether to implement MCP Tasks V1 or wait for the cleaner V2 design and want to understand the protocol changes.
