[FEATURE] Support the MCP Tasks extension (io.modelcontextprotocol/tasks, spec 2026-07-28) for long-running tool calls

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet in its current form
• [x] This is a single feature request (not multiple features)

Problem Statement

Since MCP spec 2026-07-28, Tasks is an official extension, io.modelcontextprotocol/tasks (SEP-2663). It is the standard way for any MCP server to answer tools/call with a task handle and let the client pick up the result later. Claude Code doesn't support it yet, so every server with slow operations has to work around the client.

This has been asked for before. Each time, a bot closed the issue before any maintainer replied: #18617 and #52137 (8 👍) were auto-closed as stale, and #76571 was auto-closed as a duplicate of #52137. All three describe the experimental 2025-11-25 design (tasks/result, the client task hint), which the extension has since replaced. This issue asks for the current design.

What server authors can do today:

• Hold the call open and send progress keep-alives. This works when Claude Code connects to the server directly. Observed with Claude Code 2.1.299 over --transport http: a single call stayed open for about 10 minutes while progress notifications kept arriving, and was backgrounded after 120 s.
• The same server added as a claude.ai connector doesn't get that far. The relay hangs up at about 240 s, and it doesn't forward progress notifications to Claude Code, so Claude Code idles out on its own at about 311 s with "sent no response or progress". Any operation longer than about 4 minutes has no standard path.
• Hand-rolled start_* / get_* tool pairs. These work, but every server invents its own shape, the tool surface doubles, and the model has to be prompted to poll. Every poll is a model turn and costs tokens.

The affected class of servers is broad: CI and deploy pipelines, data warehouse queries, bulk exports and imports, document processing, model training and inference jobs, crawlers, and any tool that waits on a human decision before it can finish.

Proposed Solution

Implement the client side of the Tasks extension for the 2026-07-28 protocol:

1. Advertise io.modelcontextprotocol/tasks in the client's extensions capability.
2. When tools/call returns a CreateTaskResult, return to the agent loop right away. Poll tasks/get at the server's pollInterval, as background Bash and long MCP calls do today.
3. When the task reaches a terminal state, give the model the final result, including content and structuredContent when the status is failed.
4. Handle input_required through tasks/update, using the elicitation UI Claude Code already has.
5. Cancel through tasks/cancel when the user interrupts or the session ends.
6. Apply the request timeout to each RPC, not to the task.

This is additive: tools that answer synchronously keep working as they do today, and a server opts in per call.

Dependency note: the TypeScript SDK doesn't implement the extension yet (modelcontextprotocol/typescript-sdk#2189, open, P2, "needs decision"). The Rust SDK (rmcp 3.x) ships it, so the protocol side is settled and implementable. If Claude Code is waiting on the SDK, saying so in this issue would help server authors plan.

Alternative Solutions

• Forward progress through the claude.ai connector relay and lift its ~240 s cap. That would make long calls work for connectors too. It's a smaller change, but it isn't the standard path and can't survive a reconnect.
• A configurable tool-call timeout (#22542, #424, both closed). This moves the limit without removing it.
• Client-side run_in_background for MCP tools (suggested in #18617). Useful, but the server can't hand back a durable handle that survives a reconnect or a session resume.

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

An MCP server wraps a CI system. run_pipeline takes anywhere from 2 to 40 minutes.

• Today: the server either holds the call, which works with a direct connection but dies at about 240 s through a connector, or returns a run id and relies on the model to call get_pipeline_status again and again. Each poll costs a turn and tokens, and the model sometimes gives up or polls too fast.
• With Tasks: the server returns a task right away, Claude Code polls tasks/get without spending a model turn, and when the pipeline finishes, the agent gets the result as if the call had simply taken a long time.

The same pattern applies to a warehouse query, a bulk export, or a tool that needs a person to sign off before it can finish.

Additional Context

• Tasks extension spec: https://modelcontextprotocol.io/specification/2026-07-28/changelog
• SEP-2663 implementation tracking: modelcontextprotocol/modelcontextprotocol#2886
• Other clients: VS Code ships a 2025-11-25-era Tasks client but blocks the chat turn until the task ends (microsoft/vscode#308961). Codex has an open request for the 2026-07-28 extension (openai/codex#48617).