Tools the Agent Can Call

Tools are the Agent's hands. Only when its name, purpose, input, output, and risk level are all clear will it get called correctly.

Let's think about it this way for a moment

The model doesn't see the world directly. It reads a tool's description and sends a JSON-like argument. You run the function and hand back the result. A good tool has a short name, states what it does, states what it doesn't do, and includes an example argument. A bad tool is something broad like "doAnything(query)," and the Agent ends up guessing at how to use it. Give your first Agent only 1–3 tools.

Let's connect this to everyday life

For a study helper, start with three tools — list_notes(), read_note(name), draft_summary(text). list_notes only returns names. read_note only returns text. draft_summary doesn't save anything, it just produces a draft. Add save_note later, and only behind human approval. The fewer side effects a tool has, the safer the Agent.

One tool = one job
Write out the input name and its type
Don't include write/delete tools in your first version

Let's try it out together

javascript

const tools = [
  {
    name: "list_notes",
    description: "List note file names in the study folder. Read-only.",
    input: {},
  },
  {
    name: "read_note",
    description: "Read one note by file name. Does not change files.",
    input: { name: "string" },
  },
  {
    name: "draft_summary",
    description: "Draft a 3-bullet summary. Does not save anything.",
    input: { text: "string" },
  },
];

You should see

You'll be able to write three read-only tools with clear descriptions.

5-minute try-it

Write 3 tools for your Agent. For each one, make a table with name, description, input, and whether it's read-only or write.

A quick word of caution

Don't hand out shell.run or fetch(url) as your first tool. The Agent can end up somewhere you never intended.