Skip to main content
Large language models (LLMs) can generate fluent text, but by themselves they cannot access external systems or real-time data. They can’t check calendars, send emails, or perform web searches without being given a way to interact with those systems.
Tools enable LLMs to act on the world. When you expose a tool, the model can choose to call it, receive concrete results, and incorporate those results into its response.
A retro-style infographic titled "LLMs WITHOUT TOOLS" showing a pixelated AI icon labeled "TEXT ONLY" and red crossed-out boxes for "Check Calendar," "Send Email," and "Search Web." A large red banner reads "STUCK INSIDE TRAINING DATA" with smaller text below: "No real-time access. No external calls. Text in, text out."
What is a tool? A tool is a function your application exposes to the LLM so the model can request an action or fetch live data. The model decides when a tool is appropriate; your application executes the requested call and returns the result. This division keeps control and validation on the application side while letting the model orchestrate tasks.
A retro-style infographic titled "WHAT ARE TOOLS?" explaining that a tool is a function an LLM can call to interact with the outside world. It contrasts "No tools" (LLM can't access your calendar) with a highlighted "But with a tool..." callout.
Walkthrough: asking a calendar question
  1. You ask the LLM: “What’s on my calendar today?”
  2. The LLM recognizes it needs real-time data and opts to call a calendar tool rather than guess.
  3. The model emits a structured tool call (your app receives this request).
  4. Your application runs the corresponding function (e.g., queries a calendar API).
  5. The tool returns the events, and the LLM formats a natural-language reply.
Example — LLM tool call and the application response:
The model did not know your schedule from training data; it recognized the check_calendar tool was available, requested it, and used the returned facts to produce a helpful answer. Tool definition structure Each tool definition typically includes three parts:
  • name: the identifier the model will use to reference the tool.
  • description: a concise explanation the model reads to determine when to use the tool.
  • parameters: the inputs the tool requires (types and any constraints).
Quick reference table Example tool definition (JSON)
The LLM reads these definitions during generation and decides whether to call a tool and which one. The model generates the request; your application executes it. Common tool types Tools are ordinary functions that your application exposes. Common categories include:
  • Search tools — web search, database queries, document retrieval.
  • Calculation tools — calculators, unit converters, precise numeric computation.
  • API tools — send email, create calendar events, interact with online services.
  • File operations — read/write, save artifacts, return file contents.
  • Code execution — run Python, shell commands, or custom scripts.
A retro-style infographic titled "COMMON TOOL TYPES" showing five colored boxes labeled Search, Calculation, API Calls, File Ops, and Code Exec with brief examples. Below it reads "PERSONAL ASSISTANT USES ALL OF THESE" and lists example tasks like searching the web for restaurants and checking calendar free slots.
Important boundary: LLMs generate the call, your code executes it The model outputs a structured request (for example, Call check_calendar(date="today")) but it does not execute your code. Your application must validate and run the requested function, then return the results to the LLM. This separation is a critical safety and control boundary.
This is an important safety boundary: models should only request tool calls; your application must validate and execute them. Never allow unchecked model-initiated actions to run without application-side verification.
Links and references

Watch Video