My MCP Timeout Was Being Ignored, and Every Call Died at Exactly 60 Seconds — Reclaiming Per-Server request_timeout_ms

Placing request_timeout_ms correctly per server

Here is the correct placement after the fix. In .mcp.json, you write request_timeout_ms in milliseconds inside each server's definition. The points are that the unit is milliseconds, and that you deliberately give a value longer than the global default.

{
  "mcpServers": {
    "report-builder": {
      "command": "node",
      "args": ["./mcp/report-builder.js"],
      "request_timeout_ms": 180000
    },
    "quick-lookup": {
      "command": "node",
      "args": ["./mcp/quick-lookup.js"],
      "request_timeout_ms": 20000
    }
  }
}

For a heavy tool like report-builder that aggregates AdMob daily revenue and generates a report as a personal developer, I give 180 seconds; for a light lookup like quick-lookup, I narrow it to 20. The key is not to make everything uniformly long. Giving a long ceiling to a light tool means that if it hangs, the wasted wait stretches out and eats the time left for later steps.

Keep the precedence in mind, too. The per-server request_timeout_ms wins first; a server without it falls to the global MCP_TOOL_TIMEOUT, and if that is unset, to the built-in default. The recent bug is, roughly, that this top-priority layer was not read and fell one step down.

If you only want to raise the floor globally, give it on the execution side:

# Set the tool-execution default to 120s. A per-server request_timeout_ms still wins.
export MCP_TOOL_TIMEOUT=120000
# Server startup wait is a separate track. Widen it for servers that start slowly.
export MCP_TIMEOUT=30000

Tool-execution wait and server-startup wait are different things. Confusing when to touch MCP_TIMEOUT for a slow-starting server with when to extend request_timeout_ms for a heavy tool means the value you thought you fixed takes effect in the wrong layer. I got this backwards once, widened the startup timeout, and spent half a day wondering why the tool cutoff never changed.

Back the timeout value out from the tool's response profile

So how many seconds should it be? There is no single right answer here; backing it out from how the tool tends to respond proved most practical. Here is the rough guide I actually use, organized by the axis of judgment.

More than the numbers themselves, two principles matter. One is to set the ceiling at 1.5–2x the measured "at most this long." Set it exactly, and you get an unstable gate that passes normally but fails only on high-load days. The other is that no matter how heavy a tool is, never allocate more than a third of the whole run's budget to a single call, because you stop being able to leave time for the remaining steps. Miss these two, and operations get rough even when you thought you set the values carefully.

After the fix, verify the cutoff yourself

Even once the update fixes the bug, it is worth separately confirming that your own setting takes effect as intended. Whether the value in the config file and the time actually cut off have drifted apart. I keep a light checker that pulls this from each run's log and watches for values pinned to the default.

import json
import statistics
from pathlib import Path
 
# Read each server's request_timeout_ms from .mcp.json (convert to seconds)
def configured_limits(config_path: str) -> dict[str, float]:
    cfg = json.loads(Path(config_path).read_text(encoding="utf-8"))
    limits = {}
    for name, server in cfg.get("mcpServers", {}).items():
        ms = server.get("request_timeout_ms")
        if ms:
            limits[name] = ms / 1000.0
    return limits
 
# Decide whether cutoffs cluster at the default 60s rather than the configured value
def detect_default_cap(timeouts_sec: list[float], configured_sec: float,
                       default_sec: float = 60.0, tol: float = 1.5) -> str:
    if not timeouts_sec:
        return "no-data"
    median = statistics.median(timeouts_sec)
    near_default = abs(median - default_sec) <= tol
    near_configured = abs(median - configured_sec) <= tol
    if near_default and not near_configured and abs(configured_sec - default_sec) > tol:
        # Config is not 60s, yet the measurements pin to 60s = suspect fallback to default
        return "SUSPECT: cutoffs cluster at default, configured value not taking effect"
    return "ok"
 
# Usage: pass the list of elapsed seconds cut off on the same step
limits = configured_limits(".mcp.json")
print(detect_default_cap([59.8, 60.1, 59.9], configured_sec=limits.get("report-builder", 60.0)))

What it does is simple: it checks whether the median cutoff time sits near the configured value or leans toward the default 60 seconds. Because a run can hit 60 seconds by load alone, I never judge on a single value. I raise suspicion only when the median across several runs pins to the default and sits far from the configured value. Wire this one line into the tail of a scheduled run, and even if the same bug returns in a different form, it will not slip by in silence.

Fitting it into unattended nightly operation

When you delegate several jobs to run at night as a personal developer, a timeout becomes a tool for failing fast. In an unattended run, cutting short and moving on beats waiting forever, because the damage you see in the morning is smaller that way.

Through that lens, I set each per-server request_timeout_ms by backing it out from the whole run's budget. There is a total budget, inside it a per-step cutoff, and inside that the ceiling on a single tool call. Keeping this nesting — shorter as you go inward — is the foundation that prevents silent cutoff incidents. When a per-server value silently falls back to the default, as it did here, the innermost layer of that nesting drops out and gets swallowed by the larger outer ceiling. That is exactly why I want the small habit of confirming a value works, not just that it was written, permanently built into operations.

Configuration looks like a write-once affair, yet in practice it quietly betrays you like this. I am still feeling my way through much of it, but the habit of keeping the cutoff visible has become a quiet insurance against tasting the same surprise twice. Thank you for reading.