MCP Tasks in Claude Code: Slow Tools Finally Work

Long-running MCP tools can now outlive a single request in Claude Code. The Tasks extension, shipped in the MCP 2026-07-28 release, lets a server return a task id for expensive work and then accept polls, extra input and cancellation while the job runs (Upstash, Tasks spec). For anyone building an MCP server, that turns exports, crawls, renders and reports from fragile demos into tools people can rely on.

TL;DR

• Tasks let a slow MCP tool return a task id instead of holding one request open.
• The client polls with tasks/get, sends input with tasks/update and cancels with tasks/cancel.
• The public beta is in the Claude Code CLI from v2.1.304, not yet in subagents or the VS Code extension.
• Servers should set a poll interval and a time to live, use unguessable ids and check auth on every request.
• Elicitation covers the missing detail that used to force a tool to fail or guess.

Disclosure: ZeroRaised publishes this analysis and is a launch site for bootstrapped products. Facts come from the linked sources as checked on 27 Oct 2026; ZeroRaised has no commercial relationship with the companies named.

An MCP Task is an addressable unit of long-running server work that a client can poll, update or cancel by id instead of waiting inside one tool call.

Why did slow MCP tools break before?#

Claude Code backgrounds MCP calls that run longer than 2 minutes (Upstash). Before Tasks, the tool call itself was the unit of work. A twenty minute crawl could not report progress or survive a restart.

Builders worked around it with many small calls, a homemade job id plus a polling tool, or a retry. Each workaround leaks implementation detail into the tool surface and makes the agent look less competent than the underlying service.

How does the Tasks extension work?#

A slow tool returns a task id. The client polls with tasks/get, can send input with tasks/update and can cancel with tasks/cancel (Tasks spec).

Task status is one of five values: working, input_required, completed, cancelled or failed. Servers suggest a poll interval with pollIntervalMs and a time to live with ttlMs. Clients should persist task ids so polling can resume after a crash. Task ids must be unguessable, and servers must check authorisation on every task request. There is no tasks/list, so one caller cannot see another caller's tasks (Tasks spec).

The specification describes tasks as useful "for representing expensive computations and batch processing requests", and says they "map naturally onto external job APIs" (Tasks spec). That is the design brief. If you run a queue and a worker, you are halfway there; the MCP server guide covers the rest.

What can a server ask the user now?#

Elicitation is the other half of the change. The server asks the user for information through a form; the MCP example uses a form that asks for a name (Upstash, Tasks spec).

For a long job, that is the difference between a guess and a correct run. A report tool can ask for a date range; an export tool can ask where the file should go. The task can sit in input_required while the question is answered, then continue.

The most common failure in agent tools is a missing parameter that the server silently fills with a default. Elicitation lets the tool stop and ask.

What is in the beta, and what is missing?#

The public beta is in the Claude Code CLI from v2.1.304, in the interactive terminal, the Agent SDK and GitHub Actions (Upstash, Claude Code MCP docs). It is not yet in subagents, one-shot claude -p, the VS Code extension or the desktop app (Upstash, Claude Code MCP docs).

That list matters for packaging. If your users mostly run agents inside the desktop app, a task-only tool will look broken. Ship a synchronous path and a task path; the same handler can serve both if the task is a queued call to the same function.

What should MCP server makers build now?#

The obvious candidates are the jobs that already have a queue: exports, site crawls, screenshots and renders, PDF generation, audits, multi-step reports and anything that calls an external job API.

1. Pick the jobs that exceed 2 minutes and make those tasks. Leave fast reads as ordinary tools.
2. Return a task id immediately, then do the work in a worker with a durable record.
3. Suggest a sensible pollIntervalMs, and set a ttlMs that matches how long you keep results.
4. Use unguessable ids and check auth on every task request, not only at creation.
5. Handle cancellation by stopping the worker, and make create idempotent so a retry does not charge twice.
6. Persist results with an expiry so a completed task can still be fetched after a client restart.

Upstash ships helpers in @upstash/mcp-toolkit/tasks (Upstash). Keep your tools/list output in a deterministic order too: the 2026-07-28 changelog asks for it to help client caching and prompt cache hit rates (MCP changelog).

How should you price a task-based tool?#

Opinion: tasks make metering easier and more honest. A long job has a visible unit, so you can charge per run, per page crawled or per minute of compute. Buyers of an export tool understand "one credit per report" more easily than "one credit per thousand tokens".

That does not mean abandoning usage limits. A task started by an agent needs a budget check before the worker starts, not after. The guide to monetising an MCP server covers packaging, and the LLM cost guide covers the underlying spend.

What this means for bootstrapped founders#

1. Audit your MCP tools for anything that can take longer than 2 minutes.
2. Queue those jobs and return a task id, with a synchronous fallback for older clients.
3. Design the task record first: owner, status, input, result, expiry, cost.
4. Check auth and budget on every task request, not just creation.
5. Support cancellation, make create idempotent and add elicitation for the parameters that most often go missing.
6. Test in the CLI from v2.1.304 before you advertise support.

Infrastructure features become product features: a tool that runs for an hour, asks a question and survives a restart feels like a service. The AI agent vs AI workflow guide tests whether the job needs an agent at all.

Where ZeroRaised fits#

ZeroRaised is a launch and discovery site for products built without institutional venture capital or accelerator equity. If you ship an MCP server or an AI tool, submit your product. The newsletter carries new analysis like this, and the pricing page explains the listing options. A launch page is a stable place to state what your tool supports and costs.

Sources#

• Upstash: MCP Tasks in Claude Code
• Claude Code MCP documentation
• MCP Tasks extension specification
• MCP 2026-07-28 changelog