Claude MCP Tool Call Timeout: Exact Limits and How to Raise Them

Claude MCP Tool Call Timeout: Exact Limits and How to Raise Them

When an MCP tool call hangs, the error you see usually names whichever layer gave up first — and that layer is often not the one you think. This article separates the three timeout layers in a Claude MCP setup, gives the one exact number that is publicly verifiable (the MCP TypeScript SDK's 60-second default request timeout), and shows how to raise it, measure the layers that Anthropic does not document, and tell a slow tool apart from a slow model.

TL;DR

• The MCP TypeScript SDK (@modelcontextprotocol/sdk) version 1.32.1 defaults every request to 60,000 ms (60 seconds): DEFAULT_REQUEST_TIMEOUT_MSEC = 60000 in src/shared/protocol.ts line 106, applied at line 1248 as options?.timeout ?? DEFAULT_REQUEST_TIMEOUT_MSEC (verified against the 1.32.1 tag, 2026-10-19).

• You can override it per request with RequestOptions.timeout, keep a long-running request alive with resetTimeoutOnProgress, and cap the total wall time with maxTotalTimeout (protocol.ts lines 136 and 143).

• Anthropic does not publish a specific MCP tool-call timeout for Claude Desktop or Claude Code. The only honest answer for those clients is: measure it on your machine with the procedure below. Do not plan a workflow around a number you read in a blog post (including this one).

The three timeout layers

An MCP tool call crosses three layers, and each has its own clock:

1. Transport layer — the stdio pipe or the HTTP/SSE connection between the client and the MCP server. A dead child process, a proxy idle timeout, or a VPN that drops long-lived connections shows up here.

2. MCP request layer — the client's own per-request timer. In the TypeScript SDK this is the 60-second default above; it wraps the whole request/response exchange, including time the server spends working.

3. Tool and model layer — the tool implementation itself (a slow database query, a paginated API crawl) and, separately, the model's inference time before it even decides to call the tool.

A timeout message almost always tells you which layer fired. RequestTimeout / McpError with code RequestTimeout is the MCP request layer. ECONNRESET, socket hang up, or EPIPE is the transport layer. A call that returns after 40 seconds with data is neither — it is a slow tool.

The exact number: 60 seconds in the TypeScript SDK

The MCP TypeScript SDK is the reference client most integrations embed, so its default is the only MCP timeout you can cite with a line number. In tag 1.32.1:

// src/shared/protocol.ts:106
export const DEFAULT_REQUEST_TIMEOUT_MSEC = 60000;

and the call site:

// src/shared/protocol.ts:1248
const timeout = options?.timeout ?? DEFAULT_REQUEST_TIMEOUT_MSEC;

That is a per-request default, not a per-tool or per-session one: every request() that does not pass timeout gets 60 seconds. Verify it yourself against the tag rather than trusting this article:

curl -s https://raw.githubusercontent.com/modelcontextprotocol/typescript-sdk/1.32.1/src/shared/protocol.ts \
  | grep -n "DEFAULT_REQUEST_TIMEOUT_MSEC"

The Python SDK has its own default; read the version you actually installed instead of assuming it matches the TypeScript one.

How to raise the timeout

Per request, in the client

Pass timeout in the request options. The value is in milliseconds:

const result = await client.callTool(
  { name: 'slow_report', arguments: { month: '2026-09' } },
  undefined,
  { timeout: 180_000 }, // 3 minutes for this call only
);

Keep the override local to the call that needs it. Raising the default globally hides genuinely stuck tools behind a longer wait and makes the failure mode worse, not better.

Long jobs: progress notifications instead of one huge timeout

A tool that legitimately runs for minutes should emit progress notifications, and the client should reset its timer on each one. In the SDK that is resetTimeoutOnProgress: true (line 136), paired with maxTotalTimeout (line 143) as the hard ceiling:

const result = await client.callTool(
  { name: 'crawl_site', arguments: { url: 'https://example.com' } },
  undefined,
  {
    timeout: 60_000,          // per-progress window
    resetTimeoutOnProgress: true,
    maxTotalTimeout: 600_000, // absolute cap: 10 minutes, then fail
  },
);

On the server side, send progress from inside the tool handler so the client actually receives those notifications. A resetTimeoutOnProgress client talking to a silent server still times out at the per-request value.

HTTP transport: the middlebox is a separate clock

If your MCP server is reached over HTTP/SSE, a reverse proxy or CDN in front of it may have its own idle timeout that is shorter than the SDK's 60 seconds. Raise the client timeout and you will still see ECONNRESET. Check the proxy's idle/read timeout before blaming the SDK.

Measuring what Anthropic does not publish

Anthropic's public documentation does not state a specific MCP tool-call timeout for Claude Desktop or Claude Code. To get a number for your own install, measure the wall time at which a deliberately slow tool is cut off:

1. Register a test server with one tool that sleeps for a configurable duration and logs start / end with Date.now().

2. Ask the client to call it with sleeps of 30 s, 60 s, 90 s, 120 s, and 300 s.

3. Record, for each run, whether the tool finished, whether the client reported a timeout, and the elapsed time at the error.

4. The smallest sleep that reliably fails gives you the effective ceiling for that client version. Record the version next to the number — it can change between releases.

// test server tool: sleeps for N seconds, then returns
server.tool('sleep_probe', { seconds: z.number() }, async ({ seconds }) => {
  console.log('start', Date.now());
  await new Promise((r) => setTimeout(r, seconds * 1000));
  console.log('end', Date.now());
  return { content: [{ type: 'text', text: `slept ${seconds}s` }] };
});

Two cautions about the result. First, a client that retries can make a single long call look like two shorter ones — watch the server log, not just the client's final error. Second, a 60-second cut-off measured on one network is not proof of a 60-second product limit; it may be your proxy.

Diagnostic order

Work from the layer closest to you outward — the same order as the Claude Code connection timeout troubleshooting guide, but applied to tool calls:

1. Run the tool outside the model. Call the underlying command or HTTP endpoint directly. If it is slow there, no timeout setting will fix it.

2. Check the transport. For stdio, confirm the child process is alive and its command works verbatim in a terminal. For HTTP, curl -w '%{time_starttransfer}' the endpoint from the same machine.

3. Check the MCP request timeout. If the failure arrives at almost exactly 60 seconds, you are looking at the SDK default, not the tool.

4. Check for retries. Duplicate tool executions in the server log usually mean the client retried after a timeout, which doubles the billed work.

5. Only then raise the ceiling — per call, with maxTotalTimeout as the absolute cap.

FAQ

Q: What is the default MCP request timeout?

A: In the MCP TypeScript SDK @modelcontextprotocol/sdk v1.32.1, every request defaults to 60,000 ms — DEFAULT_REQUEST_TIMEOUT_MSEC = 60000 at src/shared/protocol.ts:106, applied at line 1248. Pass RequestOptions.timeout to override it per request.

Q: Does Claude Desktop time out MCP tool calls after 60 seconds?

A: Anthropic does not publish a specific MCP tool-call timeout for Claude Desktop. The 60-second figure is the TypeScript SDK's client default, not a documented Claude Desktop limit. Measure your own client version with a sleeping test tool before designing around a number.

Q: How do I keep a long-running MCP tool from timing out?

A: Emit progress notifications from the tool and set resetTimeoutOnProgress: true on the client, with maxTotalTimeout as a hard ceiling. Without progress notifications, the per-request timeout still applies no matter how the client is configured.

Q: Why does my tool call fail at 60 seconds even after I raised the timeout?

A: A proxy, CDN, or corporate middlebox on the HTTP path usually has its own idle timeout. Look for ECONNRESET or socket hang up rather than the SDK's RequestTimeout error, and raise the proxy's read timeout as well.

Setting up the server side in the first place

If you have not registered an MCP server yet, start with Claude Code MCP server setup — it covers claude mcp add, scopes, and the mcpServers block for Claude Desktop. For pointing the client at a gateway instead of an official Anthropic endpoint, see Claude Desktop third-party inference mode.

CodeGateway is a multi-model AI gateway: one API key for Claude, GPT, and Gemini, with usage and limits in one place. If you are setting this up without an official Anthropic key, you can create a key and check pricing and the model catalog first. CodeGateway is an independent gateway and is not affiliated with or endorsed by Anthropic.