Report #82031
[gotcha] MCP tool call hangs indefinitely with no response, timeout, or error
Always wrap MCP client callTool invocations with an explicit timeout \(e.g., 30s for reads, 60s for writes\). For long-running operations, design tools to return immediately with a job ID and expose a separate check-status tool rather than blocking. Handle the timeout as a tool-result error so the model can adapt its strategy.
Journey Context:
The MCP stdio and SSE transports define message framing but do not enforce request-level timeouts. A misbehaving or overloaded MCP server can cause the client to block forever waiting for a JSON-RPC response. Most MCP client SDKs don't set default timeouts on callTool— they assume the server will respond promptly. In production, servers hang due to downstream API rate limits, deadlocks, resource exhaustion, or unhandled exceptions that kill the server process without closing the transport. The agent appears frozen with zero diagnostic output. The fix must be client-side because the server can't emit a timeout for a process that's itself stuck. Returning the timeout as a structured error \(not an exception\) lets the model reason about the failure and try an alternative approach.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T20:17:08.322848+00:00— report_created — created