Lesson deck
Function and tool calling flashcards
Reviewing needs JavaScript. You can read every card in the list below.
Loading your cards...
Back to the lesson6 cards in this deck
Read all 6 cards as a list
- Front
- What does the model actually do when it "calls a function"?
- Back
- It emits a structured request (tool name plus arguments). Something outside the model executes it; for your own tools that is your application, which returns the result linked to the call id.
- Front
- What does a tool definition contain, and why does its quality matter?
- Back
- Name, description and JSON-schema parameters (with required fields). It is the only thing the model knows about the tool, so vague names, empty descriptions or free-text arguments lead to wrong calls.
- Front
- Why make side-effecting tools idempotent?
- Back
- Retries and loops can repeat a call. An idempotency key lets the downstream service recognise a repeat and not charge twice or send a duplicate email.
- Front
- Name four controls your executor applies to a model-proposed call.
- Back
- Validate arguments, authorize from the real session (not a model-supplied id), set timeouts with bounded retries, and treat results as untrusted. Add idempotency keys for side effects.
- Front
- Does strict mode make a tool call safe?
- Back
- No. Strict mode makes arguments follow the schema more reliably. It does not check permissions or whether the values are sensible, so executor checks stay.
- Front
- Client tools vs provider-hosted tools?
- Back
- Client tools are defined by you and run in your code. Hosted tools (for example web search or code execution) run on the provider's infrastructure, with less code for you but less control and possible extra charges.