How tools work in AI agents: from function to tool call

Who this is for, and what you will be able to do

This guide is for readers who already know what an agent is and want to see how a tool actually connects to a language model. By the end you should be able to write a typed Python tool, generate its description automatically with a decorator, and follow the full path from the model's text output to the tool running.

What a tool is

A tool is a function given to the LLM, and it should have a clear objective^[1]. Commonly used tools include web search for up-to-date information, image generation, retrieval from an external source, and API interfaces to services such as GitHub, YouTube and Spotify^[1].

Tools matter because an LLM's knowledge stops at its training data. An agent that needs current information has to get it through a tool. Asked for today's weather without a search tool, a model may invent an answer^[1].

A tool should contain a textual description of what it does, a callable that performs the action, arguments with type annotations, and optionally outputs with type annotations^[1].

How a model "calls" a tool

An LLM can only receive text and produce text, so it cannot call a tool by itself. Providing tools means teaching the model that they exist and instructing it to generate text-based invocations when they are needed^[1].

Suppose a user asks about the weather in Paris. The model recognizes that a weather tool applies, and it generates text that represents the call, such as call weather_tool('Paris'). The agent reads that text, runs the tool on the model's behalf, and gets the real data^[1].

These tool-calling steps are usually hidden from the user. The agent appends them to the conversation as a new message and passes the updated conversation back to the model, which writes a natural-sounding reply. From the user's side it looks as if the model used the tool directly, but the agent handled the whole execution in the background^[1].

The tool descriptions are given to the model through the system prompt, which holds a textual description of each available tool^[1]. The descriptions must be precise. They have to say what the tool does and what exact inputs it expects. Computer languages or JSON are common formats, but any precise and consistent format works^[1].

Start with a calculator

A simplified calculator tool that multiplies two integers can be written in Python like this^[1]:

def calculator(a: int, b: int) -> int:
    """Multiply two integers."""
    return a * b

The description the model needs is: Tool Name: calculator, Description: Multiply two integers., Arguments: a: int, b: int, Outputs: int. Writing such descriptions by hand is fragile. Every new tool has to follow the same format, and small details are easy to miss^[1].

Generate the description with a decorator

A better approach is to let Python read the code. A function with type hints, a docstring and a clear name can be turned into a tool with a decorator that builds the description automatically^[1]:

@tool
def calculator(a: int, b: int) -> int:
    """Multiply two integers."""
    return a * b

print(calculator.to_string())

The decorator uses Python's inspect module to read the function signature. It takes the docstring as the description and the function name as the tool name^[1]. The output of to_string() is identical to the description written by hand^[1].

A generic Tool class holds a name, a description, the function, the arguments and the outputs, and adds __call__ and to_string() methods. It is an example implementation, but it closely resembles what most libraries do^[1]. The generated description is injected into the system prompt^[1].

Standardizing tools with MCP

The Model Context Protocol (MCP) is an open protocol that standardizes how applications provide tools to LLMs. Any framework that implements MCP can use the tools defined in the protocol, so each framework does not need its own tool interface^[1].

MCP offers a growing list of pre-built integrations, the flexibility to switch between LLM providers and vendors, and best practices for securing data within your infrastructure^[1].

Actions: how an agent engages with its environment

An action is a concrete step an agent takes to interact with its environment, such as browsing the web or controlling a physical device^[2]. Actions fall into four types: information gathering, tool usage, environment interaction and communication^[2].

Agents differ in how they express actions^[2]:

• A JSON agent specifies the action in JSON.
• A code agent writes a code block that is interpreted externally.
• A function-calling agent is a subcategory of the JSON agent, fine-tuned to generate a new message for each action.

Stop and parse

A key method for implementing actions is stop and parse, which has three steps^[2]:

1. The model outputs the action in a predetermined format, either JSON or code.
2. Once the action is complete, the model stops generating tokens.
3. An external parser reads the action, determines which tool to call and extracts the parameters.

The model must stop after a complete action so that control returns to the agent and the output can be parsed^[2]. A weather request might produce an action like this:

{
  "action": "get_weather",
  "action_input": {"location": "New York"}
}

A framework can parse this easily to get the function name and its arguments^[2].

Code agents

A code agent generates executable code, typically Python, instead of a simple JSON object. Code can express loops, conditionals and nested functions, its functions and modules can be reused across actions, errors are often easier to debug, and it can integrate directly with external libraries and APIs^[2].

Running LLM-generated code carries security risks, from prompt injection to executing harmful code. Frameworks such as smolagents include default safeguards, and they are the recommended choice^[2].

Next steps

Build a small project with two or three tools. Walk through the whole cycle once: write a function, add the decorator, check the generated description, let the model call the tool, and parse and run the result. After that, consider whether MCP servers can supply some of those tools.

Adapted from unit 1 of Hugging Face's open-source *Agents Course*^[1][2], released under the Apache-2.0 License.