Here is a puzzle. A language model does exactly one thing: it produces text. It cannot search the web, read a file, or query a database. And yet AI agents do all of those things constantly. How?

The answer is tool use (also called function calling), and it is the mechanism that underpins every agent. Once it clicks, the whole idea of agents stops seeming magical. The model still only produces text. The trick is what that text is allowed to say.

The model proposes, your code disposes #

The key insight is that the model never runs anything itself. It only asks. When a model “uses a tool,” what actually happens is that instead of replying with an ordinary sentence, it produces a structured request that means “please run this specific tool with these specific inputs.” Your program sees that request, runs the real function, and hands the result back.

Think of the model as an extremely capable colleague locked in a room with a phone but no hands. It cannot touch anything in the outside world. But it can pick up the phone and say, precisely, “look up the weather in Paris.” Someone outside the room does it and reads the answer back. The model figures out what to do; your code does it.

What a tool definition looks like #

For the model to call a tool, it has to know the tool exists and how to use it. You provide that up front as a tool definition, which has three parts:

• A name, like get_weather.
• A description of what it does and, ideally, when to use it: “Get the current weather for a city. Use this whenever the user asks about current conditions.”
• An input schema, which spells out the arguments the tool takes and their types, for example a required location string and an optional unit that must be “celsius” or “fahrenheit.”

You hand the model a list of these definitions along with the user’s request. Now the model knows its options.

How a tool call actually flows #

Put the pieces in motion and a single tool call goes like this:

1. You send the model the user’s question plus the available tool definitions.
2. The model decides it needs a tool and, instead of text, emits a call: get_weather with location = "Paris". It fills in the arguments according to the schema you gave it.
3. Your program executes the real get_weather function, which calls a weather service and gets back “18 degrees and cloudy.”
4. You return the result to the model as the answer to its call.
5. The model continues, now able to say “It is 18 degrees and cloudy in Paris.”

That round trip, model asks, your code answers, model continues, is a single turn of the agent loop. Chain many of them together and you have an agent.

Parsing the request safely #

One practical note that trips people up. The model’s tool call arrives as structured data (usually JSON), and you should treat it as data, not as text to eyeball. Always parse it properly with a JSON parser and validate it against the schema before acting on it. Different models format their output with slightly different quirks, and matching on raw strings will eventually break. Parse it, check it, then run the tool.

Why the description matters so much #

The single biggest lever on whether tool use works well is the quality of your tool descriptions. The model decides whether and how to call a tool based almost entirely on the name, the description, and the schema. Vague descriptions lead to a tool that gets ignored when it should be used, or used when it should not.

Good tool descriptions are specific about when to reach for the tool, not just what it does. “Get current prices” is weak. “Get the current stock price for a ticker symbol. Call this whenever the user asks about a current or recent price, rather than answering from memory” is strong, because it tells the model the trigger condition. Writing tool descriptions is genuinely part of building a good agent, not an afterthought.

Two flavors: your tools and the platform’s tools #

Worth knowing that there are two kinds of tools in practice. Your own tools are functions you write and execute, like the get_weather example. There are also built-in tools some AI platforms run for you on their own servers, like web search or code execution, where you just declare that the tool is available and the platform handles running it. From the model’s point of view they work the same way: it emits a call, a result comes back. The only difference is who does the executing.

That is the whole mechanism. A model that only writes text becomes able to act because one of the things it can write is a request to run a tool, and something outside the model honors that request. Everything an agent does, from booking a flight to fixing a bug, is built on this one simple loop of asking and answering.