Added default mcp tool call timeout from env

[haydenrear]

Add a default fallback from an env for tool call timeout from the client side.

Motivation and Context

Tool calls timeout at 60 seconds. For any tool call that is an agent, for instance, it's too low.

How Has This Been Tested?

Unit tests, and I tested by running it in claude-agent-sdk (replacing the env).

Breaking Changes

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• [ x] New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• [ x] I have read the MCP Documentation
• [x ] My code follows the repository's style guidelines
• [ x] New and existing tests pass locally
• [ x] I have added appropriate error handling
• [ x] I have added or updated documentation as needed

Additional context

[changeset-bot]

🦋 Changeset detected

Latest commit: 89f2d79

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@modelcontextprotocol/core	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@1854

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@1854

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@1854

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@1854

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@1854

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@1854

commit: 89f2d79

[travisbreaks]

The intent is reasonable (60s is too short for many agent operations), but the implementation has several issues:

1. No tests

This modifies a core constant that affects every request() call across the SDK. Zero new tests. At minimum, tests should cover: valid numeric string, empty string, non-numeric string ("abc"), negative number, zero, and the fallback when process.env is undefined (non-Node runtimes).

2. Environment variable name

MCP_TOOL_CALL_MCP_REQUEST_TIMEOUT_MSEC contains "MCP" twice and "TOOL_CALL" despite applying to all requests, not just tool calls. The constant is DEFAULT_REQUEST_TIMEOUT_MSEC. Suggested: MCP_REQUEST_TIMEOUT_MSEC (shorter, accurate scope).

3. Unnecessary try/catch

Number.parseInt() never throws. Number.parseInt(undefined) returns NaN, Number.parseInt("abc") returns NaN, and NaN > 0 is false. The try/catch is dead code. The > 0 check handles all invalid inputs correctly on its own.

4. process.env assumes Node.js

The MCP SDK runs in Cloudflare Workers, Deno, and browser-like environments where process.env may not exist. The try/catch accidentally guards against this (catching the ReferenceError), but this should be an intentional check:

const envValue = typeof process !== 'undefined' && process.env
  ? Number.parseInt(process.env.MCP_REQUEST_TIMEOUT_MSEC ?? '', 10)
  : NaN;

5. Evaluated once at module load

The IIFE runs at import time. Setting the env var after importing the module has no effect. This should be documented, or the env var should be read lazily (at request time).

6. No upper bound

MCP_TOOL_CALL_MCP_REQUEST_TIMEOUT_MSEC=999999999 (31+ years) would be accepted. A reasonable ceiling (e.g., 3600000 / 1 hour) would prevent misconfiguration.

7. Changeset says minor

This adds no new API surface (no new function, class, or type). It changes behavior of an existing constant based on environment. This is a patch, not a minor.

---

I'd suggest: rename the env var, drop the try/catch, add runtime detection for non-Node environments, add tests, and change the changeset to patch.

[haydenrear]

The intent is reasonable (60s is too short for many agent operations), but the implementation has several issues:

1. No tests

This modifies a core constant that affects every request() call across the SDK. Zero new tests. At minimum, tests should cover: valid numeric string, empty string, non-numeric string ("abc"), negative number, zero, and the fallback when process.env is undefined (non-Node runtimes).

2. Environment variable name

MCP_TOOL_CALL_MCP_REQUEST_TIMEOUT_MSEC contains "MCP" twice and "TOOL_CALL" despite applying to all requests, not just tool calls. The constant is DEFAULT_REQUEST_TIMEOUT_MSEC. Suggested: MCP_REQUEST_TIMEOUT_MSEC (shorter, accurate scope).

3. Unnecessary try/catch

Number.parseInt() never throws. Number.parseInt(undefined) returns NaN, Number.parseInt("abc") returns NaN, and NaN > 0 is false. The try/catch is dead code. The > 0 check handles all invalid inputs correctly on its own.

4. process.env assumes Node.js

The MCP SDK runs in Cloudflare Workers, Deno, and browser-like environments where process.env may not exist. The try/catch accidentally guards against this (catching the ReferenceError), but this should be an intentional check:

const envValue = typeof process !== 'undefined' && process.env
  ? Number.parseInt(process.env.MCP_REQUEST_TIMEOUT_MSEC ?? '', 10)
  : NaN;

5. Evaluated once at module load

The IIFE runs at import time. Setting the env var after importing the module has no effect. This should be documented, or the env var should be read lazily (at request time).

6. No upper bound

MCP_TOOL_CALL_MCP_REQUEST_TIMEOUT_MSEC=999999999 (31+ years) would be accepted. A reasonable ceiling (e.g., 3600000 / 1 hour) would prevent misconfiguration.

7. Changeset says minor

This adds no new API surface (no new function, class, or type). It changes behavior of an existing constant based on environment. This is a patch, not a minor.

I'd suggest: rename the env var, drop the try/catch, add runtime detection for non-Node environments, add tests, and change the changeset to patch.

Hello,

Thanks for the review!

I've just made the above changes and pushed them.

Thank you,
Hayden

[felixweinberger]

Hi @haydenrear thanks for this contribution - could you provide some additional context and motivation for this PR?

Are you running into a problem with this behavior in production or is this speculative? There's no linked issue, so it's unclear if you're trying to address a real problem or not.

[haydenrear]

Hi @haydenrear thanks for this contribution - could you provide some additional context and motivation for this PR?

Are you running into a problem with this behavior in production or is this speculative? There's no linked issue, so it's unclear if you're trying to address a real problem or not.

Hi Felix,

This is not speculative. MCP tool calls are timing out after 60 seconds in Claude Code. Then, I patched the JavaScript bundled, updated my typescript modules to make it a higher timeout, and it didn't time out.

In the PR, I mentioned that there are many reasons for MCP tool calls longer than 60 seconds. For example, in my workflow we call another agent. This agent sometimes does research and maybe yields to the human for review. This can take 5-10 minutes sometimes, conservatively. However, I can come up with many reasons.

If we make it an environmental variable, like, for instance, MCP_TOOL_TIMOUT in Claude Code I can set that env when running. This allows me to set a sensible default on my system. Much like when I run the MCP Java server and I set a request timeout, except it allows me to skip patching the minified code manually after I download it, upgrade it.

In fact I created another issue to build on this to provide a fallback and env in the client.ts for exactly this: #1863

The main problem is that libraries may not pass in the timeout parameter, then it falls back to the default, which then we have to patch the minified code instead of having a way to set the default as an environmental variable. Exposing the fallback as an environmental variable is well established way of managing defaults as well.

Thank you,
Hayden