Claude Code Adds MCP Tasks for Long-Running Agent Tools, but Support Remains in Public Beta

Claude Code can hand compatible tools longer jobs, then collect their results. This is a limited beta, not universal support for unattended agents.

Claude Code now supports MCP Tasks for long-running tool work. Anthropic’s documentation identifies the feature as a public beta requiring version 2.1.304 or later.

The rollout was discussed at AGNTCon + MCPCon on October 22 and announced through ClaudeDevs on October 23, according to Upstash’s account. Its October 23 article and DevelopersIO’s October 24 technical coverage describe the same change. These are announcement and coverage dates, not evidence of a new launch on October 25.

A task handle replaces a long wait for one response

The MCP Tasks extension lets a server accept work and return a task identifier instead of the finished output. The client checks progress with tasks/get; completion brings the original result. Both sides must support the extension.

A task can report that it is working, needs input, has completed, failed or been cancelled. When input is required, responses travel through tasks/update. This gives a slow operation an explicit lifecycle instead of treating silence as its only visible state.

The underlying standard is older than this Claude Code rollout. MCP’s July 28, 2026 specification release moved Tasks into an official extension. The news is client adoption, not the invention of long-running work.

Where the beta works, and where it does not

Updating the executable alone therefore does not establish availability. Builders should check the capabilities their actual session advertises before designing around the feature.

Closing the terminal is not the same as cancelling the work

Remote-server tasks can outlive Claude Code; resuming the originating session can restore tracking. Local stdio processes stop on exit, so their work is not automatically durable. Non-interactive tasks requesting human input are sent a cancellation request.

The protocol makes cancellation cooperative: requesting a stop does not guarantee the server stops. For a hypothetical deployment, the important evidence would be whether the deployment actually ceased, not whether the client displayed a cancelled state.

That difference deserves attention before teams put consequential actions behind long-running tools. A task identifier is useful for following work, but it is not a substitute for a server-side record of what changed.

Elicitations add questions, not a blanket safety guarantee

Elicitations let a tool request missing information or confirmation. In a hypothetical release workflow, the tool could prepare an artifact and then ask whether to deploy it. That pause is valuable only if the question is understandable and the server enforces the answer.

Anthropic’s v2.1.310 release notes also record a narrower improvement: when a non-interactive MCP call times out with an unanswered elicitation, its error now tells Claude that no answer arrived and not to repeat the call.

That is a change to failure handling, not proof that every integration prevents duplicate actions. It also should not be confused with that release’s separate expansion of the Monitor tool to additional provider environments.

The design concern connects naturally with our analysis of what persistent agent permissions actually authorize. Approval should identify the intended action and its consequences, rather than become a general permission to finish whatever the agent started.

What this changes for agent infrastructure

AgentsCalling’s analysis: Tasks provide a clearer handoff between an agent deciding what to do and a service executing the job. They do not remove the operational work around credentials, retries, recovery or cost.

This complements, rather than replaces, the infrastructure question in our coverage of Google’s compute layer for long-running agents. Keeping an execution environment available and tracking a tool’s job are different layers of the same broader problem.

Nor does every slow operation need an autonomous agent. As our agents-versus-workflows guide explains, a predictable process can keep its fixed steps while using a model only where interpretation is useful. A report export might need dependable job tracking without giving a model authority over the underlying business process.

The useful next test is recovery, not just a successful demo

A practical evaluation would use a disposable server and a harmless report-generation job. Start the job, disconnect the client, resume the original session and check that the same result returns without creating another job.

Then request cancellation during execution and compare the client’s message with the server’s final activity record. Repeat with a mid-task approval request, including a declined answer and an unattended run. Record job identifiers, duplicate work, approval decisions, recovery time and total cost.

These are proposed tests, not results AgentsCalling has measured. The reviewed material establishes documented functionality and limitations, but not independently demonstrated production reliability or productivity gains. The beta is a meaningful integration step; whether it makes a workflow dependable still needs evidence from that workflow.

Sources & methodology

This story compares Anthropic’s documentation and release notes with the MCP extension documentation, the specification announcement, Upstash and DevelopersIO. The latter is third-party technical coverage, not an independent product audit; Upstash also markets related infrastructure. Documentation was accessible. Upstash’s indexed article text was available, but direct retrieval failed; the original X thread returned an access error. No paywalled text or hands-on test results are claimed.