ask-mcp-tool-use-has-current-catalog
OUT derived (depth 1)
Ask's MCP tool integration achieves full reliability — errors caught, iterations bounded — with the tool catalog always reflecting the MCP server's current capabilities rather than a stale connection-time snapshot.
Summary
The ask function's MCP integration is claimed to be fully robust on three fronts: tool errors don't crash the loop, the number of tool-call rounds is capped, and the list of available tools stays up to date with what the MCP server actually offers. This last part — the fresh catalog — is what makes the claim go beyond its supporting evidence, since the antecedents only cover error handling and iteration limits, not whether the tool list can go stale after the initial connection.
Justifications
SL — Full MCP reliability requires fresh tool catalogs, not just error handling and iteration bounds
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.
Unless (any of these IN defeats this justification):
- mcp-bridge-tools-snapshot-at-connect — The tool catalog and server instructions are populated once during `connect()` and never refreshed — there is no mechanism to pick up tools added after the initial handshake.