Ask a language model what the weather is right now, and it will fail — not because it's unintelligent, but because it has no eyes. It was trained on text that stopped at some point in the past, and weather is not a fact you can memorize into a static set of numbers. The model can guess, hedge, or hallucinate a plausible-sounding forecast. What it cannot do, on its own, is find out.
Tool use is the fix for that gap. It is the mechanism that lets a model say, in effect, "I don't know this — let me go check," and then actually go check: call a weather API, query a database, run a calculation, search the web, or push a button in some other system. It is the single feature that turns a model from a text generator into something that can act on the world, and it is the foundation underneath almost everything people now call an "AI agent."
This post explains what tool use is, how it actually works under the hood, why it has become the default architecture for serious AI applications, and where it still breaks down.
What "Tool Use" Actually Means
Strip away the branding and tool use is a narrow, mechanical idea: a language model can request that a piece of code be run on its behalf, and it can receive the result of that code back into its context.
That's it. The model doesn't execute anything itself — it has no hands. What it does is:
- Look at a list of available tools (functions), each described by a name, a plain-language description of what it does, and a schema describing its inputs.
- Decide, based on the conversation, that calling one of those tools would help answer the question.
- Emit a structured request naming the tool and providing arguments that match the schema.
- Wait for the calling application to actually run that function and hand back a result.
- Read the result and continue — either answering the user directly or calling another tool.
Every step from "run the function" onward happens outside the model. The model's only contribution is deciding what to call and with what arguments, expressed as structured data instead of prose. This is why the older, still-common name for the same idea is "function calling" — the model isn't using a tool in any physical sense, it's calling a function the way one piece of code calls another, except the caller is a probabilistic system guessing at the right call based on context.
This distinction matters because it clarifies where responsibility sits. The model proposes; your application disposes. Nothing a model "does" with a tool happens unless the surrounding software chooses to execute the request — which is also where every safety guarantee in the system has to live.
How It Works Under the Hood
The plumbing is more mundane than the term "agent" suggests, and understanding it demystifies most of what looks like magic from the outside.
Tool definitions are just schemas
Before a model can call anything, the application tells it what's available. Each tool definition typically includes:
- A name (
get_weather,search_orders,send_email) - A description in plain language explaining what the tool does and, increasingly, when to call it
- An input schema — usually JSON Schema — specifying the exact shape of arguments the tool expects: field names, types, which fields are required, and any constraints like enumerated values
This schema is the entire contract. The model has never seen your database, your API, or your codebase. It only knows what the schema and description tell it. A vague description ("interacts with the calendar") produces vague, unreliable tool calls. A precise one ("Schedules a meeting; requires a start time in ISO 8601 and a list of attendee emails; do not call this for tentative or unconfirmed meetings") produces far more reliable behavior. Prompt engineering, in agentic systems, is largely tool-description engineering.
The request/response cycle
When the model decides a tool is useful, its response contains a structured block instead of (or alongside) plain text — a tool-call object naming the tool and containing arguments that match the schema. The calling application:
- Parses that structured block (never string-matches it — always parse it as data, since formatting details like escaping can vary)
- Executes the corresponding real function with those arguments
- Packages the output as a "tool result" and sends it back to the model as part of the ongoing conversation
- Lets the model continue — it now has the tool's output in its context and can use it to answer, or call another tool
Crucially, the API underneath this is stateless. Every request in the cycle resends the full conversation history, including the earlier tool call and its result — nothing is "remembered" between calls except what's explicitly included. Drop the tool-call block from history and the model loses track of what it already tried; this is the source of a lot of early bugs.
Parallel calls and forced choice
Two refinements make the mechanism more practical:
- Parallel tool calls. A single model turn can request multiple tool calls at once — for example, checking the weather in three cities in one shot rather than three separate round trips. The application should execute them concurrently and return all the results together, since splitting them across multiple turns tends to make future parallel calls less likely.
- Tool choice control. The calling application can constrain whether the model must call a tool at all, is free to decide, is forced into one specific tool, or is blocked from calling any tool this turn. This is useful for cases like structured extraction, where you always want the model to "call" a formatting tool rather than reply in prose.
Error handling is part of the contract
Tools fail — APIs time out, inputs are invalid, records don't exist. A tool result can be marked as an error, and a well-built harness returns that error back to the model rather than crashing the whole exchange. Models generally handle this well: told that a lookup failed, they'll often retry with corrected arguments or ask the user for clarification, the same way a competent human assistant would.
Why It Matters Right Now
Tool use is not a hypothetical capability being previewed somewhere — it is the default architecture underneath customer support bots that check order status, coding assistants that read and edit real files, research tools that search the live web, and back-office automations that update real records. Any product description that says an AI "can look things up," "can take actions," or "is connected to your systems" is describing tool use, whether or not the vendor uses that term.
The reason it has become foundational rather than a niche feature is structural: a language model's knowledge is frozen at training time and its reasoning happens entirely inside a fixed context window. Tool use is the only mechanism that lets a model reach past both limits — pulling in information that postdates training, and taking actions with effects outside the conversation. Every other technique for making models more useful — better prompting, longer context, more training data — improves what happens inside the model. Tool use is the interface to everything outside it.
This is also why tool use sits at the center of the shift toward "agents." An agent, in the sense the term is normally used now, is a model running in a loop where it can repeatedly call tools, observe the results, and decide what to do next until the task is finished. Remove tool use from that loop and there is no agent — just a chatbot producing one reply per turn. The agentic behavior people find impressive is not a different kind of model; it's the same tool-use mechanism, run in a loop long enough to look autonomous.
The Agentic Loop: From Single Calls to Autonomous Systems
It's worth separating three tiers of sophistication, because they're often conflated under the single word "agent."
| Tier | What happens | Typical use case |
|---|---|---|
| Single tool call | Model calls one tool, gets a result, answers | "What's the weather in Austin?" |
| Manual multi-step loop | Application code repeatedly sends the conversation back to the model, executing whatever tools it requests, until it stops asking for more | A support bot that looks up an order, checks a refund policy, then issues a refund |
| Open-ended agent loop | The model is given a broad toolset (file access, code execution, web search) and runs many iterations autonomously toward a goal, deciding its own sequence of steps | A coding agent that plans, edits multiple files, runs tests, and iterates until they pass |
The mechanism is identical at every tier — it's the same request/response tool-calling cycle. What changes is how many iterations run before a human looks at the output, and how much discretion the model has over which tools to reach for and in what order. Most production systems today sit in the middle tier deliberately: enough autonomy to be useful, with checkpoints where a human approves anything risky or irreversible before it executes.
That checkpoint pattern — often called a permission or confirmation gate — is one of the more important practical patterns to come out of this space. Some tool calls are safe to auto-execute (read a record, run a search). Others should pause and wait for explicit approval before running (send an email, delete a file, transfer money). Good agent design treats "should this run automatically or wait for a human" as a property of the tool, not a global setting — a support agent might auto-approve order lookups while requiring approval for refunds over some threshold.
Practical Implications for Builders
If you're designing a system that uses tool-calling models, a handful of decisions determine whether it's reliable or flaky.
Promote actions to dedicated tools when they need special handling. A generic "run this shell command" tool is flexible but opaque — your application can't tell a safe read-only command from a destructive one without parsing the command string itself. A dedicated tool with a typed schema (delete_file(path: string)) lets your harness reason about the call before it runs: gate it behind approval, log it distinctly, or reject a path outside an allowed directory. The rule of thumb: start broad for flexibility, and carve out a dedicated tool wherever you need to gate, audit, or render an action differently from the rest.
Write tool descriptions for the reader that actually consumes them — the model, not your team. Internal API documentation is written for engineers who already understand the domain. A tool description needs to state, explicitly, the conditions under which it should be called, because the model has no other signal. "Searches the product catalog" is weaker than "Searches the product catalog by keyword; call this before answering any question about whether a product exists, its price, or its stock level — do not answer from memory."
Validate everything a model sends you. A tool call's arguments are model output, not a trusted client — they should be validated exactly as you'd validate user input, because in one sense they are: a probabilistic system's best guess, not a guarantee of correctness. This applies with extra force to anything resembling a file path or a database query, both classic injection surfaces.
Design for retries, not just success. Tool calls fail for mundane reasons — a downstream API times out, a record doesn't exist, an argument is slightly malformed. Returning a clear, structured error (rather than crashing or silently swallowing it) lets the model correct course. This is often more effective than trying to make the tool call itself infallible.
Decide your approval strategy per tool, not globally. Map every tool your agent can call against two questions: is this action reversible, and how bad is it if it's wrong? Read-only, reversible actions can usually run automatically. Irreversible or high-stakes actions — sending external communications, spending money, deleting data — should default to a human-in-the-loop confirmation step until you have enough production evidence to trust the automation.
A simple checklist for a new tool before shipping it:
- Does the name and description unambiguously signal when to call it, and when not to?
- Does the input schema reject malformed arguments before they reach your business logic?
- Is the output size manageable, or could a single call return an enormous blob that floods the model's context?
- If it fails, does it return a clear, actionable error rather than a stack trace or a silent empty result?
- Should this action require human confirmation before it executes?
Real Limitations and Open Questions
Tool use closes the "the model doesn't know things" problem, but it introduces new failure modes that are less familiar to teams used to thinking about model accuracy alone.
Models can call the wrong tool, or call the right tool with wrong arguments. A model deciding to call a tool is still a probabilistic judgment, not a guaranteed-correct dispatch. It can invoke a tool it doesn't need, skip one it should have used, or fill in a plausible-looking but wrong argument (a slightly wrong date format, a hallucinated ID). This is why validation on the receiving end isn't optional — it's the actual line of defense.
More tools is not always better. Loading dozens of tool definitions into every request consumes context space and, past a certain point, measurably degrades a model's ability to pick the right one. Systems with large tool libraries increasingly rely on a secondary step — searching or retrieving only the relevant tool definitions for a given request — rather than exposing everything all the time.
Tool results are an injection surface. If a tool fetches content from the outside world — a web page, an email, a document someone else wrote — that content lands directly in the model's context, and the model treats it as information rather than untrusted input. Text embedded in a fetched page that reads like an instruction ("ignore previous instructions and...") is a live prompt-injection risk. This is genuinely unsolved; current best practice is defense in depth — least-privilege tool permissions, approval gates on consequential actions, and treating anything from a tool result as data to reason about, never as an instruction to follow.
Long tool-use loops accumulate cost and drift. Each round trip resends the growing conversation history, so a long agentic session gets expensive in both tokens and latency. It can also drift — an agent several dozen calls deep can lose track of the original goal or repeat work it already did, especially once earlier context gets summarized or trimmed to fit a limited window.
There's no universal standard for how tools are exposed — yet. Every model provider has its own conventions for defining tools, and connecting a model to a new tool has historically meant custom integration code per provider, per tool. Protocol efforts to standardize how an application exposes tools to any compatible model are still maturing, and interoperability across different vendors' agents remains an active area of change, not a settled question.
What to Watch Next
A few threads are worth tracking as this space develops:
- Standardized tool-exposure protocols. Efforts to let one tool server be reused across different models and applications, instead of writing bespoke integration code for every pairing, are still young and evolving quickly.
- Better built-in judgment about when not to call a tool. Reducing both over-triggering (calling a tool reflexively when the answer was already known) and under-triggering (failing to check when it should have) remains an active tuning problem across the industry, not a solved one.
- Composable, code-driven tool chains. Rather than one tool call per round trip, some systems now let a model write a short script that calls several tools in sequence inside a sandboxed execution step, reducing round-trip overhead for multi-step lookups.
- Stronger permission and audit models. As tool use extends into higher-stakes actions (financial transactions, infrastructure changes), expect more formal, tool-level permission systems — allow, deny, ask — to become standard rather than something every team builds themselves.
None of these change the underlying mechanism described above. They're refinements to how reliably, cheaply, and safely that mechanism runs at scale.
FAQ
What's the difference between tool use and function calling?
They're the same thing under two names. "Function calling" is the older, more literal term — the model calls a function you defined. "Tool use" became more common as the range of things models could invoke expanded beyond simple functions to include code execution, web search, and file access. Both describe a model emitting a structured request that your application executes.
Do I need to fine-tune a model to use tools?
No. Current general-purpose language models are trained to use tools out of the box — you supply tool definitions with your request, and the model decides when and how to use them. Fine-tuning can improve reliability for a narrow, repetitive task, but it isn't a prerequisite.
Can a model call a tool without my application's permission?
No. The model can only request a tool call; it has no way to execute code or reach a network directly. Your application decides whether to actually run the requested function, and can reject, modify, or require approval before it happens. This is the core safety boundary in every tool-using system.
Why does my agent call the wrong tool sometimes?
Usually because the tool's name or description doesn't clearly signal when it should — and shouldn't — be used, or because too many similar tools are available at once and the model can't reliably distinguish between them. Tightening descriptions, reducing the number of simultaneously available tools, and adding explicit trigger conditions ("call this only when...") are the first fixes to try before assuming it's a model-capability problem.
What is an "agentic loop" and how is it related to tool use?
An agentic loop is what you get when tool use runs repeatedly without a human in between each step: the model calls a tool, gets a result, decides what to do with it, and calls another tool, continuing until it judges the task complete or hits a limit you've set. Tool use is the mechanism; the agentic loop is simply that mechanism running iteratively toward a goal instead of stopping after one call.
Is tool use safe for actions like sending money or deleting data?
It can be, but only with deliberate safeguards — input validation on every tool call, least-privilege scoping so a tool can only do what it strictly needs to, and a human-approval step for anything irreversible or high-stakes. Treat the model's tool call the same way you'd treat a request from an untrusted client, because functionally, that's what it is.
How many tools can a model handle at once?
There's no fixed limit, but reliability tends to degrade as the number of simultaneously available tools grows large, since the model has to search a bigger list of options for the right match. Systems that need dozens or hundreds of tools generally do better retrieving or exposing only the subset relevant to the current task rather than presenting everything at once.
If you're weighing how to design a tool-use layer for a real product — what to expose, how to gate risky actions, and how to keep an agentic loop reliable at scale — the team at Woyce Technologies can help you think it through.