mcp-bridge-is-timeout-bounded-at-all-phases
IN derived (depth 1)
MCP bridge operations are timeout-bounded at both connection establishment (30s) and per-tool execution (60s), preventing indefinite blocking on unresponsive MCP servers at any lifecycle phase.
Summary
The MCP bridge will never hang forever waiting on a misbehaving MCP server. Both the initial handshake and each individual tool call have hard time limits, so if a server stops responding, the system recovers within at most 60 seconds rather than getting stuck indefinitely.
Justifications
SL — Connection and execution timeouts independently bound both MCP lifecycle phases
Antecedents (all must be IN):
- mcp-bridge-connect-blocks-up-to-30s — `connect()` blocks the calling thread for up to 30 seconds waiting for MCP session initialization via `_ready.wait(timeout=30)`, then raises `TimeoutError` if the server doesn't respond.
- mcp-bridge-call-tool-timeout-60s — `call_tool()` blocks for up to 60 seconds per invocation via `future.result(timeout=60)`; if the MCP server hangs, the calling thread unblocks with `TimeoutError`.
Dependents
These beliefs depend on this one:
- ask-mcp-achieves-accurate-bounded-tool-use — MCP tool integration in ask() achieves both bounded safety (iteration caps, error tolerance, transport timeouts at two layers) and accurate tool discovery (catalog reflects current server capabilities rather than a stale snapshot).
- ask-mcp-is-defense-in-depth-bounded — MCP-backed ask queries are bounded at two independent layers: application-level iteration caps with error-tolerant fallback at the ask layer, plus per-call and connection timeouts at the MCP bridge transport layer — no single timeout failure can cause unbounded execution.