Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix Bundle MCP `callTool` ignores SDK 60s default — long-running tool requests fail with -32001 (followup to #57969) [2 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#78092•Fetched 2026-05-06 06:16:59
View on GitHub
Comments
1
Participants
2
Timeline
3
Reactions
2
Author
sibyllineXsibyllineX
Participants
clawsweeper[bot]clawsweeper[bot]sibyllineXsibyllineX
Timeline (top)
cross-referenced ×2commented ×1

Error Message

#57969 fixed the connection / handshake path. A sibling failure remains in the tool-execution path: callTool ignores per-request options and inherits the SDK's hardcoded DEFAULT_REQUEST_TIMEOUT_MSEC = 60000. Any bundle-MCP tool whose work legitimately takes >60s fails with -32001: Request timed out. Both paths emit the same error code, which is probably why this didn't surface as distinct in the original thread.

Fix Action

Fixed

PR fix notes

PR #78109: fix(mcp): honour per-server requestTimeoutMs for bundle-MCP callTool (#78092)

Description (problem / solution / changelog)

Problem

Closes #78092.

callTool() in pi-bundle-mcp-runtime.ts was called without RequestOptions, so the MCP SDK's hardcoded DEFAULT_REQUEST_TIMEOUT_MSEC = 60000 applied to every tool invocation regardless of server configuration. Long-running MCP tools (filesystem scans, slow external APIs, batch operations) reliably hit the 60 s ceiling and returned -32001 errors with no way to raise the limit on a per-server basis.

Fix

Add requestTimeoutMs to the bundle-MCP server config schema alongside the existing connectionTimeoutMs. Wire it through the resolution chain and use it when calling the SDK.

Config shape (YAML / JSON — same as connectionTimeoutMs): ```yaml mcpServers: my-slow-server: command: node args: [./server.mjs] connectionTimeoutMs: 30000 # existing — controls connect phase requestTimeoutMs: 300000 # new — controls each callTool invocation ```

When requestTimeoutMs is absent the SDK default (60 s) continues to apply, so the change is fully backwards-compatible.

Files changed

FileChange
src/agents/mcp-transport-config.tsAdd requestTimeoutMs?: number to ResolvedBaseMcpTransportConfig; add getRequestTimeoutMs() helper; populate field on both stdio and HTTP resolved configs
src/agents/mcp-transport.tsAdd requestTimeoutMs?: number to ResolvedMcpTransport; propagate from resolved config on all 3 transport branches
src/agents/pi-bundle-mcp-runtime.tsAdd requestTimeoutMs?: number to BundleMcpSession; pass { timeout: session.requestTimeoutMs } as RequestOptions to session.client.callTool()
src/agents/mcp-transport-config.test.ts3 new regression tests: stdio propagation, HTTP propagation, absent → undefined

Tests

Tests  22 passed (22)   # 19 pre-existing + 3 new

🤖 Generated with Claude Code

Changed files

  • src/agents/mcp-transport-config.test.ts (modified, +33/-0)
  • src/agents/mcp-transport-config.ts (modified, +15/-0)
  • src/agents/mcp-transport.ts (modified, +4/-0)
  • src/agents/pi-bundle-mcp-runtime.ts (modified, +7/-4)

PR #78160: fix: extend bundle MCP tool request timeout

Description (problem / solution / changelog)

Fixes #78092.

Summary

  • add per-server bundled MCP requestTimeoutMs with a 10-minute default, separate from connection timeout
  • pass SDK callTool request options with resetTimeoutOnProgress: true
  • document the new setting and add regression coverage for config plumbing plus SDK call options

Tests

  • node scripts/run-vitest.mjs run --config test/vitest/vitest.agents.config.ts src/agents/mcp-transport-config.test.ts src/agents/pi-bundle-mcp-runtime.call-tool-timeout.test.ts --reporter=verbose
  • git diff --check
  • PATH="/tmp/openclaw-pnpm-shim:$PATH" node scripts/check-changed.mjs
  • PATH="/tmp/openclaw-pnpm-shim:$PATH" pnpm exec oxfmt --check src/agents/mcp-transport-config.ts src/agents/mcp-transport.ts src/agents/pi-bundle-mcp-runtime.ts src/agents/mcp-transport-config.test.ts src/agents/pi-bundle-mcp-runtime.call-tool-timeout.test.ts src/config/types.mcp.ts

Changed files

  • docs/cli/mcp.md (modified, +15/-11)
  • docs/plugins/bundles.md (modified, +4/-1)
  • src/agents/mcp-transport-config.test.ts (modified, +21/-2)
  • src/agents/mcp-transport-config.ts (modified, +17/-0)
  • src/agents/mcp-transport.ts (modified, +4/-0)
  • src/agents/pi-bundle-mcp-runtime.call-tool-timeout.test.ts (added, +71/-0)
  • src/agents/pi-bundle-mcp-runtime.ts (modified, +13/-4)
  • src/config/types.mcp.ts (modified, +2/-0)

Code Example

return await session.client.callTool({
    name: toolName,
    arguments: isMcpConfigRecord(input) ? input : {}
});

---

// plugin-sdk/src/config/types.mcp.d.ts
export type McpServerConfig = {
    connectionTimeoutMs?: number;   // existing
    requestTimeoutMs?: number;      // new
    // ...
};

// src/agents/pi-bundle-mcp-runtime.ts
return await session.client.callTool(
    { name: toolName, arguments: isMcpConfigRecord(input) ? input : {} },
    undefined,
    {
        timeout: resolved.requestTimeoutMs ?? DEFAULT_BUNDLE_MCP_REQUEST_TIMEOUT_MS,
        resetTimeoutOnProgress: true,
    }
);
RAW_BUFFERClick to expand / collapse

Followup to #57969

#57969 fixed the connection / handshake path. A sibling failure remains in the tool-execution path: callTool ignores per-request options and inherits the SDK's hardcoded DEFAULT_REQUEST_TIMEOUT_MSEC = 60000. Any bundle-MCP tool whose work legitimately takes >60s fails with -32001: Request timed out. Both paths emit the same error code, which is probably why this didn't surface as distinct in the original thread.

Affected version

openclaw 2026.5.4 · @modelcontextprotocol/sdk 1.29.0.

Source

src/agents/pi-bundle-mcp-runtime.ts, callTool of createBundleMcpRuntime:

return await session.client.callTool({
    name: toolName,
    arguments: isMcpConfigRecord(input) ? input : {}
});

No RequestOptions arg → SDK falls back to 60s. The existing connectionTimeoutMs (resolved at mcp-transport-config.ts:170, consumed by connectWithTimeout) is connect-only and does not reach this code path.

Reproduction

Any bundle-MCP tool whose work takes longer than 60s. The MCP server can be actively streaming and the client cancels regardless.

Suggested fix

Sibling field on McpServerConfig, plumbed to RequestOptions:

// plugin-sdk/src/config/types.mcp.d.ts
export type McpServerConfig = {
    connectionTimeoutMs?: number;   // existing
    requestTimeoutMs?: number;      // new
    // ...
};

// src/agents/pi-bundle-mcp-runtime.ts
return await session.client.callTool(
    { name: toolName, arguments: isMcpConfigRecord(input) ? input : {} },
    undefined,
    {
        timeout: resolved.requestTimeoutMs ?? DEFAULT_BUNDLE_MCP_REQUEST_TIMEOUT_MS,
        resetTimeoutOnProgress: true,
    }
);

resetTimeoutOnProgress: true as default lets servers that emit notifications/progress run unbounded while idle stalls still cap at requestTimeoutMs. The SDK supports it; modelcontextprotocol/typescript-sdk#849 to flip this default upstream was rejected, so opt-in has to live in clients.

A reasonable DEFAULT_BUNDLE_MCP_REQUEST_TIMEOUT_MS is 5–10 min.

PR

Happy to submit one once the field name and default are settled.

extent analysis

TL;DR

Add a requestTimeoutMs field to McpServerConfig and pass it to callTool to override the default 60s request timeout.

Guidance

  • Introduce a new requestTimeoutMs field in McpServerConfig to allow for per-request timeout configuration.
  • Update the callTool method in pi-bundle-mcp-runtime.ts to accept and apply the requestTimeoutMs value from McpServerConfig.
  • Set a reasonable default value for DEFAULT_BUNDLE_MCP_REQUEST_TIMEOUT_MS, such as 5-10 minutes, to handle longer-running bundle-MCP tools.
  • Consider setting resetTimeoutOnProgress to true to allow servers that emit progress notifications to run without timing out.

Example

// plugin-sdk/src/config/types.mcp.d.ts
export type McpServerConfig = {
    connectionTimeoutMs?: number;
    requestTimeoutMs?: number;
    // ...
};

// src/agents/pi-bundle-mcp-runtime.ts
return await session.client.callTool(
    { name: toolName, arguments: isMcpConfigRecord(input) ? input : {} },
    undefined,
    {
        timeout: resolved.requestTimeoutMs ?? DEFAULT_BUNDLE_MCP_REQUEST_TIMEOUT_MS,
        resetTimeoutOnProgress: true,
    }
);

Notes

The suggested fix requires updates to both the McpServerConfig type and the callTool method implementation. The choice of default value for DEFAULT_BUNDLE_MCP_REQUEST_TIMEOUT_MS may depend on specific use cases and requirements.

Recommendation

Apply the suggested workaround by introducing the requestTimeoutMs field and updating the callTool method, as it directly addresses the issue of ignoring per-request options and hardcoded timeouts.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#conversation history#tool integration#LLM response#prompt template#agent execution

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix Bundle MCP `callTool` ignores SDK 60s default — long-running tool requests fail with -32001 (followup to #57969) [2 pull requests, 1 comments, 2 participants]