MCP: hardcoded 30s timeout on every request makes long-running tools impossible (same root cause as #617)

[tic-top]

Summary

Every MCP JSON-RPC request shares one hardcoded 30s timeout, including tools/call. There is no flag, config key, or mcp.json field to raise it, so any tool that legitimately takes longer than 30s can never succeed.

crates/jcode-base/src/mcp/client.rs:46 (at 02439b4):

let response = tokio::time::timeout(std::time::Duration::from_secs(30), rx)
    .await
    .context("Request timeout")?

request() is the single path used by initialize (client.rs:301), tools/list (client.rs:103) and tools/call (client.rs:71), so the same 30s covers server startup and long-running tool work alike.

I believe this is also the root cause of #617 — a slow-starting server blows the same budget during initialize.

Reproduction

Minimal MCP server (slow_mcp.py, needs pip install mcp):

import time
from mcp.server.fastmcp import FastMCP
mcp = FastMCP("slowsrv")

@mcp.tool()
def slow_ping(seconds: int = 45) -> str:
    """Sleep then return a token."""
    time.sleep(seconds)
    return "SLOW-TOKEN-OK"

mcp.run()

.jcode/mcp.json:

{"mcpServers": {"slow": {"command": "python", "args": ["/abs/path/slow_mcp.py"], "env": {}}}}

jcode run 'Call slow_ping with seconds=45 exactly once, then report what it returned.'

Expected: the tool returns SLOW-TOKEN-OK after 45s.
Actual (0.68.0): the call fails at exactly 30s with Error: Request timeout, and the model reports the timeout instead of the result. I also tried timeout, timeout_ms, timeout_secs and tool_timeout_ms keys on the server entry in mcp.json — none are read.

Impact

I maintain a benchmark harness that drives Microsoft Word through an MCP server, where a single document edit routinely runs longer than 30s (the first call on a busy pool especially). Under jcode those calls come back as Request timeout and the model retries them; the work still completes, but every run burns turns and tokens on retries, and a slow enough backend can never finish at all. Anything else with real I/O behind it — builds, test suites, deploys, browser automation, remote APIs — has the same ceiling.

Suggestion

Two things would fix it, in rough priority order:

1. Make the timeout configurable, and use a longer default for tools/call than for initialize/tools/list. Comparable clients all expose this: Claude Code has MCP_TIMEOUT / MCP_TOOL_TIMEOUT, VS Code and Cursor take a per-server timeout in mcp.json, goose and kimi-cli both have their own knobs. A per-server field in mcp.json plus a global default in config.toml would match what people already expect.
2. Optionally, reset the deadline on MCP progress notifications — the spec allows implementations to do this so well-behaved long-running tools stay alive.

Happy to test a patch against the real workload if that helps. Environment: jcode 0.68.0 (installed via jcode.sh/install), Linux x86_64.

[tic-top]

Correcting my own "Impact" paragraph above — I overstated it, and I would rather the numbers be right on the record.

I claimed a document edit through my MCP server "routinely runs longer than 30s". I went back and measured instead of asserting, and that is not true. Timing the same MCP server directly (initialize, then repeated execute_office_js), against the same backend pool:

initialize               0.49s
tools/list               0.00s  (3 tools)
execute_office_js #0     2.39s   <-- first call of the session (acquires the resource + opens the document)
execute_office_js #1     0.45s
execute_office_js #2     0.46s
...

Two of those probes racing each other: first call 3.09s and 3.84s. Steady state is 0.2–2s. So my real workload sits roughly an order of magnitude under the 30s cap, not above it — the ceiling is not something a normal Office.js edit runs into.

What I actually observed, and what I should have written:

• In my harness the first tool call of each task failed at exactly 30s (Error: Request timeout), and every subsequent call in the same session came back in 0.2–2s. The tasks still completed, because the model retried and the retry was fast.
• A standalone single-task jcode run doing the same first call finished in 7s wall clock, so I cannot reproduce that 30s failure outside my harness, and I am not attributing it to jcode — cause unidentified, possibly on my side. If I pin it down and it turns out to be a jcode issue I will open a separate, properly evidenced one.

The request in this issue is unaffected, and rests only on the synthetic repro: slow_ping(45) fails at exactly 30s with no way to raise the limit, and no mcp.json field is honored. The general point stands — one hardcoded constant covering initialize, tools/list and tools/call alike means any tool that legitimately blocks (a build, a test suite, a deploy, a queued resource) can never complete — but the honest version of my motivation is "a tool can exceed 30s and then there is no recourse", not "mine routinely does".

Apologies for the noise; thanks for the project.

[1jehuang]

The fixed 30-second MCP timeout is confirmed, but one setting currently covers initialization, discovery, and tool calls. Configuration and progress-deadline semantics need a product decision so slow tools can be supported without masking genuinely stuck servers.

--- — Jcode agent (automated triage), on behalf of @1jehuang

[devinder-getok]

hi @1jehuang , Are we picking this up in upcoming release? Happy to contribute. This is a blocker for one of my ACP requirement

[SK-DEV-AI]

Real-world confirmation that the ceiling is hit by normal tools, not just the synthetic repro. I run jcode with two stdio MCP servers — a web-search server (multi-engine search, CDP-driven fetch/extract, PDF extraction) and a package/code-intelligence server. Under jcode 0.81.6 (latest) via mcp.json stdio entries:

• a depth>=2 web search (results + full-page re-rank fetches) and a CDP fetch/pdf_extract on a heavy page routinely pass 30s, and sometimes 60s on a cold CDP connection;
• those calls fail at exactly 30s with Error: Request timeout; jcode retries, the server is still running, and the model burns turns/tokens on the retry loop — same retry tax the issue describes;
• no timeout, timeout_ms, timeout_secs, or tool_timeout_ms on the mcp.json server entry is honored (same as the reporter found).

For comparison, the same two servers run under opencode with a configurable per-tool MCP timeout raised from the default, and long searches complete there. So the 30s cap is the only thing that makes them unusable in jcode today.

As @1jehuang noted, a real fix needs a product decision on how to distinguish slow-but-healthy tools from a genuinely stuck server — the reset-on-progress-deadline half of the suggestion handles exactly that, and per-server/global knobs match what Claude Code (MCP_TIMEOUT), VS Code/Cursor (mcp.json timeout) and goose already expose. Happy to test a JCODE_MCP_TIMEOUT_SECS env toggle and per-server mcp.json override against this workload if useful for the decision.

[1jehuang]

A per-server timeout_secs landed on master in c0c3c96 (via #1174). Example: {"mcpServers": {"websearch": {"command": "...", "timeout_secs": 120}}}. Default stays 30s when unset.

---

— Jcode agent (automated triage), on behalf of @1jehuang