Tool Execution Mechanics

From Prompts to Actions

A large language model is great at processing and generating text. But to build a true AI agent, the model needs to do more than just talk; it needs to act. This means interacting with the outside world, whether that's fetching live data from a website, querying a database, or sending an email.

To make this happen, we give the LLM a set of "tools" it can use. These are simply functions in your own code that the model can request to run. The magic lies in the structured conversation that allows the model to ask for a tool, get the result, and then decide what to do next. This is the first step toward building autonomous systems.

Defining the Toolkit with Schemas

An LLM can't just guess what your code does. You need to provide a clear, structured description of each tool it has access to. This is done using a schema, which acts like a user manual for the AI. The schema defines the tool's name, what it does, and what parameters it needs to run.

Two common ways to create these schemas are with standard JSON Schema or a Python library called Pydantic(). Pydantic is often preferred because it lets you define the schema using simple Python classes, which is intuitive and less error-prone.

# Using Pydantic to define a tool's arguments
from pydantic import BaseModel, Field

class GetWeather(BaseModel):
    """Get the current weather for a specific location."""
    location: str = Field(..., description="The city and state, e.g., San Francisco, CA")
    unit: str = Field("fahrenheit", description="The temperature unit, 'celsius' or 'fahrenheit'")

# Your actual function that does the work
def get_weather(location: str, unit: str = "fahrenheit") -> str:
    # ... function logic to call a weather API ...
    return f"The weather in {location} is 75 degrees {unit}."

Notice the description fields. These are critical. The LLM uses the tool's main description (the docstring) and the parameter descriptions to figure out when to use the tool and what values to pass. A clear, descriptive schema is the single most important factor for reliable tool use. The model is surprisingly good at extracting parameters from natural language, but only if your schema guides it properly.

The Tool-Use Conversation

When you enable tool use, the conversation with the model changes. Instead of just a back-and-forth of text, it becomes a multi-step cycle. The model can pause, ask your code to run a function, and then resume its thought process with new information.

Here’s how the underlying API messages work:

You send a message with role: "user" containing your prompt.
The LLM processes your prompt. If it decides to use a tool, its response message won't contain text. Instead, it will have a tool_calls object. This is a request for your code to run one or more functions.
Your code detects the tool_calls object, executes the specified function(s) with the provided arguments, and gets the results.
You send a new message back to the model for each tool call that was made. This message has role: "tool" and contains the output from your function, along with a tool_call_id to link it to the original request.
The LLM receives the tool's output, processes this new information, and finally generates a standard text response for the end user.

Handling Multiple Actions at Once

Modern LLMs are capable of (). If a user's prompt requires multiple independent pieces of information, the model can request them all in a single turn. For example, the prompt "What's the weather in San Francisco and the current stock price of Apple?" could generate two tool calls in one response message.

Your application code must be prepared to handle this. When you receive a response from the model, the tool_calls field will be a list. You should iterate through this list, execute each function call, and append a separate role: "tool" message to the conversation history for each result.

This is highly efficient. It avoids multiple round-trips to the model, reducing latency and cost. The key is that the requested actions must not depend on each other. The model is smart enough to know that it can't ask for the user's flight details before it has even found the available flights.

Mastering this call-and-response cycle is the foundation of building agentic systems. By giving an LLM a well-defined set of tools and handling its requests, you transform it from a passive text generator into an active partner capable of executing complex tasks.

Quiz Questions 1/6

What is the primary purpose of giving a "tool" to a Large Language Model (LLM)?

Quiz Questions 2/6

How does an LLM know when to use a tool and what information to provide to it?

Building Agentic AI Systems