[PR #2387] [MERGED] fix(scripts): pass MCP callTool timeouts as request options #5197

New issue

Closed

opened 2026-10-31 01:04:44 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-31 01:04:44 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/2387
Author: @AurelioB
Created: 10/12/2026
Status: ✅ Merged
Merged: 10/13/2026
Merged by: @baron

Base: main ← Head: fix/mcp-calltool-timeout

📝 Commits (1)

926ba76 fix(scripts): pass MCP callTool timeouts as request options

📊 Changes

3 files changed (+5 additions, -9 deletions)

View changed files

📝 scripts/verify-real-ghidra-mips-relocatable.mjs (+1 -3)
📝 scripts/verify-real-ghidra-mips.mjs (+0 -3)
📝 scripts/verify/javascript/recovery.mjs (+4 -3)

📄 Description

Problem

@modelcontextprotocol/client is pinned to 2.3.1, which declares callTool(params, options). Three verifiers still use the v1 shape callTool(params, undefined, { timeout }). The SDK drops the third argument, so those calls run under its 60 s default (DEFAULT_REQUEST_TIMEOUT_MSEC = 6e4) instead of the timeout they request:

Script	Line	Timeout requested
`scripts/verify-real-ghidra-mips.mjs`	172	180 s
`scripts/verify-real-ghidra-mips.mjs`	182	60 s
`scripts/verify-real-ghidra-mips.mjs`	417	180 s
`scripts/verify-real-ghidra-mips-relocatable.mjs`	127	180 s
`scripts/verify/javascript/recovery.mjs`	44	150 s

They pass today because their fixtures are small. On a slow or cold host, any call over 60 s fails even though the script asked for more. That's how I ran into it: a Ghidra analysis of a firmware libc takes about 71 s.

Fix

Pass the options as the second argument. No other call site in scripts/, src/ or tests/ uses the SDK Client with three arguments; the remaining three-argument callTool calls belong to REA's own provider clients, whose signature is (operation, params, options).

Verification

Runtime demonstration (throwaway script against scripts/rea.mjs mcp, binary_session):

Timeout position Result

{ timeout: 1 } third the call completes

{ timeout: 1 } second SdkError: Request timed out
Affected verifiers on this branch, all exit 0:
- npm run verify:javascript:recovery, with the official Wakaru 1.14.0 binary (SHA-256 checked) and esbuild 0.25.10 / webpack 5.101.3 installed as in CI.
- npm run verify:ghidra:mips (Ghidra 12.1.4).
- npm run verify:ghidra:mips-relocatable (Ghidra 12.1.4).
Formatting and lint: oxfmt --check and oxlint on the changed files.

Timeout position	Result
`{ timeout: 1 }` third	the call completes
`{ timeout: 1 }` second	`SdkError: Request timed out`

No persistent regression test: the affected calls are inline closures inside .mjs verifier scripts, outside type checking. A behavioral test would need those wrappers exported and driven against a deliberately slow MCP server, which is a refactor beyond this fix. The runtime comparison above exercises the SDK behavior directly.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/2387 **Author:** [@AurelioB](https://github.com/AurelioB) **Created:** 10/12/2026 **Status:** ✅ Merged **Merged:** 10/13/2026 **Merged by:** [@baron](https://github.com/baron) **Base:** `main` ← **Head:** `fix/mcp-calltool-timeout` --- ### 📝 Commits (1) - [`926ba76`](https://github.com/morluto/rea/commit/926ba7647d4e96cb24a1f0db02cc560838054e8b) fix(scripts): pass MCP callTool timeouts as request options ### 📊 Changes **3 files changed** (+5 additions, -9 deletions) <details> <summary>View changed files</summary> 📝 `scripts/verify-real-ghidra-mips-relocatable.mjs` (+1 -3) 📝 `scripts/verify-real-ghidra-mips.mjs` (+0 -3) 📝 `scripts/verify/javascript/recovery.mjs` (+4 -3) </details> ### 📄 Description ## Problem `@modelcontextprotocol/client` is pinned to 2.3.1, which declares `callTool(params, options)`. Three verifiers still use the v1 shape `callTool(params, undefined, { timeout })`. The SDK drops the third argument, so those calls run under its 60 s default (`DEFAULT_REQUEST_TIMEOUT_MSEC = 6e4`) instead of the timeout they request: | Script | Line | Timeout requested | |---|---|---| | `scripts/verify-real-ghidra-mips.mjs` | 172 | 180 s | | `scripts/verify-real-ghidra-mips.mjs` | 182 | 60 s | | `scripts/verify-real-ghidra-mips.mjs` | 417 | 180 s | | `scripts/verify-real-ghidra-mips-relocatable.mjs` | 127 | 180 s | | `scripts/verify/javascript/recovery.mjs` | 44 | 150 s | They pass today because their fixtures are small. On a slow or cold host, any call over 60 s fails even though the script asked for more. That's how I ran into it: a Ghidra analysis of a firmware `libc` takes about 71 s. ## Fix Pass the options as the second argument. No other call site in `scripts/`, `src/` or `tests/` uses the SDK `Client` with three arguments; the remaining three-argument `callTool` calls belong to REA's own provider clients, whose signature is `(operation, params, options)`. ## Verification - **Runtime demonstration** (throwaway script against `scripts/rea.mjs mcp`, `binary_session`): | Timeout position | Result | |---|---| | `{ timeout: 1 }` third | the call completes | | `{ timeout: 1 }` second | `SdkError: Request timed out` | - **Affected verifiers on this branch**, all exit 0: - `npm run verify:javascript:recovery`, with the official Wakaru 1.14.0 binary (SHA-256 checked) and esbuild 0.25.10 / webpack 5.101.3 installed as in CI. - `npm run verify:ghidra:mips` (Ghidra 12.1.4). - `npm run verify:ghidra:mips-relocatable` (Ghidra 12.1.4). - **Formatting and lint:** `oxfmt --check` and `oxlint` on the changed files. No persistent regression test: the affected calls are inline closures inside `.mjs` verifier scripts, outside type checking. A behavioral test would need those wrappers exported and driven against a deliberately slow MCP server, which is a refactor beyond this fix. The runtime comparison above exercises the SDK behavior directly. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-31 01:04:44 +00:00