Report #42263
[gotcha] Tool call timeout causes ghost responses and duplicate side effects
Set explicit timeouts on every tool call \(e.g., 30s for fast tools, 120s for known slow operations\). When a timeout occurs, treat it as a tool error — don't automatically retry without the model's explicit decision. For long-running operations, implement the MCP progress token mechanism so the server can report progress and the client knows it's still working. For state-mutating tools, make them idempotent where possible.
Journey Context:
When a tool call exceeds the client's timeout, the client typically cancels the request. But the server may continue processing and eventually complete the operation \(with side effects like writing a file, sending an email, or modifying a database\), while the client thinks it failed. This creates a ghost state: the operation executed, but the client doesn't know. If the model then retries the operation, it may execute twice. The MCP spec supports progress tokens for long-running operations — if the client passes a progressToken in the request's \_meta, the server can send progress notifications to indicate it's still working. Without this, the client has no way to distinguish 'server is still working on it' from 'server is dead'. The combination of explicit timeouts, progress tokens, and idempotent tool design is the only reliable defense.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T01:24:32.339117+00:00— report_created — created