[FEATURE] Make MCP Tool Execution Timeout Configurable in Claude Desktop

[slexs]

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

Environment

• Product: Claude Desktop (Windows 11)
• MCP Server: @steipete/claude-code-mcp v1.10.12 (stdio transport → WSL → Claude Code CLI)
• MCP Transport: stdio

Problem

Claude Desktop has a hardcoded, non-configurable client-side timeout for MCP tool execution. When an MCP tool call exceeds this threshold (~60 seconds based on the MCP TypeScript SDK default of DEFAULT_REQUEST_TIMEOUT_MSEC = 60000), Claude Desktop silently drops the result and displays:

"No result received from client-side tool execution."

The MCP server does return a valid response — Claude Desktop has simply stopped listening by that point. The server-side timeout (30 minutes in claude-code-mcp) is not the bottleneck.

Evidence

Real measurements from MCP server logs (mcp-server-claude-code.log):

Prompt type | Duration | Result -- | -- | -- Direct shell commands (echo, git log, cat) | 9–16s | ✅ Always succeeds Pre-written Python script (sent as stdin) | 16–20s | ✅ Always succeeds Prompt requiring Claude Code to "think" first | ~52s | ⚠️ Borderline Multi-step prompt ("write and run a script that...") | ~81s | ❌ Frequently fails

Official docs gap: Claude Code CLI documents MCP_TIMEOUT explicitly. Claude Desktop documentation has zero mention of any timeout configuration for MCP tool execution. The claude_desktop_config.json schema only documents command, args, and env — no timeout field.

Prior issue closed without resolution

anthropics/claude-code#5221 requested this exact feature and was closed as "not planned" with the external label — acknowledging this is a Claude Desktop issue, not a Claude Code issue. The underlying problem remains unresolved.

Environment

Product: Claude Desktop (Windows 11)
MCP Server: @steipete/claude-code-mcp v1.10.12 (stdio transport → WSL → Claude Code CLI)
MCP Transport: stdio

Problem
Claude Desktop has a hardcoded, non-configurable client-side timeout for MCP tool execution. When an MCP tool call exceeds this threshold (~60 seconds based on the MCP TypeScript SDK default of DEFAULT_REQUEST_TIMEOUT_MSEC = 60000), Claude Desktop silently drops the result and displays:

"No result received from client-side tool execution."

The MCP server does return a valid response — Claude Desktop has simply stopped listening by that point. The server-side timeout (30 minutes in claude-code-mcp) is not the bottleneck.
Evidence
Real measurements from MCP server logs (mcp-server-claude-code.log):
Prompt typeDurationResultDirect shell commands (echo, git log, cat)9–16s✅ Always succeedsPre-written Python script (sent as stdin)16–20s✅ Always succeedsPrompt requiring Claude Code to "think" first~52s⚠️ BorderlineMulti-step prompt ("write and run a script that...")~81s❌ Frequently fails
The pattern is clear: tool calls under ~30s always work, 30–60s is unreliable, and 60s+ consistently produces "No result received."
Not configurable (verified)
I have tested every documented and community-suggested approach. None work for Claude Desktop:
ApproachWorks for Claude Code CLI?Works for Claude Desktop?MCP_TIMEOUT env var✅ Yes (startup timeout)❌ NoMCP_TOOL_TIMEOUT env var✅ Yes❌ No"timeout": 300000 in claude_desktop_config.jsonN/A❌ No effect (not in official schema)"initTimeout" in configN/A❌ Not documentedMCP progress notificationsResets timeout in Python SDK❌ Unknown if Claude Desktop honors these
Official docs gap: Claude Code CLI documents MCP_TIMEOUT explicitly. Claude Desktop documentation has zero mention of any timeout configuration for MCP tool execution. The claude_desktop_config.json schema only documents command, args, and env — no timeout field.
Prior issue closed without resolution
anthropics/claude-code#5221 requested this exact feature and was closed as "not planned" with the external label — acknowledging this is a Claude Desktop issue, not a Claude Code issue. The underlying problem remains unresolved.

Proposed Solution

Proposed solution
Per-server timeout in claude_desktop_config.json
json{
"mcpServers": {
"claude-code": {
"command": "wsl",
"args": ["bash", "-lc", "/home/user/.npm-global/bin/claude-code-mcp"],
"timeout": 300000
}
}
}
This is already the pattern used by other MCP clients (Cline, Continue) and aligns with the MCP Timeout Coordination proposal (SEP-1539).
Additionally:

Honor MCP_TOOL_TIMEOUT as an environment variable for parity with Claude Code CLI
Reset timeout on MCP progress notifications (as TypeScript SDK PR #849 enabled)

Impact
This affects anyone using MCP servers for operations exceeding ~60 seconds:

Agentic coding tools (claude-code-mcp, DesktopCommander)
Database queries on large datasets
Browser automation (Playwright, Puppeteer MCP servers)
Multi-step API integrations

The current workaround — restructuring all prompts to complete under 60s — is fragile and fundamentally limits what MCP tools can achieve in Claude Desktop.
Related

anthropics/claude-code#5221 — Same request, closed "not planned" / "external"
anthropics/claude-code#424 — Original MCP timeout request (fixed for CLI only)
modelcontextprotocol/modelcontextprotocol#1539 — SEP-1539: Timeout Coordination spec proposal
modelcontextprotocol/typescript-sdk#245 — 60s hard timeout in TS SDK (17+ reactions)
modelcontextprotocol/typescript-sdk#849 — Fix: reset timeout on progress notifications

Alternative Solutions

No response

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

No response

Additional Context

No response

[github-actions]

Found 3 possible duplicate issues:

1. [Feature Request] Make MCP tool timeouts configurable in Claude Desktop #5221
2. [BUG] MCP tool responses lost for long-running HTTP tools (works in Cursor, fails in Claude Code) #18684
3. [BUG] MCP Timeout needs to be configurable #424

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[developer239]

Good job! I am surprised more people and way earlier didn't run into the same issue.

+1

[github-actions]

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

[github-actions]

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.