MCP tools/call always uses the SDK's 60 s default request timeout — no way to raise it for slow tools

[Gabrielgvl]

Problem

Every MCP tool call that Executor dispatches is cut at 60 s, whatever the server needs. Slow but legitimate tools, such as an agentic "reflect" over a memory store that takes about 2 minutes, always fail with Internal tool error. The server finishes the work after the client has hung up, and the result is discarded.

Root cause (Executor 1.6.7)

• The bundled @modelcontextprotocol/sdk client uses DEFAULT_REQUEST_TIMEOUT_MSEC = 60000 (r?.timeout ?? <default> in the request path).
• The daemon dispatches tools as client.callTool({ name, arguments }) with no request-options argument, so every tools/call gets exactly that default.
• Nothing can change it:
  • the stdio MCP-server registration schema (POST /api/mcp/servers) has no timeout field;
  • executor call and executor daemon run have no timeout flag;
  • the /executions payload has no timeout;
  • no EXECUTOR_* env var sets it.

Evidence

• daemon.log shows three failed dispatches at about 62 s each (the 60 s timeout plus dispatch overhead): ToolInvocationError: MCP tool call failed … → McpInvocationError … transportFailure: true.
• A timed repro, executor call tools <mcp-integration> org default <slow_tool> '{…}', failed after real 1m2.6s. In the same window the MCP server logged that call completing successfully at 130 s.
• Fast tools on the same integration answer in under 1 s, so the transport and the server are healthy.

Request

Make the MCP request timeout configurable, preferably per integration, so slow tools don't make every other call hang longer:

1. An optional requestTimeoutMs in the MCP-server registration (POST /api/mcp/servers), threaded into client.callTool(params, resultSchema, { timeout }). A per-call override (for example executor call --timeout <ms>) would also help.
2. Optionally, pass resetTimeoutOnProgress: true together with maxTotalTimeout, so servers that emit progress notifications can run longer safely.

A global default raise would also work, but it makes every failing MCP call hang longer before erroring, so per-integration scope is preferable.

Environment

Executor v1.6.7 (compiled binary, linux-x64), stdio MCP servers with spawnPerCall: false.