Tool calls: free-recall review
Free-recall prompts across the tool-calls unit. Answer each in your own words first, then reveal the model answer and compare.
Retrieval beats re-reading. For each prompt, say or write a full answer from memory before you open the model answer — the effort of recall is what makes the mechanism stick.
Reconstruct the unit’s core mechanisms — the round-trip contract, the validation trust boundary, the runaway guard, parallelism, tool_choice, and the schema token cost — without looking back at the lesson.
- 01Describe the tool-use loop. Who is the caller, who is the callee, and what makes each iteration expensive?
- 02Why must you validate tool arguments, and what does 'validate' actually mean for a mutating endpoint like cancel_order?
- 03Why is an unguarded tool-use loop both a correctness risk and a cost risk, and what two guards do you add?
- 04When can the model parallelize tool calls, and when is a chain inherently serial?
- 05Explain the four tool_choice settings and when a senior reaches for each.
- 06Where does the token cost of tools actually come from, and what is the standard mitigation?
If you could reconstruct each answer from memory, you hold the unit’s spine: the model is the caller and your code the callee, so every round trip is a fresh, transcript-re-sending model call; arguments are untrusted input you schema-validate then authorize and existence-check, returning errors as tool_result; an unguarded loop runs away, so cap iterations and detect repeats; parallelism helps only independent calls; tool_choice (auto/any/tool/none) sets whether and which tool fires; and the re-sent tools array is the token cost prompt caching exists to absorb. Now when you ship a tool-calling agent, you’ll reach for the iteration cap and the validator before the first production deploy — not after the first runaway bill.
Something unclear?
Ask a question about this lesson. Questions are anonymous and go straight to the author to make the lesson better.