Claude Code MCP Tasks: A New Paradigm for Long-Running Tasks and Proactive Questioning

Claude Code's support for MCP Tasks and elicitations marks a noteworthy evolution in how AI coding assistants interact with external tools. Simply put, it transforms tool calls from short "one-question-one-answer" requests into tasks that can run for extended periods and proactively request information from users or models mid-execution. Drawing on key points from the official documentation, this article breaks down what conditions a tool call must meet to be upgraded to a Task, which scenarios currently don't support this, and what changes MCP server authors need to make.

From Tool Calls to Tasks: What MCP Tasks Solve

In traditional MCP interactions, tool calls are typically synchronous: the model sends a request, and the server returns a result as quickly as possible. When a tool needs to run for minutes or longer—such as executing a large-scale code search, waiting for an external build to complete, or running a test suite—synchronous calls become awkward: they're prone to timeouts and block the conversation flow for extended periods.

The core idea behind MCP Tasks is to "taskify" these calls: a tool call is registered as a trackable, pollable long-running task rather than a return value that must be delivered immediately. According to the official documentation, this provides more natural lifecycle management for long-running tools and allows clients to more gracefully display progress, handle failures, and retry.

Complementing this, elicitations address another real-world problem: tools often need additional information while running. Previously, such information either had to be stuffed into parameters upfront or left to the tool to guess. Elicitations allow a task to pose questions to the user mid-execution, turning "need your confirmation" into a standard protocol-level action rather than an ad-hoc interaction.

MCP (Model Context Protocol) is an open protocol proposed by Anthropic in late 2024 to standardize how AI models connect with external tools and data sources. It uses a client-server architecture: AI applications (such as Claude Code) act as clients, and external capability providers act as servers, communicating via JSON-RPC messages. The core value of MCP lies in unifying "how models call external tools" from proprietary implementations into an interoperable protocol, so that the same MCP server can be reused by different clients. Understanding this is crucial—Tasks and elicitations are new capability semantics added within this protocol framework, not private extensions of any single client, so their effectiveness depends on both ends of the protocol implementing the same version.

What Conditions Must a Tool Call Meet to Become a Task

The documentation clearly specifies the elements a tool call must have to be upgraded to a Task. This is the section server authors should pay most attention to, as it determines the boundaries of implementation approaches.

From a protocol perspective, taskification requires tools to express task semantics in their declarations and responses, including the task's lifecycle states, how to obtain task progress, and how results are delivered upon completion. In other words, a server can't just "run long"—it must also be able to communicate "what stage I'm currently in."

Client cooperation is equally important. The client needs to understand the task's polling or subscription mechanism and be capable of handling elicitation requests during task execution. This means upgrading only the server side is insufficient for a complete experience—protocol support on both sides is indispensable.

Current Capability Boundaries: Where It Doesn't Work Yet

The documentation doesn't shy away from limitations. MCP Tasks isn't available in all environments, and some scenarios still lack support. For developers, understanding these boundaries in advance saves more time than debugging after the fact.

A pragmatic understanding: this is a capability that's still being rolled out, and client and server support levels aren't aligned. In combinations with incomplete support, tool calls may still fall back to traditional synchronous behavior, and the advantages of taskification won't materialize. Therefore, before actual integration, confirming whether the client version in use supports Tasks and elicitations is a necessary prerequisite.

Capability negotiation is the mechanism in the MCP protocol where client and server exchange their lists of supported features during session initialization. Both parties declare which capabilities they support (such as tools, resources, prompts, and the newly added tasks and elicitation) during the initialize handshake, and subsequent interactions only use features that both parties have declared support for. This explains why the article emphasizes "protocol support on both sides is indispensable": if the client doesn't declare tasks capability in the handshake, the server's taskification implementation won't take effect, and calls will fall back to synchronous mode. When developers troubleshoot "why isn't taskification working," the first step should be to check the actual capability declarations in the initialization handshake, rather than immediately suspecting the implementation logic.

What Server Authors Need to Change

For MCP server authors, the focus of this change isn't rewriting business logic but "wrapping" existing long-running tools into a form that conforms to task semantics.

The adjustments needed are roughly concentrated in three areas: first, expressing task capability in tool declarations so the client knows the call may proceed as a task; second, exposing task status and results in a way that ensures the client can query progress and obtain the final output; third, handling elicitation requests, where the tool needs to construct properly formatted requests when asking questions mid-execution and correctly handle user responses or rejections.

An easily overlooked detail is error handling. Long tasks can fail in more varied ways than synchronous calls: they may fail at the startup stage or be interrupted midway. Mapping these failure paths to task states rather than simply throwing an exception is key to ensuring a consistent client experience.

Idempotency and task IDs are design points that are easily underestimated in taskification efforts. Retrying after a synchronous call failure usually means re-executing, but once a long task is registered as a pollable object, the client may repeatedly query or even repeatedly initiate due to network jitter or timeouts. The server needs to assign a stable and unique task ID to each task and ensure that the "query task status" operation itself is idempotent—multiple queries of the same ID should not produce side effects or change task state. At the same time, the task's final result should be readable multiple times (rather than destroyed after a single read), otherwise a brief failure in the result delivery phase would cause the entire long task's computational output to be lost.

Significance for AI Coding Workflows

Zooming out a bit, the combination of MCP Tasks and elicitations is effectively giving AI coding assistants two new abilities: "patience" and "communication." The former lets the assistant wait for work that genuinely takes time; the latter lets the assistant speak up when information is insufficient rather than stubbornly guessing.

These two points are especially important for code-related tasks. Builds, tests, static analysis, and dependency resolution are inherently long-running operations that may require clarification midway. When these operations can run as tasks and confirm with users at key junctures, AI coding collaboration feels closer to working with a real engineer rather than facing a black box that only gives one-shot replies.

Of course, rolling out capabilities takes time. Before client support, server implementations, and developer habits are all in sync, the actual benefits will vary by tool. But the direction is clear: MCP is evolving from a "function-calling protocol" to a "collaborative task protocol."

Practical Recommendations

If you maintain an MCP server, start by taskifying the tool that takes the longest and has the highest failure rate to verify whether the client chain works smoothly. If you're just a user, pay attention to whether your client has declared support for Tasks before deciding whether to hand long tasks to it. The limitation clauses in the documentation are also worth reading through to avoid wasting effort on unsupported combinations.