MCP's Tasks Extension Lets a Tool Call Run in the Background — If You Get the Object Shape Right

Model Context Protocol has quietly grown an answer to a problem every MCP server hits eventually: what do you do when a tool call takes thirty seconds, or thirty minutes? A CI pipeline, a batch export, a step that's waiting on a human to click approve — none of that fits the request-response model MCP started with, where the client just sits on the connection until a result comes back.

The Tasks extension is the fix. Instead of blocking, a server can hand back a task handle immediately: a taskId, a status, and enough metadata for the client to poll intelligently. The client checks in with tasks/get (or gets pushed a notifications/tasks/status update), waits for the status to land on completed, failed, or cancelled, and then — this is the part that trips people up — fetches the actual output with a separate tasks/result request. The task object itself never carries the result. It's pure status metadata: taskId, status, a required-but-nullable ttl, timestamps, and a couple of optional fields. If your mental model says "the completed task has the result attached," you'll write code that works in your own test and breaks against a spec-following client.