How does the call-now, fetch-later pattern work?

The client invokes a task-capable tool and gets back a receiver-generated task ID instead of a final result. The agent keeps doing other work while the client polls tasks/get with that ID until the task reaches a terminal state (completed, failed, or cancelled), then reads the result.

What are the MCP task lifecycle states?

A task moves through five states: working (running), input_required (paused, needs more data), completed (done, result ready), failed (errored), and cancelled (stopped by the client). Working and input_required are non-terminal; the other three are terminal.

What methods does the Tasks extension use?

Three: tasks/get to poll a task by ID, tasks/update to send data back into a task waiting in input_required, and tasks/cancel to stop a task you no longer need. The old blocking tasks/result method was removed in favor of polling.

Do I need to migrate from the experimental Tasks API?

Yes. Tasks first shipped as an experimental core feature in the 2025-11-25 spec, but the 2026 redesign moved it into an official extension and replaced the blocking tasks/result call with polling via tasks/get. Code built against the experimental API must be updated to the extension-based lifecycle.

MCP Tasks Extension: Long-Running Jobs Without Blocking Your Agent (2026)

📖 TL;DR

The MCP Tasks extension gives long-running work first-class support — no more tool calls that hang for 20 minutes.
It uses a call-now, fetch-later pattern: submit a job, get a task ID, then poll tasks/get while the conversation keeps moving.
Tasks moved out of the core protocol into an official extension in the 2026 redesign, rebuilt around the new stateless core.
Test how your server handles long jobs in MCP Playground — free, in the browser.

Some tools finish in 50 milliseconds. Others kick off a data pipeline that runs for 20 minutes.

Until 2026, MCP treated both the same way — one blocking request, one response. That falls apart the moment work outlives the request.

The MCP Tasks extension fixes this. It lets an agent start a long job, get a handle back, and check on it later — without freezing the chat.

If you build agents that run ETL jobs, multi-repo evals, or overnight batch work, this is the piece of the 2026 spec you actually need. Here is how it works.

What is the MCP Tasks extension?

The Tasks extension is an official MCP extension for long-running operations. It lets a server accept a request, return a task handle immediately, and do the real work in the background.

The client then polls or subscribes for the result. The model is free to answer other questions in the meantime.

Each task is a durable state machine. It carries the execution state of a request — running, done, failed — behind a single ID the receiver generates.

The reference lives at modelcontextprotocol/ext-tasks on GitHub, versioned independently from the core spec.

Why blocking tool calls break real agents

The problem: a plain tool call is synchronous. The client sends a request and waits for one response.

That is fine for a database read. It is a disaster for a job that takes minutes.

It gets worse. A long request holds a connection open. On the new stateless infrastructure, that means timeouts, dropped load-balancer connections, and gateways that give up mid-job.

Your agent looks frozen. The user assumes it crashed. The pipeline is still running, but nobody can see it.

The fix is to stop waiting. Return a receipt now, deliver the result later. That is exactly what Tasks does.

The call-now, fetch-later pattern

The Tasks flow has three moves. Think of it like ordering food with a buzzer.

Call now. The client invokes a task-capable tool. The server returns a task ID instead of a final result.
Do other work. The agent keeps talking to the user. The conversation is never blocked.
Fetch later. The client polls tasks/get with the ID until the task reaches a terminal state, then reads the result.

This decouples the length of the work from the length of the request. A 20-minute job and a 200-millisecond job use the same clean handshake.

The task lifecycle: five states

Every task moves through a small set of states. That gives the agent and the user real visibility instead of a spinner.

State	What it means
`working`	The job is running. Keep polling.
`input_required`	The task paused and needs more data from the client.
`completed`	Done. The result is ready to fetch.
`failed`	The job errored out. Read the error payload.
`cancelled`	The client called `tasks/cancel` and the work stopped.

working and input_required are non-terminal. The other three are terminal — once you hit them, stop polling.

The three methods: get, update, cancel

The 2026 redesign trimmed the API down to what agents actually use.

tasks/get — poll a task by ID to read its current state and, once terminal, its result.
tasks/update — send data back into a task that is sitting in input_required.
tasks/cancel — stop a task you no longer need so the server can free resources.

Notice what is missing: the old blocking tasks/result call. It is gone.

Instead of one method that hangs until the job finishes, you poll tasks/get. That plays nicely with stateless servers and plain HTTP load balancers.

Tip: back off your polling interval. Start at a second or two, then widen the gap for jobs you know run for minutes. Hammering tasks/get every 100ms just burns tokens and rate limits.

What changed from the 2025-11-25 version

Tasks is not brand new. It first shipped as an experimental core feature in the 2025-11-25 spec.

Production use exposed two problems. The blocking result call did not fit long jobs, and baking tasks into the core made the protocol heavier for servers that never needed them.

So the 2026 redesign made two calls:

Moved out of core into an official, independently versioned extension. Servers opt in.
Rebuilt around statelessness — polling via tasks/get replaced the blocking tasks/result method.

If you built against the experimental API, you must migrate. The lifecycle-based extension is the supported path going forward.

When should you reach for Tasks?

Not every tool needs this. Use Tasks when the work can plausibly outlive a single request.

Kicking off a 20-minute data pipeline or ETL job
Running a multi-repo evaluation across a large codebase
An overnight document classification batch
Large file conversions or media processing
Multi-step infrastructure provisioning

For a fast lookup or a single API read, skip it. A plain tool call is simpler and cheaper.

How MCP Playground can help

Before you ship a task-capable server, you want to see the whole lifecycle actually work — states, polling, and the final payload.

MCP Agent Studio connects a real AI model to your server and shows every call live. You watch the task fire, transition through working, and land on completed — no local setup.

Testing a long-running MCP server?

Connect it, fire a task, and watch every state change in your browser.

Test any MCP server free →

Frequently Asked Questions

What is the MCP Tasks extension? It is an official MCP extension that adds first-class support for long-running operations, letting a server return a task ID immediately and deliver the result later while the conversation keeps moving.

How do MCP tasks work? A client calls a task-capable tool, gets a receiver-generated task ID, and polls tasks/get until the task reaches a terminal state — completed, failed, or cancelled.

Is Tasks part of the MCP core protocol? No. It started as an experimental core feature in 2025-11-25 but was moved into an official, independently versioned extension in the 2026 redesign.

Conclusion

The Tasks extension is how MCP finally handles work that takes minutes, not milliseconds. Call now, fetch later, poll tasks/get, and never freeze the chat again.

The best way to trust it is to watch it run. Test any MCP server free and see the full task lifecycle end to end.