MCP‐adapter tool timeouts are never applied when invoked via ToolNode

[simozampa]

Checked other resources

• I added a very descriptive title to this issue.
• I searched the LangChain.js documentation with the integrated search.
• I used the GitHub search to find a similar question and didn't find it.
• I am sure that this is a bug in LangChain.js rather than my code.
• The bug is not resolved by updating to the latest stable version of LangChain (or the specific integration package).

Example Code

import { StateGraph, Annotation }    from "@langchain/langgraph";
import { ToolNode }                  from "@langchain/langgraph/prebuilt";
import { MultiServerMCPClient }      from "@langchain/mcp-adapters";

// 1) Load your MCP tools…
const client = new MultiServerMCPClient({ /*…*/ });
const tools  = await client.getTools();
const toolNode = new ToolNode(tools);

// 2) Build a simple graph that routes every AI message to the tools:
const StateAnn = Annotation.Root({ messages: Annotation() });
async function echoModel(state) {
  return { messages: [state.messages.at(-1)!] };
}
function route(state) { return "tools"; }

const graph = new StateGraph(StateAnn)
  .addNode("agent",    echoModel)
  .addNode("tools",    toolNode)
  .addEdge("__start__", "agent")
  .addEdge("agent",    "tools")
  .addEdge("tools",    "agent")
  .addConditionalEdges("agent", route)
  .compile();

// 3) Bind a timeout+signal on the top‐level runnable…
const runner = graph.withConfig({
  timeout: 10_000,           // 10 seconds
  signal: new AbortController().signal,
});

// 4) Stream… and watch your debug logs inside `ToolNode.run`:
//    you’ll see “config.timeout === undefined”
const stream = await runner.stream(
  { messages: [{ role: "user", content: "…" }] },
  { recursionLimit: 5, streamMode: "messages" }
);

Error Message and Stack Trace (if applicable)

No response

Description

LangChain’s MCP adapters docs claim you can set per‐tool timeouts via the standard RunnableConfig interface:

// either…
const slowToolWithTimeout = slowTool.withConfig({ timeout: 300_000 });
await slowToolWithTimeout.invoke({ /*…*/ });

// or…
await slowTool.invoke({ /*…*/ }, { timeout: 300_000 });

When you do

const toolWithTimeout = tool.withConfig({ timeout: 5000 });

you actually get back a RunnableBinding, not a DynamicStructuredTool. A RunnableBinding does not expose the .invoke(args, config) signature that ToolNode expects, so even trying to wrap the tool in a withConfig before passing it to ToolNode breaks invocation entirely.

In addition, when you embed tools with custom timeout in a graph via ToolNode, any { timeout, signal } in the config is silently dropped. Inside ToolNode.run, the config argument passed down to tool.invoke(...) always has timeout === undefined, so the MCP client falls back to its default 1 minute default

System Info

@langchain/core: ^0.3.57
@langchain/mcp-adapters: v0.5.1
@langchain/langgraph: v0.2.74
@modelcontextprotocol/sdk: ^1.11.2
Node.js: 20.18.0

[lkm1developer]

same issue with simple langgraph

let tools = await client.getTools();
tools = tools.map(t => t.withConfig({ timeout: 300000 }));
const model = new ChatOpenAI({
modelName: "gpt-4o",
temperature: 0,
});

const agent = createReactAgent({
llm: model,
tools,
});

const response = await agent.invoke({
messages: [{ role: "user", content: "do some heavy stuff" }],
});

Error###

Error during agent execution: BadRequestError: 400 Missing required parameter: 'tools[0].function.name'.
at APIError.generate (file:///E:/a/node_modules/openai/error.mjs:41:20)

System Info###

"@langchain/core": "^0.3.57",
"@langchain/langgraph": "^0.2.74",
"@langchain/mcp-adapters": "^0.5.2",
"@langchain/openai": "^0.5.11"

[hntrl]

Thanks for the issue @simozampa and the followup @lkm1developer!

@simozampa I see in the example code that you have you're attaching the timeout to the graph but not the tools. Are you expecting to be able to add that timeout independent of the graph timeout? i.e. new ToolNode(tools.map((t) => t.withConfig({ timeout: 5000 }))?

@lkm1developer I'll dig into this more, but this does look like either a regression or a small incompatibility between the openai and mcp-adapters packages. Just to be clear you're looking to handle these mcp calls locally rather than using OpenAI's built in MCP tools, correct?

[simozampa]

Thanks for the issue @simozampa and the followup @lkm1developer!

@simozampa I see in the example code that you have you're attaching the timeout to the graph but not the tools. Are you expecting to be able to add that timeout independent of the graph timeout? i.e. new ToolNode(tools.map((t) => t.withConfig({ timeout: 5000 }))?

@lkm1developer I'll dig into this more, but this does look like either a regression or a small incompatibility between the openai and mcp-adapters packages. Just to be clear you're looking to handle these mcp calls locally rather than using OpenAI's built in MCP tools, correct?

Hi @hntrl thanks for replying,

When i do new ToolNode(tools.map((t) => t.withConfig({ timeout: 5000 })) the graph invocation breaks.

So I tried to attach the timeout to the graph as well as to the ToolNode by doing new ToolNode(tools).withConfig({ timeout: 5000 }) but in this case the timeout is ignored silently

PS: I am using ChatAnthropic

[hntrl]

@simozampa Yeah I think we intentionally don't bubble the config to the containing tools in a ToolNode when using withConfig like that. I would think that mapping over the tool list and applying the timeout that way is more "semantically correct".

Could you paste the error message you get when you try to construct the tool node with that map? Is it the same 400 error as above?

[simozampa]

@hntrl Makes sense

Yes same error above. but even before running the code i get a type error Property 'withConfig' does not exist on type 'StructuredToolInterface<ToolInputSchemaBase, any, any>'.ts(2339)

[lkm1developer]

@hntrl I tried with anthropic and openai model, both throw the error with timeout config, without timeout it works . here is my full sample code with errors

Anthropic llm Error

Error during agent execution: BadRequestError: 400 {"type":"error","error":{"type":"invalid_request_error","message":"tools.0.custom.name: Field required"}}

Troubleshooting URL: https://js.langchain.com/docs/troubleshooting/errors/INVALID_TOOL_RESULTS/

at APIError.generate (file:///E:/a/node_modules/@anthropic-ai/sdk/error.mjs:37:20)

Openai llm error

Error###

Error during agent execution: BadRequestError: 400 Missing required parameter: 'tools[0].function.name'.
at APIError.generate (file:///E:/a/node_modules/openai/error.mjs:41:20)

import { ChatOpenAI } from "@langchain/openai";
import { createReactAgent } from "@langchain/langgraph/prebuilt";
import { ChatAnthropic } from "@langchain/anthropic";

const anthropicLLm = new ChatAnthropic({
  model: "claude-3-haiku-20240307",
  temperature: 0,
  maxTokens: undefined,
  maxRetries: 2,
  apiKey: '***'
});
// Create client and connect to server
const client = new MultiServerMCPClient({
  throwOnLoadError: true,
  prefixToolNameWithServerName: true,
  additionalToolNamePrefix: "mcp",
  useStandardContentBlocks: true,
  mcpServers: {
    scrape: {
      transport: "stdio",
      command: "node",
      args: ["E:/mcp-servers/test-server/build/index.js"],
      restart: {
        enabled: true,
        maxAttempts: 3,
        delayMs: 1000,
      },
    }
  },
});

let tools = await client.getTools();
tools = tools.map(t => t.withConfig({ timeout: 300000 }));
// Create an OpenAI model
const openAiLLm = new ChatOpenAI({
  modelName: "gpt-4o",
  temperature: 0,
  apiKey: '***'
});

// Create the React agent
const agent = createReactAgent({
  llm: anthropicLLm,
  tools,
});

// Run the agent
try {
  const mathResponse = await agent.invoke({
    messages: [{ role: "user", content: "scrape the url meerkats.ai" }],
  });
  console.log(mathResponse);
} catch (error) {
  console.error("Error during agent execution:", error);
  // Tools throw ToolException for tool-specific errors
  if (error.name === "ToolException") {
    console.error("Tool execution failed:", error.message);
  }
}

await client.close();```

[lkm1developer]

@hntrl I figure out that invoke ignore the timeout but call pick the the timeout (call is deprecated)

Working with timeout

let tools = await client.getTools();
tools = tools.map((t) => ({
  ...t,
  invoke: (p, config) => {
    config.timeout=80000
   return  t.call(p, config, )
  },
}));

Not working with timeout

let tools = await client.getTools();
tools = tools.map((t) => ({
  ...t,
  invoke: (p, config) => {
    config.timeout=80000
   return  t.invoke(p, config, )
  },
}));

[oneWalker]

I found it was fixed once by the official developer. But the problem still exists. We can adjust it to less than 60s but not avaliable to over 60s.
#8241

It works with t.call not t.invoke

[hntrl]

Apologies for the delay! Unfortunately the errors that you're seeing I think are an artifact of some hard to spot limitations with the Runnable api that was hard to foresee when it was first created. I won't bore you with the details, but calling .withConfig sets the inheritance up in a way where we lose the information needed to serialize the tool which is the reason you're seeing the 400 errors. The docs that we have in the README seem to be specifically for invoking mcp tools directly, but using that pattern when passing back to a model call/ graph invocation will cause issues for that reason. We have it slated to readdress this design for the first major version of langchain.

Unfortunately it means that adding a timeout in this has to come with a quick and dirty fix. @lkm1developer @oneWalker @simozampa what would you say to adding the timeout directly in the constructor of MultiServerMCPClient? I.e.

const client = new MultiServerMCPClient({
  throwOnLoadError: true,
  prefixToolNameWithServerName: true,
  additionalToolNamePrefix: "mcp",

  useStandardContentBlocks: true,

  mcpServers: {
    filesystem: {
      transport: "stdio",
      command: "npx",
      args: ["-y", "@modelcontextprotocol/server-filesystem", "."],
+     toolTimeout: 80000
    },
  },
});

Only limitation with this is it doesn't let you set timeouts on a per tool basis, but hopefully the above explains why that's more difficult (the .call and .invoke overrides that are in the thread can also work in the interim)

[hntrl]

Yes same error above. but even before running the code i get a type error Property 'withConfig' does not exist on type 'StructuredToolInterface<ToolInputSchemaBase, any, any>'.ts(2339)

I'll work on a fix for specifically this as it should be a DynamicStructuredTool instead of the interface type

[oneWalker]

Apologies for the delay! Unfortunately the errors that you're seeing I think are an artifact of some hard to spot limitations with the Runnable api that was hard to foresee when it was first created. I won't bore you with the details, but calling .withConfig sets the inheritance up in a way where we lose the information needed to serialize the tool which is the reason you're seeing the 400 errors. The docs that we have in the README seem to be specifically for invoking mcp tools directly, but using that pattern when passing back to a model call/ graph invocation will cause issues for that reason. We have it slated to readdress this design for the first major version of langchain.

Unfortunately it means that adding a timeout in this has to come with a quick and dirty fix. @lkm1developer @oneWalker @simozampa what would you say to adding the timeout directly in the constructor of MultiServerMCPClient? I.e.

const client = new MultiServerMCPClient({
throwOnLoadError: true,
prefixToolNameWithServerName: true,
additionalToolNamePrefix: "mcp",

useStandardContentBlocks: true,

mcpServers: {
filesystem: {
transport: "stdio",
command: "npx",
args: ["-y", "@modelcontextprotocol/server-filesystem", "."],

• toolTimeout: 80000
  

  },
  },
  });
  Only limitation with this is it doesn't let you set timeouts on a per tool basis, but hopefully the above explains why that's more difficult (the .call and .invoke overrides that are in the thread can also work in the interim)

@hntrl
Sounds great! Is it included in the release version? Timeout settings for the server can cover most of the cases. It will be better to support both if possible.

[hntrl]

@oneWalker This isn't released yet as there's some additional work needed to make this possible. It may take a bit for me to get to this though, so a PR is welcome!

By us "supporting both" do you mean setting tool timeouts for all the tools from a server + on an individual basis?

[simozampa]

Apologies for the delay! Unfortunately the errors that you're seeing I think are an artifact of some hard to spot limitations with the Runnable api that was hard to foresee when it was first created. I won't bore you with the details, but calling .withConfig sets the inheritance up in a way where we lose the information needed to serialize the tool which is the reason you're seeing the 400 errors. The docs that we have in the README seem to be specifically for invoking mcp tools directly, but using that pattern when passing back to a model call/ graph invocation will cause issues for that reason. We have it slated to readdress this design for the first major version of langchain.

Unfortunately it means that adding a timeout in this has to come with a quick and dirty fix. @lkm1developer @oneWalker @simozampa what would you say to adding the timeout directly in the constructor of MultiServerMCPClient? I.e.

const client = new MultiServerMCPClient({
throwOnLoadError: true,
prefixToolNameWithServerName: true,
additionalToolNamePrefix: "mcp",

useStandardContentBlocks: true,

mcpServers: {
filesystem: {
transport: "stdio",
command: "npx",
args: ["-y", "@modelcontextprotocol/server-filesystem", "."],

• toolTimeout: 80000
  

  },
  },
  });
  Only limitation with this is it doesn't let you set timeouts on a per tool basis, but hopefully the above explains why that's more difficult (the .call and .invoke overrides that are in the thread can also work in the interim)

hi @hntrl

thank you for the update.

the proposed solution would work great for me. i am currently hardcoding the timeout in the langchain mcp adapters build to override the timeout for all tools.