Every serious agent developer has hit the same wall: a tool that takes longer than a typical RPC round-trip. The data pipeline that runs for twenty minutes, the multi-repo evaluation, the overnight document classification — each one timed out, blocked the session, or forced an ad-hoc async hack. The MCP Tasks extension closes that gap by upgrading the protocol from "synchronous tool calls" to a call-now, fetch-later model.
The core idea: a durable handle
A Tasks-aware request returns immediately — not with the answer, but with a durable task handle. The real work continues in the background while the conversation moves on. The client can poll that handle for status or subscribe to updates, and pull the result whenever it's ready. Nothing blocks. The model isn't sitting on a stalled connection waiting for a long job, and the user isn't staring at a spinner that the client might kill on a timeout. The handle is the contract: hand it back later and you get the current state.
Why it's a first-class primitive, not a tool trick
The important design decision is that Tasks aren't tool-specific or client-specific. They're a generic primitive that works uniformly across request types, rather than something each tool author reinvents. That matters because the old workarounds — returning a job ID as a magic string, telling the model to "check back in a minute," polling a side-channel API — were all bespoke and brittle. Standardising the lifecycle means clients render progress consistently and an agent can reason about "in-flight work" as a real concept instead of guessing from free text.
When you actually need it
Tasks earn their keep for anything genuinely long-running: kicking off a batch ETL job, running an evaluation suite across many repositories, generating a large report, or classifying a backlog of documents overnight. The test is simple — if the operation can plausibly outlast a single conversational turn, it's a Task. Short, interactive calls (look up a record, post a message, run a quick query) should stay synchronous; wrapping them in Tasks just adds latency and ceremony. Reach for the heavier primitive only when the lightweight one stops working.
How it fits the 2026 spec
Tasks started as an experimental primitive in the 2025-11-25 revision and graduate to a proper extension with a defined lifecycle in the 2026-07-28 release candidate. That maturation matters if you're migrating: anything you'd previously built on the experimental Tasks API should move to the new lifecycle as part of the same upgrade where you go stateless and off deprecated SSE transport. Tasks also pair naturally with elicitation: a long job can pause to ask the user a clarifying question, then resume, without ever holding a connection open.
Going further
Tasks are part of the same enterprise-readiness push as MCP Apps and the stateless core — see what are MCP Apps for the UI half. Building servers? Start with build your first MCP server in Node.js and the Python tutorial. For orchestrating long jobs across agents, read multi-agent orchestration patterns or browse the developer-tools category.