Module 1 · Lesson 1 of 8

Imagine asking an AI assistant to help organize a small community event. You have 40 guests, a Saturday afternoon in mind, and a budget of $2,000.

The assistant can immediately suggest a checklist. But a checklist does not tell you which halls are available. To find that out, the system needs a way to reach information outside the conversation.

A tool is a capability the software exposes

A tool is an operation the surrounding software makes available to the model. It might search a venue directory, read a calendar, calculate a total, or create a reservation.

Think of the difference between knowing how to use a phone and actually having access to one. A language model can describe checking availability. A calendar tool gives the system a way to perform that check.

What a tool call contains

The model needs a description of the tool and the information it accepts. For a venue check, that could be a venue identifier, a date, and the number of guests.

Tool: check_availability
Venue: Riverside Hall
Date: the requested Saturday
Guests: 40

Result:
Available: yes
Capacity: 60
Hire price: $800

This is an illustrative record, not executable code. In a real application, these fields usually follow a defined data format. The software can reject a request if a required field is missing or the user lacks permission.

A request is different from a result

If the model produces the words “Riverside Hall is booked,” that does not establish that a reservation exists. The booking service must accept the request and return a confirmation. The application should use that result as evidence.

It is also useful to separate tools that read information from tools that change something. Comparing prices and paying a deposit have different consequences. Our event assistant can research freely within its permissions, while the booking step waits for the organizer's approval.

Good tools make the task easier to perform correctly

A tool called “do_everything” leaves too much unclear. A tool called “check_venue_availability” with a description of its inputs and results is easier to use and test.

A useful result also says what went wrong. “The venue directory is unavailable” means something different from “No venues match these dates.” One suggests a technical retry; the other suggests changing the search.

A tool gives the system a capability. It does not decide the whole plan. We still need a process for using the result and choosing what happens next.

For the underlying workflow and tool-interface concepts, see Building effective agents.