executeTool rejects top-level intent that its sibling callMcpTool accepts #2455

Problem

The model often sends executeTool calls in a shape that the runtime rejects. Each rejection wastes one tool call. In the recurring-slot scheduling eval (#2413), that matters, because the case has a 60s idle limit and a tool-call budget.

Two shapes show up:

1. A top-level intent key next to tool_name and arguments.
2. Catalog tool parameters at the top level instead of under arguments.

Both are rejected by resolveCatalogToolCall() in packages/junior/src/chat/tool-support/catalog-tool-call.ts with executeTool arguments must be nested under arguments, not top-level fields: ....

Evidence

• In about 98 recent live behavioral runs of the Google scheduling cases, 22 executeTool calls were rejected for their argument shape. The count is from an agent that read the eval transcripts on evals.sentry.dev. It is not re-counted here.
• One example: run e3899820, recurring-slot case. The first google_findMeetingTimes call failed because the model put intent inside the executeTool input.

Likely cause (inference, not confirmed)

The two dispatcher tools have different input contracts:

• callMcpTool (chat/tools/skill/call-mcp-tool.ts) accepts a top-level intent. Its extra-key check allows tool_name, arguments and intent.
• searchMcpTools also takes a top-level intent.
• executeTool (chat/tools/execute-tool.ts) is .strict() and allows only tool_name and arguments.

The model sees both dispatchers in the same turn. It is plausible that it carries intent over from callMcpTool to executeTool. This issue does not prove that; a check of which calls carried intent versus nested parameters would.

Options

• Make the two dispatchers take the same envelope. Either executeTool accepts an optional intent (and passes it where it is useful, such as auth prompts), or neither does.
• Keep executeTool strict, but make the rejection cheaper: the error could name the corrected call shape.

Do not change eval messages, checks or timeouts to hide this. Fix it in the tool contract.

Done when

• The two dispatchers have one documented argument envelope, or the difference is deliberate and explained beside the code.
• The existing primary test for catalog tool calls covers the chosen behavior.
• A live behavioral run of the scheduling cases shows no rejected executeTool shapes.

Refs #2413.

via David Cramer.

--

View Session [Sentry]