claude-code - 💡(How to fix) Fix [FEATURE] Implement SEP-1686 (Tasks) client support to unblock long-running MCP tool calls in Cowork / Desktop [1 participants]

Preflight Checklist

• I have searched existing requests and this feature hasn't been requested yet
• This is a single feature request (not multiple features)

Problem Statement

Claude Code's MCP client enforces a hard 60-second timeout on tool calls (DEFAULT_REQUEST_TIMEOUT_MSEC = 60000 in the TypeScript SDK) and silently ignores user-side timeout configuration in the Desktop / Cowork path. There is also no client-side support for async / background tool calls.

Combined, these three constraints make it structurally impossible to build MCP servers whose operations can legitimately exceed 60s against Cowork. The affected class of operations is broad: publisher API fetches, PDF download and parsing, model inference, bulk data pulls, long-running analyses, and anything with variable upstream latency. From the user's perspective, this surfaces as opaque "tool timed out after 60s" errors with no recovery path other than retry-and-hope.

This is not a server-side performance problem. No amount of server optimization fixes it when the ceiling is on the client. The MCP community's standardized answer to this class of problem — SEP-1686 (Tasks), accepted into the MCP spec in November 2025 — is not implemented in Claude Code's client.

Proposed Solution

Implement SEP-1686 (Tasks) in Claude Code's MCP client:

1. Recognize a server's declaration that a tool returns a taskId rather than a synchronous result.
2. Poll (or subscribe to) task status per the SEP.
3. Surface task progress to the agent loop in a way the agent can reason about (e.g., as a tool result that carries status: running until completion and the final payload when the task finishes).
4. Apply the 60s timeout to the underlying RPC call, not to the task. Tasks are expected to run beyond the RPC timeout — that's the whole point.

This is a strictly additive change to the client. Existing synchronous tools continue to work unchanged; servers opt in per-tool. It does not require changing the default synchronous tool-call timeout and is independent of whether that timeout ever becomes configurable.

Alternative Solutions

1. Make the synchronous tool-call timeout user-configurable — tracked in #22542 and #424. The latest I'm aware of is that #22542 was closed by the inactivity bot with a "not planned" label (auto-closure, not an explicit product decision). Regardless, a configurable timeout is a weaker fix: it just moves the ceiling, doesn't eliminate it, and it hands every user a knob they have to tune per-server. SEP-1686 solves the problem categorically.
2. Progress-notification keepalive — some MCP clients reset the request deadline on progress pings. Reports suggest this is unreliable in the TypeScript SDK path that Claude Code uses (see #3033). Even if it worked, it's a workaround layered on top of a synchronous RPC rather than a first-class async model.
3. Server-side start_* + get_* tool pairs — this is what server authors are doing today as a workaround. It works, but pushes the async pattern into every server's public API with no standard shape, doubling the tool surface and asking every agent to re-implement the same polling loop. SEP-1686 is the standardized version of exactly this workaround; implementing it client-side would let servers retire their ad-hoc polling tools.
4. SEP-1699 (SSE polling) — transport-level resumability. Orthogonal to the timeout problem; doesn't help because the 60s limit is enforced above the transport.

Priority

High - Significant impact on productivity

Feature Category

MCP server integration

Use Case Example

Building an MCP server for literature search and paper acquisition, exercising it from Cowork:

• acquire_paper calls against Nature-family DOIs (publisher-hosted PDFs) reliably time out at 60s. Success depends on whether the publisher CDN happens to return the full PDF inside the 60s window, which is nondeterministic — one retry succeeded, four others timed out in the same session.
• acquire_paper against arXiv abstract URLs (e.g. https://arxiv.org/abs/2604.02511) also timed out at 60s in the same session.
• The failure mode the user sees is MCP server "…" tool "acquire_paper" timed out after 60s with no partial result, no progress indicator, and no way to tell whether the work was nearly complete, deeply stuck, or failed upstream.

A concrete example of how SEP-1686 would change this: acquire_paper returns a taskId in <1s, the agent continues its turn, and a follow-up poll either returns the parsed paper or an actionable error. The 60s ceiling never interacts with the operation's runtime.

This pattern generalizes directly to any MCP server that wraps a publisher API, a model inference endpoint, a long-running analysis, or a bulk data pull — i.e., a large fraction of useful MCP servers.

Additional Context

Environment:

• Product: Cowork mode, Claude desktop app
• MCP client: inherited from Claude Code / Claude Agent SDK (TypeScript)
• Observed timeout: 60,000 ms (default DEFAULT_REQUEST_TIMEOUT_MSEC)
• Timeout configuration attempts via settings had no observable effect on tool-call timeout in Cowork

Related issues (none track SEP-1686 client adoption specifically):

• #22542 — Make MCP Tool Execution Timeout Configurable — closed by inactivity bot, "not planned" label. Adjacent ask (raise the synchronous ceiling) rather than the spec-aligned async fix proposed here.
• #3033 — MCP Server Timeout Configuration Ignored in SSE Connections — overlapping symptom, different root cause.
• #424 — MCP Timeout needs to be configurable — older duplicate of #22542.
• #31427 — Async/background mode for MCP tool calls — closed as duplicate. Predates the SEP-1686 spec merge, so the spec-aligned fix wasn't available when it was filed. This issue is effectively the post-SEP-1686 version of that ask.

References:

• SEP-1686: Tasks — MCP spec page
• SEP-1686 tracking issue (MCP repo)
• FastMCP v2.14.0 — server-side tasks support
• MCP 2025-11-25 changelog