Claude Code got MCP Tasks and Elicitations. Async tool runs are not the same as a priced catalog

2026-10-24 · Dalton

Claude Code’s MCP docs now describe MCP Tasks (public beta on the CLI) and how a running task can ask the human for input via Elicitations. That is a real protocol/host change: long tool work no longer has to sit on a single blocked tools/call.

It is not the same problem as “which priced tool should this Agent call.” I build Toolswitch—a multilingual catalog of agent tools with a price and success-rate angle—so I care about both layers. This note separates them.

What the docs actually say

I opened Claude Code’s MCP page and changelog on 2026-10-24 (Asia/Shanghai), plus the MCP Tasks extension overview and the elicitation client spec.

Version gate. Claude Code’s MCP docs state that MCP tasks are in public beta in the Claude Code CLI and require Claude Code v2.1.304 or later. On that bar, the same page says Tasks cover terminal CLI sessions, Agent SDK sessions, and GitHub Actions runs. It also says other surfaces—such as the VS Code extension and the desktop app—do not have MCP tasks yet. Do not assume every Claude Code UI got this on the same day.

What an MCP Task is (host view). The docs define an MCP task as a long job (examples they give: a report export or a build) that the MCP server runs itself via the MCP tasks extension. Claude’s tool call returns once the server accepts the job; Claude Code follows status by checking with the server. On a remote server, the job can keep running after you exit; you follow it again by resuming the same session. You can stop a task from /tasks (or ask Claude to), knowing cancel is cooperative—the server may still finish.

That is different from Claude Code’s own “automatic backgrounding” of a long main-conversation tool call after about two minutes. Backgrounded host calls do not survive exiting the session. Tasks are the durable, server-owned handle.

Elicitations. A running task can open an elicitation dialog for user input. Claude Code’s MCP docs also have a section on responding to MCP elicitation requests more generally: servers can request structured input mid-flow; Claude Code shows an interactive dialog and returns your answer. No extra user configuration is required for the dialog path. For protocol detail, the docs point at the MCP elicitation specification.

The elicitation client feature describes two modes: form (structured data through the client, optional schema) and url (out-of-band navigation for sensitive flows that must not pass through the MCP client). The spec is explicit that form mode must not be used for passwords, API keys, access tokens, or payment credentials.

Changelog signal. Claude Code changelog 2.1.310 (dated October 23, 2026) is still polishing elicitation edges: it changed the error for an MCP tool call that times out in a non-interactive session while the server’s elicitation is unanswered, so Claude is told no answer came and not to repeat the call. Useful as a “still shipping” marker; not a reason to invent product claims.

I did not re-test Tasks end-to-end for this draft (paid-call test budget is still 0 unless separately approved). Everything above is from the pages themselves.

Protocol signal: beyond a sync tools/call

The Tasks overview states the problem plainly: not every tool call returns instantly. Tasks let servers return a durable handle instead of blocking, so clients can poll for progress, provide input when needed, and retrieve the final result after reconnecting.

Statuses called out there include working, input_required, completed, failed, and cancelled. Mid-flight interaction uses input_required plus responses via tasks/update—so human approval or extra fields do not require a second ad-hoc channel.

Elicitation is the sibling idea on the client-feature side: the server can ask the user for information during an interaction while the host keeps control of UI and consent.

Taken together, MCP is documenting a path from “call a tool and wait on one connection” toward “start work, poll or resume, pause for humans when needed.” Host support still varies; the Tasks page itself says host support varies by client and that both sides must opt in.

Host capability ≠ catalog selection

If you only read the headline, it is easy to mash two questions into one:

Can this Agent host run a long MCP job without blocking the session, and can it ask me mid-run? That is host + protocol (Tasks, Elicitations, which Claude Code surfaces actually enable them).
Which tool should the Agent call for this task, what does a call cost, and how often does it succeed? That is catalog / marketplace work.

Tasks change how a chosen server runs a long job. They do not tell you whether vendor A’s scrape endpoint or vendor B’s transcript API is the right pick for a given task, whether billing is per call or per success, or whether yesterday’s success rate still holds.

Claude Code’s own docs also draw a practical line: Tasks need protocol revision 2026-07-28 connections and feature-flag conditions among other requirements. A catalog entry that says “supports MCP” is still not the same as “this host will turn this call into a durable Task.”

Toolswitch angle (disclosure)

I am the person running Toolswitch: a multilingual directory of agent tools—3,900+—with a focus on comparing options by task, and (as we keep building) price and success-rate views. We are not claiming that Toolswitch’s HTTP API or MCP endpoint already exposes “async Tasks” as a product feature. Those surfaces are not the subject of this post; until they ship with documented Task support, do not read this as a promise of async catalog calls.

Where Tasks help people like me: when a host can poll and resume, long data jobs stop looking like session failures. Where a catalog still matters: you still need to pick among many overlapping tools, see how they bill, and watch whether they actually work. Complementary layers. Tasks do not replace a priced catalog; a catalog does not replace host support for long jobs.

What I am watching next

Whether more Agent hosts document Tasks (and elicitation) the way Claude Code’s CLI docs now do—without assuming VS Code/desktop catch up on the same day as the CLI.
Server authors returning resultType: "task" only when the client declared the extension (the Claude Code and MCP docs both stress that).
Avoiding a new SEO page for every protocol extension. For Toolswitch, a blog note (after the blog route ships) or a short update on an existing “what is MCP” doc is enough until search demand is measured. Keyword volumes for mcp tasks / claude code mcp tasks are not quantified yet in our Semrush tables.

If you are choosing tools today: upgrade Claude Code past the Tasks gate if you need the CLI beta behavior, read the surface matrix in the MCP docs, and keep price / success-rate selection as a separate checklist.

Data sources (opened 2026-10-24, Asia/Shanghai)

| Source | What it supports | | --- | --- | | Claude Code — Connect via MCP | Public-beta Tasks ≥ v2.1.304; CLI / Agent SDK / GitHub Actions vs VS Code & desktop; task poll/resume; elicitation dialog | | Claude Code changelog | 2.1.310 (2026-10-23) elicitation timeout messaging in non-interactive sessions | | MCP Tasks overview | Durable handle, poll, input_required, host support varies | | MCP Elicitation (latest) | Form vs URL modes; sensitive-data rules | | MCP Elicitation (2026-07-28) | Same client feature on the dated revision Claude Code’s Tasks docs reference |

How we tested

No live Claude Code Task run for this draft (test budget default 0).
Facts limited to pages opened on 2026-10-24 (Asia/Shanghai) via WebFetch/curl.