ask-mcp-integration-is-safely-bounded
IN derived (depth 1)
MCP tool calls in `ask()` are both error-tolerant (exceptions caught and fed back as context for alternative tool selection) and iteration-bounded (5 tool-call rounds max), preventing both crashes from MCP server failures and runaway tool loops.
Summary
The ask function has two guardrails when using MCP tools: if a tool call fails, the error gets handed back to the LLM so it can try a different approach instead of crashing, and the whole process caps out at 5 rounds of tool use so a misbehaving server can't cause an infinite loop. Together these mean MCP integration won't take down the caller or spin forever.
Justifications
SL — MCP errors caught + iteration cap independently bound MCP integration risk
Antecedents (all must be IN):
- ask-mcp-errors-non-fatal — When an MCP bridge's `call_tool` raises an exception during the ask loop, `ask()` catches the error, feeds it back to the LLM as context, and continues the tool loop rather than propagating to the caller.
- ask-mcp-iteration-limit-is-five — When `mcp_servers` is non-empty, `ask()` allows up to 5 tool-call iterations before forcing a final LLM response (6 total invocations), compared to the lower limit without MCP servers.
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.