Claude Code's Slow Tools Stop Blocking the Conversation: MCP Tasks in Public Beta

The short version: slow tools no longer block the conversation

Until now, an MCP tool call was one request and one answer. Export a ten-minute report or run a full regression build, and the conversation waited ten minutes — or the call timed out. Claude Code's MCP Tasks change that shape: the server can answer with a task number, keep working in the background, and hand the result back when it is done. More important is the second half: mid-task, the job can pause and ask you a question — "confirm deploying this branch to staging?" — and only continue after your answer. This is not another chat enhancement. It is a protocol-level change: slow work, long work, and work that needs a human decision finally have a respectable asynchronous form.

Draw the boundary first. MCP Tasks do not make Claude Code faster, and they do not make the model smarter. They fix the waiting structure: who waits for whom, for how long, what else can happen while waiting, and when a human must step in. Judge it by your own tools, not by a demo: if you have calls that are doomed to time out past two minutes and must be restarted from scratch on failure, this is worth serious evaluation. If you do not, it is an ordinary protocol upgrade, and there is no reason to chase it.

The news: announced October 22, available from v2.1.304

On October 22, 2026, David Soria Parra, a co-creator of MCP at Anthropic, announced Claude Code support for MCP Tasks in his keynote at AGNTCon + MCPCon North America in San Francisco. The next day, Anthropic's ClaudeDevs account confirmed that Tasks and Elicitations (the question mechanism) were both available in the Claude Code CLI. Claude Code's official documentation then wrote the mechanism into its MCP reference: MCP Tasks are in public beta, require Claude Code v2.1.304 or later, and cover terminal CLI sessions, Agent SDK sessions, and GitHub Actions runs.

The documentation is equally explicit about what is not included: the VS Code extension and the desktop app do not have MCP Tasks; calls from subagents do not become tasks; one-shot claude -p runs do not either; and third-party providers that do not fetch feature flags — the docs name Amazon Bedrock — are out as well. The server side has hard requirements too: it must speak protocol revision 2026-07-28, the call must come from the main conversation, and the server must support the Tasks extension. Miss any one of these and the call quietly falls back to an ordinary synchronous tool call. It does not error and does not queue; it just silently becomes the old thing. That quiet fallback deserves attention: if tasks do not appear after launch, check the version, the protocol revision, and the call source before assuming the server is broken.

The protocol itself is not new. The MCP Tasks extension shipped with the July 28, 2026 MCP release, defining how a server answers a slow request with a task handle while the client polls for the result. What Claude Code did in October is the client landing: wiring that protocol capability into real sessions, a task list, and question dialogs. In other words, the October news is not "asynchrony was invented" but "one of the most widely used agent CLIs finally wired asynchrony up." That is where the ecosystem significance lies: server authors now have a client worth adapting to, not just an extension name in a protocol document.

Two kinds of "background" — do not confuse them

The documentation actually contains two easily confused background mechanisms, and you must separate them before writing code. The first is automatic backgrounding: an MCP call in the main conversation that is still running after two minutes moves to a background task, the conversation continues, and the result arrives later. It needs no server change, but it has a hard flaw: the server must keep that request open, so function timeouts and broken connections still kill it; and it does not survive closing Claude Code — close the session and the task is gone.

The second is real MCP Tasks: the server answers tools/call directly with a task object containing resultType of task, a task ID, a working status, creation and update timestamps, a time-to-live, and optional status messages and poll intervals. Claude Code then polls with tasks/get at the poll interval, and when the job ends, the result goes to Claude. A task on a remote server keeps running after you exit, and resuming the same session picks it up again; the footer shows a count such as "1 MCP task," and /tasks lets you view and stop it. The price is that the server must keep its own task state: an in-memory task dies when the process restarts, and in a multi-instance deployment a poll can land on an instance that never saw the task. Production deployments need durable storage and a dispatcher, not just the in-memory code from the examples.

For users, the simplest way to tell them apart is the /tasks label: a task marked "runs on the server; survives exiting this session" is a real server task; without that line, it is probably just automatic backgrounding, and closing the session loses it. Team documentation should use exactly this distinction, or the question "will my task keep running after I shut down?" will never get a straight answer.

Elicitation: putting the human inside a long task

The hard part of a long task is not waiting; it is the moment a human decision is needed. The Elicitation mechanism solves that: when a task reaches a confirmation point, its status becomes input_required and Claude Code shows a small form in the interactive terminal — confirm a deployment branch, confirm a refund amount. Accepting, declining, or pressing Esc are all explicit answers to the server, which then decides whether to continue.

Three rules belong in every operations manual. First, questions are only delivered in interactive terminal sessions; in a non-interactive session, Claude Code asks the server to cancel any task that requests input rather than guessing an answer for you. Second, declining and cancelling are answers too: the server must handle the "user said no" branch, not assume only "yes" exists. Third, the question dialog stays hidden while /tasks is open — close /tasks first to answer. That small trap is easy to mistake for a hang, and it is worth warning a team about the first time they use it.

My judgment: the question mechanism matters more than the task mechanism. Without questions, a long task either stops before every critical step and waits for you to watch it, or goes ahead and performs an irreversible action on its own. With questions, a person can genuinely hand work off without losing control. But the responsibility stays with the server author: every irreversible step must be a question point. The protocol provides the tool; the author decides whether to use it. When reviewing an MCP server, ask "which steps will ask me?" before asking "how fast does it run?"

A checklist for server authors: answer format to cancellation semantics

If you are adding Tasks support to your own MCP server, the documentation's implementation checklist is specific enough to follow line by line. When answering with a task, the tools/call result carries no content array, and resultType must be task; the task ID is required, at most 128 printable ASCII characters with no spaces, or Claude receives a malformed-handle tool error; the status must be one of working, input_required, completed, failed, or cancelled; createdAt, lastUpdatedAt, and ttlMs are required, with ttlMs allowed to be null; pollIntervalMs is optional, clamped by Claude Code between 250 and 30,000 milliseconds, defaulting to 2,000 when absent.

Status reporting has rules too: every tasks/get must return the full task object; on completion, the normal tool result goes in result; on failure, the top-level error object must carry a message, or Claude sees only a status message or a bare "Task failed"; cancellation is the same. Cancellation is cooperative: Claude Code sends tasks/cancel, and the server may stop at a checkpoint or may finish the step in hand — so what "cancel" means in your server, "stop immediately" or "finish this step, then stop," must be written in your documentation, not left for users to guess.

Two production details are easy to underestimate. First, on HTTP or claude.ai connector servers, the task answer must arrive within the single-request timer: accept the job and answer with the task number first, then do the work — never the other way round. Second, the timeout semantics: a background task has no Claude Code time limit by default, but the tool-call time limits (wall-clock limit and idle timeout) apply until the server answers with the task; if you make Claude wait for the result, they apply to the whole task. These details decide whether your server is "stable" or "occasionally flaky" in real sessions, and they are worth testing with three cases before launch: a slow task, a cancellation, and a disconnect-and-reconnect.

What it does not solve: Tasks are not a workflow engine

Be sober about this: MCP Tasks are not a workflow engine, not a queue system, and not a durable task platform. They provide no visual retry-policy orchestration, no guarantee that a task survives a server restart (that is your storage's job), no dependency handling between tasks, and no "run task B automatically when task A finishes" semantics. Teams that need those still have to build an orchestration layer on top of MCP Tasks, or use an existing workflow system and treat MCP Tasks purely as the handshake protocol between Claude Code and a slow tool.

Nor does it change the model's capability boundary: however long a task runs, Claude can still misunderstand the result when it arrives, and you still have to review it. Moving a long task out of the conversation removes waiting; it does not remove judgment. A team expecting Tasks to let an agent independently run a full day's work on its own is wishing on a protocol, not using one.

There is also a plain adoption lag: servers must upgrade to the 2026-07-28 protocol, implement task methods, and handle questions and cancellation; clients must upgrade to v2.1.304; teams must update their manuals. For the next few months you will meet servers that support tasks and servers that do not, sessions that support tasks and sessions that do not. In that mixed period, the pragmatic move is to write new servers for Tasks, leave old servers alone, and label each tool in your documentation as "supports tasks" or not — rather than assuming a full switch.

Three scenarios worth trying first

The first is regression testing. After changing core logic, the full suite takes minutes or longer; the old habit is to open a terminal window and watch it, or to split the suite into small batches — which fragments the very coverage that catches regressions, so the longest, most revealing suite gets run least. Package the full regression run as an MCP task instead: the server accepts the job and returns a number, Claude helps you with the next change, and when the tests finish, the failure list comes back. Failures must include full output and reproduction commands, not just "3 failures" — otherwise you have to rerun everything to locate them, and the task has lost its point. Better still, include log excerpts and test file paths in the task result so Claude can locate the failure without asking you.

The second is data-heavy long work: report exports, data syncs, bulk document generation. These jobs matter for their results and are boring in process — ideal for background tasks. But watch one detail: exports and syncs often write to external systems, so a task cancelled midway may have written half its output. The server author must decide the post-cancellation state in advance: a recoverable intermediate state, or a rollback to the start? That answer belongs in the task documentation, not discovered in production. My recommendation: for any task involving external writes, return a queryable external reference number at the start, so after a cancellation or failure the user can at least check in the external system what was actually written.

The third is publish-type work that needs a human confirmation: deploying to staging, publishing a post, running a bulk operation. Here the value is not background execution but the question point: the machine does the preparation, stops at "confirm execution," and hands the decision back to you. The manual must set the granularity of questions: too coarse, and one confirmation hides ten irreversible actions, which is no confirmation at all; too fine, and the user clicks every two minutes, which is no backgrounding at all. A sensible unit is "one confirmation per externally visible side effect" — one deployment, one publication, one batch write — not a whole pipeline inside one confirmation box.

Surviving the mixed period: old and new tools side by side

For the next few months, teams will live in a mixed period: some servers support tasks, others still make synchronous calls; some sessions run in a terminal, others in the VS Code extension; some colleagues are on v2.1.304, others are not. The worst mistake is writing documentation that assumes everyone has upgraded and leaving the rest to trip over it. The pragmatic move is to tag every MCP tool in the team's internal tool list: supports tasks, synchronous only, terminal only, requires protocol version X. Put the tags in the list, not in someone's head.

Also establish a fallback rule: when the task mechanism is unavailable, the call should fall back to synchronous mode and say so plainly — "this run is synchronous; timeout risk remains" — rather than falling back silently and letting the user believe a task is running in the background. Claude Code's design is a silent fallback, which is good for compatibility and bad for users, because silence leaves room for misunderstanding. Your own wrapper can add one line at call start: "running as a task" or "running synchronously." One sentence prevents a whole class of "I thought it was running in the background" mistakes. Remove the hint later, once the ecosystem has caught up.

One line to close: the value of MCP Tasks is not speed but "can wait, can ask, can stop." Slow tools can now leave the conversation gracefully, come back gracefully, and stop at the critical moment to ask you a question. That is a piece of the puzzle that agent work needs as it moves from "one question, one answer" to "long-term collaboration" — small, but the puzzle is incomplete without it.