Claude Code MCP Tasks: Long-Running Tools That Ask You Things

Last updated: October 24, 2026

Claude Code can now treat a slow MCP tool call as a task: the server answers right away with a task id, Claude Code keeps working, polls for the result, and can show you a question the tool needs answered along the way. David Soria Parra, an MCP co-creator at Anthropic, announced support in his keynote at AGNTCon + MCPCon North America on October 22, 2026, and Anthropic's ClaudeDevs account said a day later that Tasks and Elicitations were in the CLI, according to Upstash's write-up. This post is what the Claude Code MCP docs say a call needs in order to become a task, where it will silently not happen, and what a server author does Monday morning.

What the sources say#

The MCP tasks extension lets a server return a durable handle instead of blocking. The flow is short:

1. The client declares io.modelcontextprotocol/tasks in the per-request capabilities it sends.
2. For a slow call, the server returns a result with resultType: "task", a taskId, a status, a TTL and a poll interval.
3. The client polls tasks/get until the status is completed, failed or cancelled.
4. If the task needs input, it moves to input_required and the client answers with tasks/update.

The extension page is explicit about the reason this exists: a blocking connection is hard to keep open past a few seconds, a task id survives a client restart, and the server decides per request whether to create a task. It also says never to return a task to a client that did not declare support. For the wider protocol context, see our breakdown of the 2026-07-28 MCP release, where Tasks became a first-class extension.

On the Claude Code side, the docs list the conditions a call must meet. Paraphrasing the page:

• The server is HTTP, stdio or a claude.ai connector on protocol revision 2026-07-28. Setting MCP_SDK_GENERATION=v1 or MCP_PROTOCOL_NEGOTIATION=legacy rules tasks out.
• The session fetches feature flags, so it is not on a third-party provider such as Amazon Bedrock and does not have telemetry or flag fetching turned off.
• Anthropic has turned tasks on for your kind of session. On v2.1.304 or later that covers terminal CLI sessions, Agent SDK sessions and GitHub Actions runs. The VS Code extension and desktop app do not have MCP tasks.
• The call comes from the main conversation, not a subagent.
• The session is interactive, or an Agent SDK or claude -p --input-format stream-json run with CLAUDE_AUTO_BACKGROUND_TASKS at 1. A one-shot claude -p "<prompt>" run does not get tasks.

Anything else stays an ordinary blocking tool call. That list is the whole story for most people: you can have a task-capable server and still never see a task.

Elicitation is the second half. In an interactive terminal session, Claude Code serves an elicitation/create request as a small form, then retries the call with the answer. Per the docs, roots/list is served everywhere, but elicitation only in interactive terminal sessions. If Claude Code cannot serve a request, it asks the server to cancel the task. We covered the underlying mechanics in MCP client features explained.

The angle: who actually needs this#

Claude Code already moves a main-conversation MCP call that is still running after two minutes to the background, with no change on the server, as the Upstash post points out and the docs describe under automatic backgrounding. So tasks are not what makes a slow tool usable in the CLI. What they change is the server side of the bargain:

• Serverless servers. A backgrounded call still needs the server to hold the request open. A function with a 30 second limit cannot do that. A task returns in milliseconds and the work runs elsewhere. Upstash's example stores each task in Redis and executes it in a fresh invocation via QStash; that is a vendor library, so treat it as one implementation, not the only way.
• Human approval gates. A deploy tool that needs a yes before it proceeds can pause in input_required instead of failing or guessing.
• Resume. The docs say Claude Code keeps asking about a task after a session resume, and that a server should keep the id answerable across connections. If the server rejects the id, you get an outcome unknown. line, and the docs warn that a second call may repeat the work.

Who loses: server authors who built their own polling tools (start_job, job_status) to work around blocking calls. Those still work for every client that does not declare the extension, so keep them, but the native path is now the better default for Claude Code users.

What a builder does Monday#

Check the client first, then decide. This is the exact shape Claude Code sends, per Upstash's captured request, trimmed to the relevant keys:

{
  "method": "tools/call",
  "params": {
    "name": "generate_report",
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": { "form": {}, "url": {} },
        "extensions": { "io.modelcontextprotocol/tasks": {} }
      }
    }
  }
}

If extensions["io.modelcontextprotocol/tasks"] is present, you may answer with a task. If it is absent, answer normally. Per the Claude Code docs, a request that cannot become a task omits the extension, so the same server behaves correctly from a subagent or a one-shot run without special casing.

Task fields Claude Code enforces, from the docs:

Two more practical notes from the docs. On an HTTP or claude.ai connector server, the task answer has to start inside the per-request timer, so accept the job and answer first, then do the work. And if you want Claude to wait for the result instead of carrying on, set CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS to 0 in the env block of settings.json; then the normal tool-call time limits apply to the whole task.

If you only consume MCP servers, the Monday action is smaller: update the CLI past v2.1.304, run /tasks to see running MCP tasks, and know that your desktop or VS Code sessions will still block. Our MCP clients comparison tracks which clients document which features, and how to build MCP servers covers the server basics this builds on.

What people are actually saying#

Honest answer: not much yet. The announcement is two days old and we did not find a large Hacker News or Reddit thread dedicated to it when we searched. What exists is builder reaction in the form of code: Upstash shipped @upstash/mcp-toolkit/tasks within a day, and a recent r/LocalLLaMA project showcase lists an MCP-server framework advertising "tasks for long-running tools, elicitation and MCP Apps". That reads as the ecosystem treating tasks as table stakes, not as proof of adoption.

The counter-case is the one in the docs themselves. The coverage gaps are real: no VS Code, no desktop app, no subagents, no one-shot claude -p, and it depends on a server-side feature flag, so a task-capable server will often get plain calls. The Upstash post also notes Anthropic says tasks and elicitations are coming to more Claude products. Until that lands, build for both paths and measure which one your users actually hit.

One more caveat from Upstash's own example: their simple QStashDispatcher runs a task in one invocation, so it cannot wait for an elicitation answer. Only the in-memory default and their workflow dispatcher can. Check that your task runner supports pausing before you promise an approval gate.

Continue Reading#

• MCP Client Features: Sampling, Elicitation and Roots Explained - the client-side features Tasks rides on
• MCP 2026-07-28 Breaking Changes - where Tasks became an extension
• How to Build MCP Servers - server basics before you add tasks
• MCP Clients Comparison 2026 - which clients support which features
• Claude Code Subagents vs Agent Teams vs Workflows - why subagent calls stay plain tool calls

FAQ#

Does Claude Code support MCP Tasks?#

Yes, as a public beta from Claude Code v2.1.304 in terminal CLI sessions, Agent SDK sessions and GitHub Actions runs, per the Claude Code docs. The VS Code extension and desktop app do not have it.

What is the difference between an MCP task and Claude Code backgrounding a slow tool call?#

Backgrounding is client-side: Claude Code moves a main-conversation call still running after two minutes to the background, but the server must keep the request open. A task is server-directed: the server answers immediately with a task id and Claude Code polls tasks/get, so a serverless timeout no longer kills the work.

How do I make Claude Code wait for an MCP task instead of backgrounding it?#

In an interactive session, set CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS to 0 (for example in the env block of settings.json) so Claude waits for every MCP tool call until it ends. The Claude Code MCP docs list the second variable that does the same.

Do I need to change my MCP server to use tasks?#

Only if it has slow tools. The server must be on protocol revision 2026-07-28, check that the client declared the io.modelcontextprotocol/tasks extension, and only then return a task. Never return a task to a client that did not declare support.

Sources#

• Connect Claude Code to tools via MCP - Claude Code Docs - requirements, field rules, environment variables
• MCP Tasks extension overview - protocol flow and server/client steps
• MCP Tasks and Elicitations in Claude Code - Upstash - announcement date, captured request and response, vendor library
• AGNTCon + MCPCon North America - the conference where support was announced
• r/LocalLLaMA project showcase - builder mention