03. Tool calling
Why tool calling is central
A model by itself only generates text.
If you want the system to:
- search the web
- read files
- call APIs
- query a database
- run code
- send messages
then it needs tools.
Tool calling is what turns “knows things” into “can do things”.
Basic idea
The model does not execute the tool directly by magic.
Instead, the system gives the model a list of available tools and their descriptions.
Then the model chooses one when needed.
User asks something
↓
Model decides a tool is needed
↓
System executes tool
↓
Result comes back
↓
Model uses result to continue
Example
User asks:
Find the weather in Hyderabad and summarize whether I need an umbrella.
Possible flow:
- Model chooses weather API tool
- Tool returns forecast data
- Model interprets result
- Final answer is generated
Good tool design
A good tool should have:
- a clear name
- a clear purpose
- predictable inputs
- structured outputs
- error handling
Bad tool descriptions create bad agent behavior.
Common tool categories
Information tools
- web search
- database lookup
- retrieval from vector store
- file reading
Action tools
- send email
- create ticket
- book appointment
- call external API
Computation tools
- calculator
- Python execution
- data transformation
- validators
Risks
Tool use is powerful, but it introduces problems:
- wrong tool selected
- wrong parameters passed
- repeated unnecessary calls
- external failures
- security issues from dangerous tools
That is why tool scope and permissions matter.
Design principle
Do not expose every possible tool.
Only expose the smallest useful set.
This improves:
- reliability
- cost
- safety
- debugging
Next
Continue to Planning loops.