Tool Calling Explained: How Models Ask Software to Act, and Where It Breaks

Early chatbots were question-answering machines. A person typed something, a reply came back, and the exchange ended there. Useful, but boxed in. A model could describe how to book a flight without being able to look up today's fares. It could explain what goes on an invoice yet never create one in the billing system. It could propose a meeting time and still have no way to see anyone's calendar, let alone put the event on it.

Function calling removes that wall. A language model gets a way to ask the surrounding software for help, and the rest of the stack grows out of that one ability.

A model that can ask for things

Without tools, a model answers from what it absorbed during training. With them, it can conclude that a question needs outside help and say which tool should supply it: a weather service, a search index, a database query, a calculator, a calendar, a payment flow, a CRM lookup, a code interpreter, or some internal business function. Instead of guessing, the model emits a structured request, the application fulfils it, and the model carries on with fresher and more exact information in hand. The big providers, OpenAI, Anthropic and Google among them, along with frameworks like LangChain, describe tool use the same broad way: well-defined tools are offered to the model, it decides when to invoke them, passes structured arguments, and folds the returned results into its answer or action.

A handy mental picture: the model is the conversational brain, and tools are the hands, eyes, memory, calculator, filing cabinet and delivery van. The brain works out what the user wants. The tools do the things that raw text generation cannot do safely or dependably.

Function calling versus tool calling

The two phrases get used interchangeably, and the second is the more accurate, because the idea reaches beyond classic programming functions. A tool might be as small as get_weather(location). It could equally be a database search, a browser session, document retrieval, a calculator, a shell command, a design pipeline, or a link to an external service. In OpenAI's vocabulary, a tool is a capability exposed to the model, and a tool call is a special kind of model reply asking for one of them to be used.

Crucially, the model normally does not run anything itself. In the common client-side arrangement it returns a structured request, something like a call to get_customer_profile with a customer_id of 12345. The application receives it, inspects it, executes the real function, gathers the output and returns that to the model, which then writes its final response. The documented sequence is: supply the available tools, get back a tool call, run the code in your own app, send the result in, and receive either a final answer or further tool calls.

There are exceptions. Certain providers also host server-side tools that run on their infrastructure. Anthropic splits the two cleanly: client tools are executed by your application and surface as structured tool-use blocks, while server tools such as web search or code execution can run on Anthropic's side.

The distinction carries weight. Saying "the model called an API" might mean the model produced a request for your software to carry out, or it might mean the platform ran a built-in tool on the model's behalf. In production this changes security posture, logging, costs, how data is handled, who approves what, and who is accountable when something goes wrong.

The loop in five steps

Most function-calling systems repeat one cycle.

1. Define the tools. Each tool gets a name, a description and a list of expected inputs. A weather tool may need a city and a country. A refund tool may need an order ID, a reason and a maximum amount. A scheduling tool may need attendees, a date, a time and a topic. OpenAI's examples describe parameters in a JSON Schema style with required fields and restrictions such as additionalProperties set to false, and Google's Gemini documentation shows function declarations built from names, descriptions and input structures.
2. The user asks for something. The model reads the request and judges whether it can answer straight away. "Explain what function calling is" probably needs no tool. "What is the status of order 8472?" almost certainly does.
3. The model issues a call. It returns the tool name and arguments in a structured form. For several independent jobs, current APIs permit more than one call in a single turn. OpenAI's documentation says a response can carry zero, one or many tool calls, each with its own ID and JSON arguments, and Gemini documents parallel function calling for separate tasks.
4. The application executes. Ordinary software engineering takes over here. The app validates the arguments, checks permissions, calls the right service, copes with errors, records what happened and shapes the result.
5. The result goes back. Now the model holds what it was missing and can answer naturally, for example that an order shipped this morning and should land on Tuesday, or that three open meeting slots exist and the earliest is tomorrow at 10:30.

The cycle may run once or loop many times. An agent could search, compare results, call another tool, ask a follow-up, update a record, and finally summarise what it did.

Language as the interface

The real appeal of tool use is that everyday language becomes a flexible front end to software.

Traditionally every feature needs its own buttons, forms, menus and flows. With function calling a user can state intent directly: locate the most recent Acme invoice, see whether payment arrived, and if not, write a courteous reminder email. One sentence hides several tools behind it: a CRM search, an invoice fetch, a payment-status check, an email draft, and perhaps an approval request before anything is sent.

Good product design does not become optional. What shifts is where the interface starts. Rather than making people learn the software's structure, the software moves toward the way people already talk about their work.

That puts a lot of weight on tool descriptions. A vague one leaves the model unsure how to use the tool. A clear one says when to reach for it, what it does, what each input means, and what should not be assumed. LangChain's documentation frames tools as functions with well-specified inputs and outputs, and notes that type hints and brief descriptions help the model use them properly.

A good tool is more than a function. It is a contract.

Four terms that overlap

People blur these words, though they sit at different layers.

• Function calling is the mechanism: the model asks for a structured function or tool invocation.
• Tool use is the wider capability. It takes in function calling, built-in tools, web search, file search, code execution, computer control, remote servers and any other way a model can touch external systems.
• An agent is a system that strings tool use across several steps toward a goal. OpenAI describes agents as applications that plan, use tools, work with specialists and track progress through multi-step tasks, and its Agents SDK defines one as an LLM configured with instructions, tools, and optional extras such as handoffs, guardrails and structured outputs.
• Automation is what happens when all this is wired into real workflows. A tool-using model might summarise a support ticket. An agent could study the ticket, review the customer's history, judge urgency, draft a reply and send the case to the right team. Automation runs that sequence on every new ticket, with a human sign-off required before refunds, account changes or sensitive messages.

Said another way: function calling is the socket, tools are the appliances plugged in, agents decide how and when to use them, and automation makes the whole thing run as part of a living system.

Why bother

Language models are strong at understanding, combining and communicating information. They are poor stand-ins for calculators, databases or live monitors. They can write about weather but cannot know today's forecast unless wired to that data. They can discuss an invoice but cannot reach your billing system unless it is connected. They can explain code but cannot tell whether your service is down without monitoring data.

Tools close those gaps. A calculator makes arithmetic dependable. Search supplies current facts. Retrieval grounds answers in private documents. A database tool answers questions about company records. A workflow tool creates tickets, sends messages, updates orders or books appointments. Google's Gemini documentation boils the benefits down to three: adding knowledge, extending abilities, and acting through outside systems.

This is the point where the experience stops feeling like chat and starts feeling like software. The model is no longer only producing words; it helps coordinate work.

Research behind the idea

Tool-using agents did not appear from nowhere. Four pieces of earlier research shaped the field.

• MRKL Systems (2022) proposed a modular design joining language models to external knowledge and reasoning modules. The core thought was simple: do not ask one model to do everything; give each job to a specialised component.
• ReAct (2022) studied how models can interleave reasoning with action. Rather than only thinking or only acting, ReAct-style prompting has a model reason, act, observe the outcome and revise its plan. The loop improves performance on question answering and decision tasks and makes behaviour easier to follow.
• Toolformer (2023) tested whether a model could teach itself to use tools through simple APIs. It learned when a tool was warranted, what to send and how to use the output, with calculators, search engines, translators and calendars as examples.
• Gorilla (2023) went after large-scale API calling and a practical headache: with many tools on offer, models sometimes invent calls or supply wrong arguments. Gorilla combined training with retrieval so the system could track changing API documentation and make fewer errors.

All of it converges on one idea: the best AI systems are not isolated models. They are parts of larger systems joined to tools, memory, rules, software and human oversight.

What a good tool looks like

Strong tools are narrow, understandable and safe.

Narrow tools are easier for a model to pick and for developers to control. A tool called update_everything is vague and dangerous. create_refund_request is clearer. approve_refund deserves even more caution, as it changes the real world.

Understandable tools carry plain names and descriptions. A model should not have to guess whether fetch_record means getting a customer profile, downloading a file or retrieving a medical record. A description should state its purpose, the situations that call for it, the meaning of every argument and the shape of the return value.

Safe tools come with built-in limits. They check permissions, validate input and avoid handing out access that is not needed. They report clear errors, keep logs and ask for human approval before sensitive actions. They never grant the model more power than the job calls for.

OpenAI recommends strict schemas so arguments arrive reliably, and its Agents SDK points developers toward guardrails, human review, clear results, state management and observability as workflows grow. In practice the best tools are boring: each does one job well and surprises nobody, whether developer, model or user.

Schemas as grammar

A schema is the grammar of tool use. When the model calls a function it must supply arguments in a shape the application understands. The schema fixes which fields exist, their types, which are required, and sometimes which values are permitted. A weather tool might demand a string location and a units field limited to celsius or fahrenheit.

Strict schemas cut ambiguity and simplify validation. OpenAI's documentation explains that strict mode keeps calls faithful to the declared schema, and it requires constraints like additionalProperties set to false with every field marked required, using nullable types to express optional values.

A schema does not make a system safe, though. A flawlessly formatted request can still be a bad one. A send_email call addressed to all_customers@example.com may satisfy the schema perfectly and still be a terrible idea. Schema validation therefore has to travel with business rules, authorisation, rate limits, review steps and monitoring.

Reading versus acting

One important design decision is whether a tool only reads or also acts.

Read-only tools fetch information: searching documents, looking up records, checking inventory, pulling weather, computing totals, inspecting logs. They can still expose sensitive data and need access control, but they typically change nothing.

Action tools get things done. They send email, place orders, cancel subscriptions, issue refunds, update databases, open tickets, deploy code or schedule meetings. Mistakes with them have real consequences.

A well-built agent treats the two kinds differently. Read-only tools can be used more freely, still behind permission checks. Action tools generally need tighter controls: confirmation screens, approval steps, transaction limits, audit logs, rollback options and clear messages to the user.

At this point automation becomes a management question and not only a technical one. The issue is not whether the model can call the function. It is under what conditions any system should be allowed to perform the action on a person's behalf.

From single calls to agents

One tool call can answer a simple question. Agents exist for longer, messier jobs. Asked to prepare a weekly sales summary and flag accounts needing attention, an agent may have to pull sales data, compare it to earlier weeks, spot unusual patterns, read CRM notes, write the summary and send it to a manager. That is a chain of decisions, not a single call.

Agent frameworks manage the chain. They hold state, run tools, retry failed steps, pass work between specialist agents, produce structured output, enforce guardrails and keep traces. OpenAI's Agents SDK documentation describes two common shapes: a manager pattern in which a central agent calls specialist agents as if they were tools, and handoffs in which one agent transfers control to a specialist.

Powerful, yes, but not something to idealise. An agent is not a small employee living inside your software. It is a probabilistic system built from code, and it needs defined responsibilities, limited permissions, test cases, monitoring, escalation routes and plans for failure. The more freedom an agent gets, the more careful the engineering around it must be.

Where automation meets real work

Automation is the stage at which tool use turns into operations.

• A support team may use an agent to classify tickets, fetch relevant policy documents, draft replies and propose next steps.
• A finance team may reconcile invoices, find missing purchase orders and prepare exception reports.
• An engineering team may inspect failing tests, search logs, propose fixes and open pull requests.
• A sales team may enrich leads, prepare call notes and update the CRM.

The strongest automation does not start from what the model can do. It starts from an existing workflow. Where does the work begin? What information does it need? Which decisions are routine and which are sensitive? Where do people currently review, approve or correct? Which errors would be irritating, and which would be expensive?

With those answers in hand, tools help the process run more smoothly. The agent collects facts, fills forms, drafts messages, compares records and makes recommendations, while people stay involved wherever judgment, accountability or trust matters.

Standardised connections

Early integrations were bespoke. Each app had its own way of exposing tools, resources, prompts and authentication. That worked for small projects and got unwieldy as organisations linked more models to more systems.

The Model Context Protocol (MCP) is one attempt to standardise this layer. Its specification describes how applications can share context, expose tools and features, and build flexible integrations through a host, client and server arrangement. MCP servers can offer resources, prompts and tools. The protocol exchanges JSON-RPC 2.0 messages and covers capability negotiation, progress tracking, cancellation, logging and error reporting.

The upside is plain: a shared tool layer lets AI applications connect to data sources and workflows consistently, so every company does not rebuild every integration. The downside is new risk. A tool server offering powerful actions should be treated by the host app as a genuine security boundary and not as one more plugin. MCP's own specification stresses user consent, data privacy, tool safety and care around arbitrary data access and code-execution paths.

Security comes first

Tool-using agents are valuable because they act, and that same ability brings risk.

Prompt injection is the best-known threat: hostile instructions hidden in user input or external content that push the model into behaviour it should avoid. OWASP lists it among the top risks for LLM applications, and its 2025 material also calls out excessive agency, where an LLM-based system has more power to act than is wise, so unexpected, ambiguous or manipulated output can lead to harmful actions.

Indirect injection worries people most with agents. Suppose an agent reads email and can send replies. A malicious sender could bury a line in a message telling it to disregard its rules and forward the user's contacts. The user may never see that line, but the model processes it all the same. If the system is overly trusting and over-permissioned, an innocent-looking message becomes a real action.

Security teams are shifting toward seeing LLMs as systems that can be fooled through wording alone, not only through code flaws. The UK National Cyber Security Centre points out that prompt injection differs from SQL injection because an LLM keeps no strict boundary between instructions and untrusted data.

The sound response is layered defence:

• Restrict tool permissions as far as possible.
• Keep reading tools and writing tools apart.
• Require approval before sensitive actions.
• Treat everything retrieved, whether web pages, emails, documents or database fields, as untrusted.
• Check every tool argument and sanitise outputs before passing them to other systems.
• Use allowlists, log every tool call and watch for unusual activity.
• Test with adversarial examples and build ways to undo actions where possible.

Give an agent only as much power as the workflow truly requires.

Seeing what the agent did

Agentic software needs even richer records than ordinary software, because one run can include model reasoning, tool calls, handoffs, guardrail checks, retries and a final result. Tracing lets developers follow the whole path from request to outcome. According to the tracing documentation for OpenAI's Agents SDK, traces can capture LLM generations, tool calls, handoffs, guardrails and custom events, helping teams debug, visualise and monitor workflows in development and production.

That matters for quality and for safety. When an agent gives a wrong answer, the cause has to be found. Did it pick the wrong tool? Did the tool return stale data? Did the model misread the description? Did a guardrail fail? Did the user lack permission? Did the agent stop too early? Without traces, teams are guessing. With good observability, building agents becomes a genuine engineering practice.

How these systems usually fail

Failures are predictable. On the model side, it may choose the wrong tool when names or descriptions are unclear, send incomplete or incorrect arguments, call a tool when it should ask a clarifying question, or skip a call when fresh data is needed. It may call tools too often, which raises cost and latency, loop on repeated calls without progress, or trust a tool's output more than it deserves.

The application can fail as well. It may accept model-supplied arguments without validation, expose too many tools at once, return huge messy outputs that confuse the model, swallow useful error messages, misattach results to the calls that produced them, or lack audit logs, rate limits and approval gates.

Prompt tweaks rarely fix these. The remedy is better tool design, clearer schemas, tighter permissions, sounder state handling, more testing and better monitoring.

When to skip tools

Function calling is not always warranted. If a task only needs an explanation, a tool adds complication. If the needed information is already in the prompt and does not change, there is nothing to fetch. For high-risk actions that cannot be safely verified or reversed, full automation may be the wrong choice. And if a tool's output is unreliable, undocumented or insecure, wiring it to an agent amplifies the trouble.

User experience pays a price too. Tool calls add delay, permission prompts interrupt flow, and elaborate agents can feel unpredictable. Sometimes a plain form beats a chat workflow, especially when users know what they want and need speed, consistency or compliance.

The goal is not to make everything agentic. Use a tool only where language, context and action genuinely meet.

Habits for building well

Begin with a handful of unambiguous tools and widen access to the model only gradually. Pick narrow functions with straightforward names. Write descriptions for the model, not only for engineers. Use strict schemas where possible and always validate inputs in your own code. Keep outputs short and pass the model only what it actually needs.

Set permissions tool by tool. A support agent who can check order status does not automatically need to issue refunds. A scheduling assistant might need calendar availability but not private event notes. A coding assistant ought to be able to read a repository well before it may open pull requests.

Require a person to sign off on anything sensitive, expensive, public, legally binding, financial or tough to undo, and make the request specific so the reviewer sees exactly what will happen.