Function Calling

Tools turn a text predictor into something that can act: the model picks a function and the args; your code runs it.

Building with AI · Lesson 17 · 11 min read

Your assistant can describe how to check the weather but can’t actually check it — it has no hands. You don’t want it to guess today’s forecast; you want it to call a real weather API. How does a text model reach out into the real world? Function calling is the bridge, and it’s the foundation of every agent.

You describe tools; the model requests them

You give the model a list of tools — each with a name, a description, and a schema for its arguments (e.g. get_weather(city: string)). When a tool would help, the model doesn’t run it (it can’t) — it outputs a structured request: “call get_weather with {city: "Paris"}.” Your code executes the real function, then feeds the result back into the conversation. The model decides what to call and with what arguments; your program does the actual doing.

Tools available: get_weather(city). User: “Should I bring an umbrella in Paris?” Model emits: { "tool": "get_weather", "arguments": { "city": "Paris" } }. Your code calls the API, gets “rain,” feeds it back, and the model replies “Yes — it’s set to rain in Paris.”

The schema is the contract

The tool’s argument schema is what makes this reliable: it tells the model exactly what shape the call must take, and lets your code validate the request before running anything. A clear name + description + typed arguments is the difference between a model that calls tools correctly and one that hallucinates tool names or bad arguments (a failure mode you’ll debug later in this module).

Wiring a calculator tool:
1. Define add(a: number, b: number).
2. User: “What’s 4,318 + 9,127?” 
3. Model emits a call: add with {a: 4318, b: 9127} instead of guessing.
4. Your code runs it (13,445), returns it, and the model states the exact answer. The model chose the tool and args; your code guaranteed the arithmetic.