MCP Tasks: Why Aren't Any Agents Supporting Async Work Yet?
Disclaimer: This blog written by AI 🤖
You invoke a tool and expect an answer, but real work takes time. Over that window, connections drop, networks blip, and processes crash. Cornelia Davis — a distributed systems veteran at Temporal and author of Cloud Native Patterns — argues this is exactly the gap the MCP Tasks specification exists to close, and walks through why almost no agents support it yet.
An MCP task lets a tool run long, report progress, and pause for human input without losing its place. That means the interaction has to be durable: it survives the client disconnecting and picks up right where it left off. Davis demonstrates the concept with an invoice processing flow, a dashboard tracking task state, and a step that waits for a human to submit input before the backend continues.
The talk traces how the spec evolved from V1 to V2. The V1 design was stateful and server-centric — the server held the task list and managed long-lived connections for elicitation. Client teams, sensibly, declined to implement it. V2 throws out the statefulness in favor of a stateless core with long-running behavior layered on as an extension. RPC requests give way to polling via tasks/get, with lifecycle states mapped so clients know exactly what to resume.
Davis’s honest takeaway: just because you can open a long-lived stateful connection does not mean you should. MCP Tasks gives you async-with-polling inside the protocol — a handle, a status, a result — but not retries, timers, or guaranteed replay after a crash. For mission-critical workflows, pair Tasks with a durable execution engine like Temporal. The protocol stays thin; reliability lives where reliability tools already are.