Tool Calling: Let the Model Use Your Code
Define tools, run the call and result loop safely, and get a model to use your functions correctly.
A taste of a lesson
My order lookup tool takes an order_id. Can the model just pass whatever id the user mentions?
It can pass the id, but your code must decide whether this user may see that order. The model might misread an id, or a user might ask for someone else's order on purpose. So in the tool function, take the order id from the arguments but the user identity from your authenticated session, and check the order belongs to that user before returning anything. If not, return a result like order not found for this account. Where does your app currently get the user's identity?
Written by the teacher as an example. In your lesson the tutor answers your own questions, and like any AI it can be wrong.
What you will be able to do
- Define tools with clear names, descriptions and parameter schemas
- Implement the call, execute and return result loop with limits
- Return errors as tool results the model can recover from
- Enforce permissions using the real user identity, not model supplied ids
- Add confirmation and idempotency to tools with side effects
Lesson plan
- 1 The tool calling message sequence Trace exactly what is sent and returned in one tool assisted answer. Start
- 2 Designing a good tool Write a tool definition the model will use correctly. Start
- 3 Building the loop Implement the loop with iteration and time limits and parallel calls. Start
- 4 Validation and errors Check arguments and report failures in a way the model can use. Start
- 5 Permissions and side effects Keep tools safe when they read private data or change things. Start
- 6 Testing tool use Check that the model picks the right tool with the right arguments. Start
Try asking
About this tutor
For developers who want a model to look things up, calculate or act through their own functions: checking an order status, querying a database, converting currencies. You learn how tool calling works across providers in general terms: you describe tools with names, descriptions and parameter schemas; the model asks for a call; your code validates and runs it and sends back the result; the model continues. You build the loop with iteration limits, handle errors as results the model can read, write descriptions that lead to correct tool choice, and put permission checks and confirmations around tools with side effects.
Reviews
4.7
3 ratingsSample
- Stefan H.Sample
Iteration limits and idempotent side effects are now in our design checklist. Clear, careful teaching.
- Joao M.Sample
Seeing the full message sequence written out made tool calling click. The permission lesson caught a real hole in my order lookup.
- Nkechi U.Sample
Good on descriptions and error results. My model stopped guessing order ids once errors came back as readable results. Wanted more on parallel calls.
About the teacher
Structured output, tool calling and safe input handling for LLM applications that must behave predictably
9 tutors 308 lessons taught Sample
I teach the parts of LLM apps where free text has to meet real software: JSON that must parse, tools the model calls, images and documents coming in, and users who send things you did not plan for. I spent years writing integrations between messy systems, which taught me to treat every input as untrusted and every output as something...
See Greta's profile and tutorsMore like this
Other tutors on the same or nearby topics.