07Tools & Function Calling
How a model “uses” a tool: schemas, tool calls, results and the round trip. Write tool definitions models understand, and design tools that are safe.
What you'll learn
- Explain the tool-calling round trip step by step
- Write clear tool definitions (name, description, parameters)
- Design safe tools with least privilege
- Handle tool errors so agents recover gracefully
The model never runs anything itself
This surprises most people: the LLM can't actually send an email or open a file. What it can do is ask your code to run a named function with specific arguments. Your code runs it and hands back the result. That's function calling (also called tool use).
Anatomy of a tool definition
A tool is described to the model with a name, a description and a JSON Schema for its parameters. The model reads the description to decide when to use it, so the description is effectively a prompt.
{
"name": "check_invoice_status",
"description": "Look up the payment status of a client invoice by its invoice number. Use this whenever the user asks whether an invoice is paid, overdue, or how much is owed. Returns status, amount due in PHP, and days overdue.",
"input_schema": {
"type": "object",
"properties": {
"invoice_id": {
"type": "string",
"description": "The invoice number, digits only, e.g. '1042'"
}
},
"required": ["invoice_id"]
}
}
Different providers use slightly different field names (input_schema, parameters), and many SDKs generate this from normal functions automatically — as you'll see in Lesson 09.
Writing tools models use correctly
Name tools like verbs
search_products,create_calendar_event,get_order_status. Avoid vague names likehelperorprocess.Write descriptions for a newcomer
Say what it does, when to use it, what it returns, and any gotchas. Three or four sentences is normal for important tools.
Describe every parameter with an example
Formats matter: “ISO date like 2026-10-10”, “amount in PHP, no commas”.
Keep tools focused
One clear job each. A handful of well-designed tools beats dozens of overlapping ones.
Return useful, compact results
Return what the model needs to decide the next step — not a 5 MB raw API dump. Summarize or paginate large outputs.
Return helpful errors
Instead of crashing, return
"error: invoice 1O42 not found — IDs are digits only". The model will often correct itself and retry.
Designing safe tools
| Principle | In practice |
|---|---|
| Least privilege | Give a support agent get_order_status, not full database access. Read-only by default. |
| Separate read from write | Reading data is low risk. Writing, sending, paying and deleting need extra checks. |
| Approval gates | For irreversible actions, the tool prepares the action and a human confirms before it runs. |
| Validate arguments | Check types, ranges and allow-lists in your code — never trust the model's arguments blindly. |
| Rate and spend limits | Cap how many emails, API calls or pesos a tool can use per run. |
| Log everything | Record each call, its arguments and results. You'll need it for debugging and accountability. |
Common tool types for business agents
Information
Web search, knowledge-base search, read file, database query, get weather/exchange rate.
Computation
Run Python, calculator, spreadsheet formulas — exact math instead of guessing.
Content
Write file, create document, generate image, fill a template.
Communication
Draft/send email, post to Slack or Telegram, send SMS — usually behind approval.
Systems
Create CRM contact, update order, add calendar event, create invoice.
Browser
Open pages, click, fill forms — powerful and slow; use APIs when they exist.
Instead of writing every integration yourself, you can plug in ready-made tool servers through the Model Context Protocol (Lesson 11).
Key takeaways
- The model proposes tool calls; your code executes them — you stay in control.
- Tool descriptions are prompts: say what, when, and what it returns.
- Focused tools, clear parameters, compact results and helpful errors make agents reliable.
- Least privilege, approval gates, validation and logs make agents safe.
Knowledge check
0 / 3Q1Who actually executes a tool during function calling?
The model returns a structured request; your code runs the function.
Q2What does the model mainly use to decide when to call a tool?
The name and description tell the model what the tool is for and when to use it.
Q3Best practice for a tool that sends payments?
Irreversible financial actions need approval gates and hard limits.