Claude Adds MCP Tasks and Elicitations: CLI Availability and Limits

Anthropic announced support for MCP Tasks and Elicitations on October 23. Tasks let a plugin run a longer job and return its result later. Elicitations let it ask the user for information partway through. The rollout announcement says both are available in the Claude Code CLI, with more Claude products coming later.

That combination addresses a familiar integration problem. A useful operation may take several minutes and still need one decision from the person who started it. Treating every tool call as an immediate question-and-answer exchange makes that workflow awkward to build and harder to recover when something interrupts it.

What an MCP Task changes

The MCP Tasks specification overview describes a server returning a durable task identifier instead of holding the original request open. The client can check progress and retrieve the result. States distinguish work in progress, a request for input, completion, failure and cancellation.

Both sides must support the extension. The server creates the task before returning its handle, and the client uses that identifier for later status checks. Cancellation is cooperative: asking to cancel does not guarantee that the server has stopped the underlying operation.

For someone building a deployment or research plugin, I would make the task record a first-class part of the design. Store the requested operation, its owner and the external job identifier together. Before retrying after a connection failure, check whether the existing job already finished. Otherwise, a helpful retry can create duplicate work or duplicate charges.

What works in Claude Code today

Anthropic's MCP documentation labels Tasks a public beta requiring Claude Code 2.1.304 or later. Its detailed compatibility rules include eligible terminal, Agent SDK and GitHub Actions sessions, but exclude the desktop app and VS Code extension. A compatible server and protocol connection are required; ordinary one-shot print runs and calls from subagents do not qualify.

Remote-server tasks can continue after the CLI exits. Resume the same session to follow them again. A local stdio server normally stops with the client, so its work should not be assumed to survive. The /tasks view exposes running jobs and a stop action; pressing Escape alone does not stop a background task.

There is another important automation boundary: a non-interactive task that requests user input is asked to cancel. An approval workflow therefore needs an interactive path, not just a successful test of background execution.

Asking a person is part of the workflow

The MCP client guide distinguishes form-based elicitation from URL-based flows. A form collects structured answers. A URL can take the user to a separate sign-in or authorization flow without routing those credentials through the client.

I would design those prompts around a concrete decision: which environment to deploy to, which report period to use, or whether to proceed with a specific refund. Show enough context to make the answer meaningful, and treat a declined request as a real outcome rather than repeatedly asking until the user agrees.

The release is especially useful for plugin authors whose work already has a job lifecycle. Start with one operation, then test disconnects, duplicate responses, cancellation and missing input. A successful happy-path demo is only the beginning; predictable recovery is what makes a long-running integration dependable.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help AI founders turn technical launches and product updates into clear stories that developers and founders read and share.

Book a 30-minute call.