Tool calling is how a language model stops just talking and starts doing something. Instead of only producing text, the model can request that a specific function — like "check the weather" or "look up an order" — be run on its behalf, then use the result to keep going.
Without tool calling, a model can only guess based on what it learned during training. With it, the model can pull a live database record, send an email, or run a calculation, and fold the real answer back into its response.
This one capability is what turns a chatbot into an agent. Once a model can call tools, it can act in a loop: decide, call a tool, read the result, decide again.
What tool calling actually is
Tool calling (sometimes called "function calling") is a structured way for a model to say: "run this specific function, with these specific arguments." The model doesn't execute anything itself — it only outputs a request. Your application code is the one that actually runs the function and hands the result back.
The typical flow looks like this:
- 1.You send the model a prompt plus a list of available tools (name, description, expected arguments).
- 2.The model decides a tool is needed and returns a structured call, like
get_weather(city="Austin"). - 3.Your code runs that function for real.
- 4.You send the result back to the model as a new message.
- 5.The model uses the result to write its final answer, or calls another tool.
Why models need tools at all
Language models are frozen at training time and have no direct connection to the outside world. They can't check today's stock price, read your calendar, or update a record in your CRM.
Tools close that gap. A tool can be:
- An API call (weather, stock prices, shipping status)
- A database query (customer records, inventory)
- A calculation (anything the model would otherwise get wrong doing math in its head)
- An action (sending a message, creating a ticket, updating a row)
Anatomy of a tool call
Most tool calling llm implementations share the same three pieces, whether you're using OpenAI's function calling, Anthropic's tool use, or an open-source framework.
| Piece | What it is | Example |
|---|---|---|
| Name | Unique identifier for the tool | search_flights |
| Description | Plain-English explanation the model reads to decide when to use it | "Searches available flights between two cities on a given date." |
| Schema | The expected arguments and their types | {origin: string, destination: string, date: string} |
The description matters more than people expect. A vague description leads to the model calling the wrong tool, or calling the right tool with bad arguments — the model only has your text to go on.
A simple example
Here's a minimal tool call and response, in plain JSON, to show the shape:
{
"tool_call": {
"name": "get_order_status",
"arguments": { "order_id": "A19284" }
}
}Your backend runs the real lookup, then sends the result back:
{
"tool_result": {
"order_id": "A19284",
"status": "shipped",
"eta": "2026-04-20"
}
}The model reads that result and writes something like "Your order shipped and should arrive by April 20."
Tool calling vs plain prompting
| Plain prompting | Tool calling | |
|---|---|---|
| Source of facts | Model's training data | Live systems you connect |
| Can take action | No | Yes (via your code) |
| Freshness | Frozen at training cutoff | Real-time |
| Reliability for math/lookups | Often wrong | As accurate as the tool |
The model never touches your systems directly — it only requests actions. Your code stays in control of what actually runs.
Common failure modes
Tool calling is powerful, but it breaks in predictable ways:
- Wrong tool chosen — usually a sign the tool descriptions are too similar or too vague.
- Malformed arguments — the model guesses a field name or format that doesn't match your schema.
- Hallucinated tool calls — the model invents a tool that doesn't exist, often because the prompt didn't clearly list what's available.
- Missing the result — a model asked to use a tool but not given the result back will just make one up.
Good schemas, tight descriptions, and validating arguments before you execute anything solve most of these.
Where tool calling fits in agentic AI
Tool calling by itself is just one request-response exchange. It becomes an agent when you wrap it in a loop: the model calls a tool, sees the result, decides whether it needs another tool, and keeps going until the task is done. That loop — plus memory of what's already happened — is the core mechanic behind most agent frameworks in use today.
If you want to see how tool calls chain together into full agent behavior, the agent loop is the next concept to learn, and what is agentic AI covers the bigger picture.
FAQ
What is tool calling in an LLM?
Tool calling is a feature that lets a language model request that a specific function run, with specific arguments, instead of only generating text. The model outputs a structured request; your application executes the actual function and returns the result.
Is tool calling the same as function calling?
Yes, in practice. "Function calling" was the original term (popularized by OpenAI's API), and "tool calling" is the more general term used across providers and frameworks. They describe the same mechanism.
Can a model call a tool without my code running it?
No. The model only produces a request — it has no ability to execute code, hit an API, or touch a database on its own. Your application is always the one that decides whether and how to run the requested function, which is also your main safety control point.
Do I need a framework to use tool calling?
No. Tool calling is a feature of the model's API — you can implement it with a few lines of code calling the model directly. Frameworks like LangGraph or CrewAI add convenience for managing many tools and multi-step loops, but they're not required to get started.