Tool Use and Function Calling

What Is a Tool?

In everyday life, a tool is anything that extends what you can do with your hands. A calculator does math faster than you can. A phone lets you talk to someone across the world. A map tells you where you are. For an AI agent, a tool is the same idea: any function or API the agent can call to get information or take action that it cannot do by generating text alone.

Common agent tools include: web search (get current information), a calculator (do arithmetic accurately), a calendar API (read and write events), a database query (look up records), an email API (send messages), and a file reader (process documents). The agent's language model decides which tool to call and with what arguments. The tool runs, returns a result, and the model reads the result and continues.

How Function Calling Works

You describe each tool to the model using a structured specification, usually in JSON. The specification says: here is the tool's name, here is what it does, and here are the parameters it accepts. When the model decides to use the tool, it outputs a structured call that matches the specification. Your system intercepts that call, runs the real function, and feeds the result back into the model's context.

Here is what a simple tool specification looks like:

When the model wants to search, it outputs something like: call search_web with query "quarterly earnings Apple 2026." Your code catches that, runs the actual web search, and returns the results. The model reads the results and decides what to do next.

Toolformer: Teaching Models to Use Tools on Their Own

In early 2023, researchers at Meta AI published Toolformer, a method for training language models to decide on their own when and how to call tools. Before Toolformer, tool use had to be explicitly programmed in: the model was told which tool to call in which situation. Toolformer showed that models could learn this from examples (Schick et al., arXiv:2302.04761).

The key idea was self-supervised fine-tuning. The researchers generated a dataset of tool calls that actually helped the model answer questions, then filtered out the ones that did not improve the answer, then fine-tuned the model on the filtered examples. The resulting model could call a calculator when it needed math, a search engine when it needed current facts, and a calendar when it needed dates, all without being told which tool to use for each question.

Three Categories of Tools

Read tools let the agent gather information without changing anything. Examples: web search, database lookup, file reader, calendar query, weather API, stock price feed. These are low-risk because they do not modify any external system.

Write tools let the agent create or modify things in the world. Examples: send email, create a document, update a database record, submit a form, post to a calendar. These carry more risk because their effects are real and may be hard to reverse.

Code execution tools let the agent write and run code. Examples: Python interpreter, SQL runner, JavaScript sandbox. These are the most powerful and the most risky, because the agent can potentially do anything the execution environment allows.

How the Agent Chooses Which Tool to Call

The agent does not have a lookup table that says "if the question is about the weather, call weather_api." Instead, the model reads the tool descriptions you provided and matches the current task to the tool that fits. This is why good tool descriptions matter: if your description of a tool is vague, the model may call the wrong one or skip a useful one entirely.

Good tool descriptions are specific about what the tool returns. Instead of "gets information," write "searches the web using Google and returns the top 5 results with title, URL, and a one-sentence summary of each." That level of specificity helps the model decide whether the tool is right for the current step.

A Second Analogy: The Plugin System

A useful way to think about function calling is the plugin system in modern software. A base application (say, a spreadsheet program) cannot do everything out of the box. But you can install plugins that extend it: a currency converter, a chart renderer, a data importer. Each plugin has a defined interface: here are the functions it exposes, and here are the arguments those functions accept.

Function calling works the same way. The base language model is the application. The tools are the plugins. The JSON schema is the plugin interface definition. When the model wants to use a plugin, it calls it by name with the right arguments. The plugin runs, returns a result, and the model reads that result to continue its work. The model does not need to know how the plugin works internally, only what it does and what it expects as input.

This analogy also clarifies why tool descriptions matter so much. If a plugin has a vague description, you do not know when to use it or what it will return. The same is true for agent tools. A description like "does email stuff" is useless. "Sends a plain-text email from the authenticated sender account. Returns success or a delivery error message" tells the model exactly when to reach for this tool and what to expect back.

A Finance Example: Trade Settlement

A financial services firm processes securities trades that require settlement, meaning the transfer of securities and cash between counterparties. A settlement agent might have access to these tools: a trade-lookup API (read), a counterparty-record API (read), a settlement-status API (read), a nostro-balance API (read), a settlement-instruction writer (write), and an exception-flag tool (write). During a task, the agent reads the trade details, checks counterparty records, verifies balance availability, and either submits settlement instructions or flags the trade for a human reviewer if a discrepancy is found. Each of those tool calls is explicit, logged, and auditable. That auditability is one of the main reasons regulated industries are drawn to function-calling architectures over less structured approaches: you always know exactly which tools the agent called and with what arguments.

import json, openai

# Step 1: Define the tool schema
tools = [{
    "type": "function",
    "function": {
        "name": "get_stock_price",
        "description": "Get the current price of a stock by ticker symbol. "
                       "Returns a float representing the price in USD.",
        "parameters": {
            "type": "object",
            "properties": {
                "ticker": {
                    "type": "string",
                    "description": "The stock ticker, e.g. AAPL or MSFT"
                }
            },
            "required": ["ticker"]
        }
    }
}]

# Step 2: Let the model decide to call the tool
response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[{"role": "user",
               "content": "What is Apple's stock price right now?"}],
    tools=tools,
    tool_choice="auto"
)

# Step 3: Parse the tool call from the response
msg = response.choices[0].message
if msg.tool_calls:
    call = msg.tool_calls[0]
    args = json.loads(call.function.arguments)
    # args == {"ticker": "AAPL"}

    result = fetch_stock_price(args["ticker"])  # your real function

    # Step 4: Return the result to the model
    follow_up = openai.chat.completions.create(
        model="gpt-4o",
        messages=[
            {"role": "user", "content": "What is Apple's stock price?"},
            msg,
            {"role": "tool", "tool_call_id": call.id,
             "content": str(result)}
        ]
    )
    print(follow_up.choices[0].message.content)