What happened?
Claude Code documents public-beta server-run MCP Tasks and structured user input, with version, protocol and session restrictions.
Why does it matter?
The features support longer workflows without treating missing input or an interrupted connection as permission to guess.
What happened?
Anthropic’s documentation describes MCP Tasks as a public beta available in Claude Code v2.1.304 and later. A supporting server can accept a long-running job and return a task handle, allowing Claude to continue while checking for the result. A remote server’s task can survive the client exiting and be followed again when the same session resumes.
Elicitation adds structured requests for input. A task can pause to ask the user a question rather than invent missing information. Task elicitation is served in interactive terminal sessions; a non-interactive session asks the server to cancel a task that requests input.
Source: Anthropic ↗
Availability is narrower than the headline
The docs identify eligible terminal, Agent SDK and GitHub Actions sessions, subject to protocol support and feature flags. They exclude the VS Code extension, desktop app, subagent calls and ordinary one-shot print runs. They also distinguish server-run tasks from ordinary backgrounded tool calls, which do not survive exiting the session.
Source: Anthropic ↗
Why does it matter?
Our analysis: the useful shift is separating the life of a job from the life of a single open request. That can make lengthy reports, builds and exports easier to manage—but only if the server actually preserves the work and its result.
Human input is equally important. A workflow that can stop for a missing detail or approval is easier to govern than one that must either fail or guess. The approval still needs to explain the intended action clearly; showing a dialog does not automatically make an operation safe.
For developers, compatibility comes first. Check the client surface, server support and session mode before redesigning a tool around tasks. Cancellation, restart behavior and duplicate execution also deserve explicit tests. A durable task identifier is a coordination mechanism, not a guarantee that the underlying job completed correctly.
