Giving a model tools

AI Foundations covered a plain model's limits: it answers from patterns learned during training, frozen at a knowledge cutoff, with no live lookup unless something else steps in. That "something else" is a tool.

A tool is a function the model can call. Not a metaphor: an actual piece of code you write and connect to the model, like a web search function, a calculator, or a function that reads a file. The model does not run this code itself. It asks for the tool to run, and your program does the running.

What changes when a model has tools

• It can pull in information past its knowledge cutoff, like today's date or a live price.
• It can get an exact answer instead of an estimated one, like a calculation.
• It can read or write real data, like a file on your machine or a row in a database.
• It can trigger a real action outside the conversation, like sending an email or creating a ticket.

The model does not automatically know which functions exist in your program. You describe each tool to it: a name, a plain description of what it does, and the inputs it needs. The model reads that description and decides, on its own, when calling the tool would help.

The three parts of a tool definition

• Name: a short, machine-friendly identifier, like get_weather.
• Description: a plain sentence explaining what the tool does and when to use it.
• Input schema: the exact inputs the tool needs, with their names and types.

{
  "name": "get_weather",
  "description": "Get the current weather for a city. Use this when the user asks about today's weather or current conditions.",
  "input_schema": {
    "type": "object",
    "properties": {
      "city": { "type": "string", "description": "City name, e.g. 'Austin' or 'Tokyo'" },
      "unit": { "type": "string", "enum": ["celsius", "fahrenheit"] }
    },
    "required": ["city"]
  }
}

The description is what the model reads

The model never sees your function's actual code. All it has is the name, the description, and the schema. A vague description, like "weather tool", leaves the model unable to tell when to use it or what to pass in. A specific one, like the example above, gets called at the right moment with the right input.

• Say what the tool does, and say when to use it, not just its name.
• Name every input and say what format it expects.
• Keep the description in plain language, the same way you would explain the tool to a new teammate.

Defining a tool is only half the picture. Once the model can see a tool, using it follows a loop, with your code sitting in the middle, not the model acting alone.

A worked example

1. 1You ask: "What is 4,821 times 37?"
2. 2Instead of guessing, the model responds with a tool call: { "a": 4821, "b": 37, "op": "multiply" }.
3. 3Your code runs the real multiplication and returns 178377.
4. 4The model reads 178377 and replies with the answer, exact instead of estimated.

The loop can repeat. A model can call one tool, look at the result, then call a second tool before it ever writes a reply to you. Each round trip, model asks, code runs, result returns, is one turn of the loop.

Most tool use in practice comes down to a short list of categories. You do not need to invent something exotic. You need to recognize which gap in the model's plain-text ability you are trying to close.

When to add a tool

• Add a tool when the model would otherwise have to guess at something you can look up or compute exactly.
• Add a tool when the task needs information from after the knowledge cutoff.
• Add a tool when the task needs to touch something outside the conversation: a file, a database, an external service.
• Do not add a tool just because you can. Every tool is another thing the model might call wrong, and another thing you have to secure.

The safety angle

A plain model can only produce text; the worst it can do is say something wrong. A model with tools can touch real things: delete a file, send a message, spend money, change a database row. That is the entire point, and it is also the risk. Give a tool only the access it needs, read-only where possible, and put a human or a permission check in front of anything that cannot be undone.