Tools and function calling: giving your agent hands

# Tools and function calling: giving your agent hands

Ask a language model "What's the weather in Tokyo right now?" and it will do one of two things: guess, or admit it doesn't know. It has no window to the outside world. It can reason and write, but it can't *look things up* or *do* anything.

Tools change that. A tool is a function your agent can call: a weather lookup, a database query, a "send email" action, a calculator. You describe the tool, the model decides when to use it, and suddenly your agent has hands.

What a "tool" actually is

A tool (also called a function in this context) is a piece of code you already have, wrapped so the AI can request it.

You give the model three things:

• A name, like get_weather.
• A description in plain English: what it does and when to use it.
• The parameters it accepts, described in a structured format called JSON Schema (a standard way to spell out "this field is text, that one is a number, this one is required").

The model never runs your code. It only reads these descriptions and, when it seems useful, says: "Please call get_weather with city = Tokyo." Your program runs the real function and hands back the answer.

Here is a concrete tool definition. This format is nearly identical across OpenAI, Anthropic, and Google:

{
  "name": "get_weather",
  "description": "Get the current weather for a city. Use this whenever the user asks about weather, temperature, or conditions.",
  "parameters": {
    "type": "object",
    "properties": {
      "city": {
        "type": "string",
        "description": "The city name, e.g. 'Tokyo' or 'Paris'"
      },
      "units": {
        "type": "string",
        "enum": ["celsius", "fahrenheit"],
        "description": "Temperature units"
      }
    },
    "required": ["city"]
  }
}

Notice how much the description is doing. "Use this whenever the user asks about weather" is not decoration. It is instruction. The model reads it to decide *whether* to call the tool at all.

The request-and-response loop

Here is the core idea, and it's simpler than it sounds. You and the model take turns.

1. You send the user's message plus the list of tools available.

2. The model replies in one of two ways: a normal text answer, or a request to call a tool (with the arguments filled in).

3. If it asks for a tool, your code runs the real function and sends the result back.

4. The model reads the result and either answers the user or asks for another tool.

That loop repeats until the model has what it needs. This back-and-forth is what people mean by function calling or tool calling.

Walk through a real exchange:

• User: "Should I bring an umbrella in Tokyo today?"
• Model: (no chit-chat) "Call get_weather with city='Tokyo'."
• Your code: runs the weather APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →, gets back {"condition": "rain", "temp_c": 14}.
• You send that result back.
• Model: "Yes, bring an umbrella. It's raining in Tokyo and about 14°C."

The model made a decision (I need live data), you did the work (called the APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →), and the model turned the raw result into a helpful answer.

A vendor-neutral code sketch

The exact function names differ per provider, but the shape is always the same. Here is the loop in pseudo-Python that mirrors how every major SDK works:

tools = [get_weather_definition]   # the JSON schema from above
messages = [{"role": "user", "content": "Umbrella in Tokyo today?"}]

while True:
    response = model.generate(messages=messages, tools=tools)

    if response.wants_tool_call:
        call = response.tool_call          # e.g. get_weather(city="Tokyo")
        result = run_my_function(call.name, call.arguments)

        # feed the real result back into the conversation
        messages.append(response.as_message())
        messages.append({
            "role": "tool",
            "name": call.name,
            "content": result
        })
        continue        # loop again so the model can use the result

    # no tool needed: we have a final answer
    print(response.text)
    break

Read the loop once more. The while True is the whole trick: keep going as long as the model keeps asking for tools, then stop when it produces a plain answer. An agent that can call several tools in a row (look up a customer, then check their orders, then draft a reply) is this loop running a few more times.

If you want the underlying standard behind these JSON parameter definitions, the JSON Schema documentation is the free, canonical reference.

Good tools vs. frustrating tools

The model can only use what you describe well. Most agent failures trace back to sloppy tool definitions, not a "dumb" model.

Write descriptions like you're briefing a new hire

Vague:

> search: searches things

Clear:

> search_help_articles: Search the internal support knowledge base for articles about billing, refunds, and account settings. Returns the top 3 matching articles. Use this before answering any policy question.

The second version tells the model *what's inside*, *what it gets back*, and *when to reachreachThe number of unique people exposed to your message in a given period. Unlike impressions, reach counts each person once, no matter how often they see it.View full definition → for it*.

Keep parameters tight

Every optional parameter is a chance for the model to guess wrong. Use enum (a fixed list of allowed values) when there are only a few valid options, like ["celsius", "fahrenheit"]. Mark required fields as required. Fewer, clearer inputs mean fewer mistakes.

Return results the model can actually read

Send back clean, labeled data:

{"condition": "rain", "temp_c": 14, "city": "Tokyo"}

not a wall of raw HTML or a 500-line log. The model has to interpret whatever you return, so make it easy.

Common tools you'll actually build

Once the loop clicks, you start seeing tools everywhere. A few patterns that show up in almost every real agent:

• Retrieval: search a knowledge base, look up a document, query a database. This is how you ground an agent in *your* data.
• Actions: send an email, create a calendar event, file a support ticket, refund an order. These *change* something, so treat them carefully (more below).
• Computation: a calculator, a currency converter, a date math helper. Models are famously shaky at exact arithmetic, so handing math to a real function is a quick reliability win.
• Handoffs: calling another agent or a specialized model. In 2026 this is common: a "router" agent decides which specialist tool or sub-agent should handle a request.

Read-only vs. action tools

There's a real difference between a tool that *reads* (get weather, search articles) and one that *acts* (send email, charge a card).

Read tools are low-risk: worst case, the agent looks something up it didn't need. Action tools can do damage if the model gets it wrong. For those, add a guardrail: require human confirmation before sending, limit what the tool can touch, or log every call. A "send refund" tool should probably cap the amount and ask a person to approve anything large.

This is a design decision, not a coding detail. Decide up front which tools your agent can fire on its own and which need a human in the loop.

Where the providers fit in

Every major provider supports this same tool-calling pattern, and each ships a higher-level agent SDK (a software toolkit that runs the loop for you so you don't hand-write the while True):

• OpenAI Agents SDK
• Claude Agent SDK (Anthropic)
• Google Agent Development Kit (ADK)

They handle the plumbing: passing tools, parsing tool calls, feeding results back. The concept you just learned is the thing all three are built on. When you're ready for provider-specific syntax, see the deep-dive blocks for each vendor.

One more thing worth knowing: there's a growing open standard called the Model Context Protocol (MCP) that lets you define a tool *once* and plug it into agents from different providers. Think of it as a universal adapter for tools. By 2026 it's increasingly the default way teams share tools across systems.

Key Takeaways

• A tool is your code, described for the model. Give it a clear name, a plain-English description, and typed parameters (JSON SchemaSchemaA schema is the formal blueprint that defines how data is structured, named, typed, and related within a database, file, or message.View full definition →). The model requests the call; your code actually runs it.
• The whole engine is a loop. Send message plus tools, check if the model wants a tool, run it, feed the result back, repeat until you get a plain answer.
• Write descriptions like a briefing. State what the tool does, what it returns, and when to use it. Most agent failures come from vague tool definitions, not the model.
• Separate read tools from action tools. Anything that changes the world (send, charge, delete) needs a guardrail: confirmation, limits, or logging.
• Start with the concept, then pick an SDK. The OpenAI Agents SDK, Claude Agent SDK, and Google ADK all run this same loop for you, and MCP lets you reuse one tool across all of them.