# Tools and Function Calling: Giving Your Agent Hands
Ask a language model "What's the weather in Tokyo right now?" and it will do one of two things: guess, or admit it doesn't know. It has no window to the outside world. It can reason and write, but it can't *look things up* or *do* anything.
Tools change that. A tool is a function your agent can call: a weather lookup, a database query, a "send email" action, a calculator. You describe the tool, the model decides when to use it, and suddenly your agent has hands.
A tool (also called a function in this context) is just a piece of code you already have, wrapped so the AI can request it.
You give the model three things:
get_weather.The model never runs your code. It only reads these descriptions and, when it seems useful, says: "Please call get_weather
city = TokyoHere is a concrete tool definition. This format is nearly identical across OpenAI, Anthropic, and Google:
{
"name": "get_weather",
"description": "Get the current weather for a city. Use this whenever the user asks about weather, temperature, or conditions.",
"parameters": {
"type": "object",
"properties": {
"city": {
"type": "string",
"description": "The city name, e.g. 'Tokyo' or 'Paris'"
},
"units": {
"type": "string",
"enum": ["celsius", "fahrenheit"],
"description": "Temperature units"
}
},
"required": ["city"]
}
}Notice how much the description is doing. "Use this whenever the user asks about weather" is not decoration. It is instruction. The model reads it to decide *whether* to call the tool at all.
Here is the core idea, and it's simpler than it sounds. You and the model take turns.
1. You send the user's message plus the list of tools available.
2. The model replies in one of two ways: a normal text answer, or a request to call a tool (with the arguments filled in).
3. If it asks for a tool, your code runs the real function and sends the result back.
4. The model reads the result and either answers the user or asks for another tool.
That loop repeats until the model has what it needs. This back-and-forth is what people mean by function calling or tool calling.
Walk through a real exchange:
get_weather with city='Tokyo'."{"condition": "rain", "temp_c": 14}.The model made a decision (I need live data), you did the work (called the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.Voir la définition complète →), and the model turned the raw result into a helpful answer.
The exact function names differ per provider, but the shape is always the same. Here is the loop in pseudo-Python that mirrors how every major SDK works:
tools = [get_weather_definition] # the JSON schema from above
messages = [{"role": "user", "content": "Umbrella in Tokyo today?"}]
while True:
response = model.generate(messages=messages, tools=tools)
if response.wants_tool_call:
call = response.tool_call # e.g. get_weather(city="Tokyo")
result = run_my_function(call.name, call.arguments)
# feed the real result back into the conversation
messages.append(response.as_message())
messages.append({
"role": "tool",
"name": call.name,
"content": result
})
continue # loop again so the model can use the result
# no tool needed: we have a final answer
print(response.text)
breakRead the loop once more. The while True is the whole trick: keep going as long as the model keeps asking for tools, then stop when it produces a plain answer. An agent that can call several tools in a row (look up a customer, then check their orders, then draft a reply) is just this loop running a few more times.
If you want the underlying standard behind these JSON parameter definitions, the JSON Schema documentation is the free, canonical reference.
The model can only use what you describe well. Most agent failures trace back to sloppy tool definitions, not a "dumb" model.
Vague:
> search: searches things
Clear:
> search_help_articles: Search the internal support knowledge base for articles about billing, refunds, and account settings. Returns the top 3 matching articles. Use this before answering any policy question.
The second version tells the model *what's inside*, *what it gets back*, and *when to reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.Voir la définition complète → for it*.
Every optional parameter is a chance for the model to guess wrong. Use enum (a fixed list of allowed values) when there are only a few valid options, like ["celsius", "fahrenheit"]. Mark truly required fields as required. Fewer, clearer inputs mean fewer mistakes.
Send back clean, labeled data:
{"condition": "rain", "temp_c": 14, "city": "Tokyo"}not a wall of raw HTML or a 500-line log. The model has to interpret whatever you return, so make it easy.
Vérification des acquis
1. According to the lesson, what fundamental limitation of a plain language model do tools address?
2. In the function-calling workflow described, who actually executes the tool's code?
3. Why does the lesson stress that the tool's description ('Use this whenever the user asks about weather...') is 'not decoration'?
4. Select ALL correct answers. According to the lesson, which three things must you provide to the model when defining a tool?
Sélectionnez toutes les réponses correctes.
5. Select ALL correct answers. What does the JSON Schema portion of a tool definition accomplish?
Sélectionnez toutes les réponses correctes.
Once the loop clicks, you start seeing tools everywhere. A few patterns that show up in almost every real agent:
There's a real difference between a tool that *reads* (get weather, search articles) and one that *acts* (send email, charge a card).
Read tools are low-risk: worst case, the agent looks something up it didn't need. Action tools can do damage if the model gets it wrong. For those, add a guardrail: require human confirmation before sending, limit what the tool can touch, or log every call. A "send refund" tool should probably cap the amount and ask a person to approve anything large.
This is a design decision, not a coding detail. Decide up front which tools your agent can fire on its own and which need a human in the loop.
Every major provider supports this same tool-calling pattern, and each ships a higher-level agent SDK (a software toolkit that runs the loop for you so you don't hand-write the while True):
They handle the plumbing: passing tools, parsing tool calls, feeding results back. The concept you just learned is the thing all three are built on. When you're ready for provider-specific syntax, see the deep-dive blocks for each vendor.
One more thing worth knowing: there's a growing open standard called the Model Context Protocol (MCP) that lets you define a tool *once* and plug it into agents from different providers. Think of it as a universal adapter for tools. It's increasingly the default way teams share tools across systems in 2026.