How AI Agents Use Tools: Function Calling Explained

AI agents use tools through function calling: the model is given a list of functions it may request, it replies with the name of a function and the arguments to pass, and your own software runs that function and returns the result. The model never touches your systems directly. It only asks, and your code decides whether and how to act.

Key takeaways

• A tool is a function your engineers write and describe to the model with a name, a description and a parameter schema.
• The model outputs a structured request to call a tool. Your application executes it. This separation is where control lives.
• The quality of tool names, descriptions and results has a large effect on how well an agent performs.
• Every tool call should be validated and permission-checked in code, because the model can ask for the wrong thing.
• Read tools are low risk. Write tools need tighter limits, and sensitive ones need human approval.

Why models need tools at all

A language model on its own can only produce text from what it learned in training and what is in the current conversation. It does not know today's stock level, your customer's balance or whether an order shipped. It also cannot do anything: it cannot send an email or update a record.

Tools close both gaps. A read tool gives the model live facts. A write tool lets it cause an effect. An agent is, in practical terms, a model with tools and a loop. Without tools you have a chatbot that knows only what it was told.

How function calling works, step by step

The sequence is the same across the major model providers, including OpenAI, Anthropic and Google, although the exact format differs.

1. You define the tools. For each one you provide a name, a plain-language description and a schema that lists the parameters and their types.
2. You send the request. The model receives the instructions, the user's message or task, and the tool definitions.
3. The model decides. It either answers directly or returns a tool call: the tool name and a set of arguments in a structured format, normally JSON.
4. Your code runs the tool. The application checks the arguments, calls the real system and collects the result.
5. You return the result. The result is sent back to the model as part of the conversation.
6. The model continues. It reads the result and either calls another tool or writes its final answer.

Steps three to six repeat until the task is complete. That repetition is the agent loop.

A small example

Suppose a customer writes: "Where is my order 4471?" The agent has a tool called get_order_status that takes an order_number. The model returns a request to call get_order_status with order_number set to 4471. Your code queries the order system and returns something like: status shipped, carrier name, expected delivery date. The model then writes: "Your order has shipped and is expected on Thursday."

The model did not query your database. It produced a request, and code you control did the query. If the customer had asked about someone else's order, your code is the place that refuses.

What a tool definition contains

A tool definition has three parts, and each one matters.

• Name. Short and specific, such as search_products or create_draft_invoice. Names that say what the tool does help the model choose correctly.
• Description. The most important part. It should say what the tool does, when to use it, when not to use it, and what it returns. Write it as you would explain the tool to a new colleague.
• Parameters. Each input with its type, whether it is required, the allowed values and a short description. "Date in YYYY-MM-DD format" prevents many errors.

The model reads these definitions every time it decides what to do. A vague description such as "gets data" forces it to guess. Much of the work of improving an agent is rewriting tool descriptions after reading failed runs.

Types of tools

Type	Examples	Risk	Typical control
Read	Look up a customer, search documents, check stock	Low, mainly data exposure	Limit which records and fields are visible
Compute	Calculate a total, convert units, run a query	Low	Do the maths in code, not in the model
Write, reversible	Create a draft, add a note, apply a label	Medium	Validate inputs, log the action
Write, hard to undo	Send an email, confirm an order, issue a refund	High	Human approval before execution
Handover	Escalate to a person, ask the user a question	Low	Always available to the agent

The handover tool deserves attention. An agent that has no way to say "I cannot complete this" will try to complete it anyway. Giving it an explicit escalation tool, and telling it when to use it, is one of the cheapest safety measures available.

How to design tools that agents use well

The following practices come from building and debugging these systems.

• Design around tasks, not around your API. A system might need three API calls to find an order by customer email. Wrap them into one tool, find_orders_by_email, so the model does not have to chain them.
• Keep the list short. Every extra tool is one more option to get wrong. Give each agent only the tools its job needs.
• Return compact, readable results. Send back the fields that matter, with clear labels. Do not return hundreds of raw rows.
• Make errors instructive. "Order number must be numeric. You passed 'ORD-4471'" lets the model correct itself on the next step.
• Make writes safe to repeat. If the agent retries after a timeout, the tool should not create a second order. Use a unique reference to detect duplicates.

Where control belongs

The model's request is a suggestion, not a command. Treat it the way you would treat input from a web form: useful, but not trusted. Before any tool runs, your code should check four things.

1. Is the request well formed? Do the arguments match the schema and the allowed values?
2. Is it permitted? Does the user or process behind this run have the right to see or change this record?
3. Is it within limits? Is the amount, quantity or number of recipients inside the bounds you set?
4. Does it need approval? If yes, pause and ask a person before executing.

These checks matter because models can be misled. Text inside an email or a document can contain instructions aimed at the agent, a problem known as prompt injection. If the checks live in code, a manipulated model still cannot go beyond what the code allows. We cover this further in AI agent guardrails.

Standard connectors and MCP

Writing a custom tool for every system takes time. The Model Context Protocol, or MCP, is an open standard that defines a common way for AI applications to connect to tools and data sources. A system that offers an MCP server can be connected to compatible AI applications without a new custom integration each time. The underlying idea is unchanged: the model requests, and software executes under your rules.

Related guides

• Multi-Agent Systems Explained: When One AI Agent Is Not Enough
• 12 AI Agent Use Cases That Actually Work for Small Businesses
• AI Agent Guardrails: Keeping Agents Safe in Production
• How to Build an AI Agent: From Idea to Production
• Service: AI Call Agents

Frequently asked questions

Is function calling the same as tool use?

Yes. Providers use both terms for the same mechanism: the model returns a structured request to call a function you defined. "Tool use" and "tool calling" are the more general names.

Can the model call a tool that I did not define?

It can only produce valid calls for the tools you supplied in that request. On rare occasions a model may invent a tool name or a parameter, which is another reason your code validates every call and rejects anything unknown.

Does the model see my whole database?

No. It sees only what your tools return for the specific calls it makes. You decide which fields are exposed, so sensitive data can be left out entirely.

Sources and further reading

Primary documentation and research behind this guide.

• OpenAI: Function calling guide
• Anthropic: Tool use overview
• OpenAI: Structured outputs guide

Tools are where an agent becomes useful and where it becomes safe or unsafe. At Growmerz, tool design is a core part of every custom AI agent build. To talk through which actions an agent could take in your systems, book a free AI audit.