TOOL CALLS · TYPED ARGUMENTS
Gemini LLM tool call: validate typed arguments before dispatch
The model fills count_items with arguments of the wrong type; compare loose coercion with strict validation and a repair turn.
Your experiment
The user asks how many items in warehouse A have at least 5 free units, not counting reserved stock; the correct answer is 19. Start with include_reserved sent as the string "false" and loose coercion, then validate strictly, allow a repair turn and try the other argument cases.
Play replays the computed run over sixty inspection seconds; Next event steps, Restart rewinds, Speed changes the pace and Inspection time scrubs. Any input change recomputes the run and rewinds it without autoplay.
Event trace
Computed data
Final metrics
Teaching model: the fictional tool is written in a dynamically typed style, so values that reach it unvalidated follow JavaScript conversion rules; a strongly typed tool would usually fail on the mismatch instead. The repair turn is a fixture in which the model always corrects its arguments after seeing the error. No model is called.
Truthy strings
The tool count_items declares warehouse as an enum of A or B, min_stock as an integer of at least 0 and include_reserved as a boolean. The user asks how many items in warehouse A have at least 5 free units, not counting reserved stock; the correct answer is 19. In the opening run the model sends include_reserved as the string "false". Loose coercion converts it with Boolean("false"), which is true, so reserved stock is counted and the agent confidently answers 21: WRONG COUNT.
Validate strictly, then let the model repair
Choose Validate strictly against the declaration. The call is rejected because include_reserved must be a boolean, and with no repair turn the agent says it could not run the count: NO ANSWER, but no wrong number. Repair turns after a validation error applies only to strict validation: with 1 turn the validation error goes back to the model as the function response, it returns corrected arguments and the count is 19. A second allowed turn is not needed here.
Which coercions are harmless
Keep loose coercion and change Arguments the model returned. It works by luck for min_stock as the string "5", which converts to 5 and gives 19. The word "five" converts to NaN, so no item qualifies and the answer is 0. A min_stock of -1 is a valid number that breaks the declared minimum, so every one of the 30 items qualifies. A lower-case warehouse "a" fails inside the tool as an unknown warehouse: TOOL ERROR. Strict validation rejects all four before dispatch.
Why the declaration is the contract
Function declarations tell the model the types it should produce, but generated arguments are still text the model wrote. Validating them against the same schema before dispatch turns silent misreads into explicit errors the model can fix, and keeps type conversions out of business code where a truthy string can change an answer.
Reading the run and its limits
Play, Next event, Restart, Speed and Inspection time step through the declaration, the model’s arguments, validation, an optional repair turn, the dispatch and the answer across sixty seconds; the table compares what the model sent with what the tool received. The inventory has 30 fictional items. The tool here follows JavaScript conversion rules; a strongly typed tool would usually throw instead, which is safer but still needs the repair path.