Part 2 of 4 · ~7 min read

Tools & Function Calling

How agents interact with the real world — and why the toolbox you give them matters more than you think.

Brain with no hands is just thoughts in the air,
Give it the tools, now it's going somewhere.
You design the box, you control the play —
No delete button means nothing gets thrown away.

I Giving Agents Hands

In Part 1, we learned agents work in a loop: think, act, observe, repeat. But how does the "act" step actually work?

The LLM never actually does anything. It can't call an API, query a database, or send an email. All it can do is generate text. So the answer is function calling(also called "tool use"): instead of plain text, the LLM outputs a structured request — "I'd like to call this function with these parameters." Your code executes the function and feeds the result back. The LLM is the brain. Your code is the hands. Without your code, it's a very articulate quadriplegic.

Key Insight
You control the agent's capabilities entirely.An agent can only do what you give it tools to do. No tools for deleting data? The agent can't delete data — no matter what a user asks. This is a powerful product design lever.

II Anatomy of a Tool

A tool is a function description included in the system prompt. It tells the LLM: "here's something you can do, here's what it's called, here's what inputs you need."

Four key parts:

  1. Name — A clear identifier like search_flights. The LLM uses this to decide which tool to call.
  2. Description — Natural language explaining what it does and when to use it. A vague description leads to wrong calls at wrong times.
  3. Parameters — Inputs with types and descriptions: destination (string, required), max_price (number, optional).
  4. Returns — What comes back. The LLM needs this to interpret results.

Explore a real tool definition below:

Interactive
Anatomy of a Tool
Click on any highlighted section to learn what it does and why it matters.
{
  "name": "search_flights",
  "description": "Search for available flights between two airports. Use this when the user wants to find, compare, or book flights.",
  "parameters": {
    "type": "object",
    "properties": {
      "origin":      { "type": "string", "description": "Departure airport code (e.g. JFK)" },
      "destination":  { "type": "string", "description": "Arrival airport code (e.g. LHR)" },
      "date":        { "type": "string", "description": "Travel date in YYYY-MM-DD format" },
      "max_price":   { "type": "number", "description": "Maximum price in USD (optional)" },
      "cabin_class": { "type": "string", "enum": ["economy","business","first"], "description": "Preferred cabin class (optional)" }
    },
    "required": ["origin", "destination", "date"]
  },
  "returns": "Array of flight objects with airline, departure_time, arrival_time, price, and stops"
}
Click any section above
Each part of a tool definition serves a specific purpose. Click to explore.
Analogy
Writing tool descriptions is like writing a brief for a new hire who reads instructions extremely literally. Say "search for flights" and they'll search. Forget to say "only search when the user asks about travel" and they'll search flights when someone asks about the weather.

III The Protocol

The function calling protocol has a simple rhythm:

  1. You define tools— Your app sends tool definitions along with the user's message.
  2. The LLM decides — It outputs either plain text or a structured tool_call with function name and arguments.
  3. Your code executes — Your app runs the function (hits the API, queries the DB) and gets the result.
  4. Results go back — The tool result goes to the LLM, which decides what to do next.

The LLM never sees your API keys, never touches your database, never executes code directly. It only expresses intent. Your code handles execution. This is a critical security boundary.

Walk through the exact message exchange:

Walkthrough
The Function Calling Protocol
Step through the exact exchange between your app, the LLM, and the tool. Notice who sends what.
Ready—Step 0 of 8
Press "Next Step" to see the protocol in action.

The entire protocol, and it's the same pattern across every AI provider. The mental model you just built applies everywhere.

IV Designing Good Tools

The tools you design directly determine what your agent can do, how reliably it does it, and how often it makes mistakes. Giving a powerful model poorly designed tools is like hiring a Michelin-star chef and giving them a spork.

Three principles for designing effective tools:

Principle 1: Do one thing well.Each tool should have a single, clear purpose. Don't build a manage_calendar tool that creates, updates, deletes, and searches events. Build create_event, update_event, delete_event, and search_eventsseparately. Anthropic's internal mantra for this is "thin harness, fat skills" — keep the orchestration logic minimal and put the real intelligence inside each individual tool. The LLM makes better decisions when tools are specific.

Principle 2: Name and describe for the LLM, not just for humans. The model reads your tool names and descriptions to decide what to call. update_crm is ambiguous — update what? update_contact_email is clear. The description should say whento use it, not just what it does: "Use this when the user wants to change a contact's email address in the CRM."

Principle 3: Constrain inputs. Use enums instead of free text when possible. Instead of cabin_class: string, use cabin_class: enum["economy", "business", "first"]. This prevents the LLM from inventing invalid values like "premium" or "standard." Required vs. optional parameters also guide the model on what it must collect before calling the tool.

Builder Tip
Review your tool descriptions the way you'd review landing page copy. Every word shapes behavior. A/B test descriptions against real queries — you'll be surprised how much a single sentence change affects call accuracy.

See how tool design affects agent behavior in the demo below:

Experiment
Build Your Toolbox
Toggle tools on and off, then ask the agent a question. See how its approach changes based on what's available.
User request: "Book me a flight from NYC to London next Friday under $500, and add it to my calendar."

Notice how the agent adapts. With the right tools, it executes the full task. Remove a critical tool, and it gracefully degrades. Add too many, and it becomes the overachieving intern who CC's the entire company on a routine email — technically thorough, practically obnoxious.

This is why tool design is a product decision, not just an engineering one.The tools you expose define the boundaries of what your agent can do. And it's not theoretical — Anthropic's own data shows roughly 50% of all agentic tool calls in the wild are software-engineering tasks (file edits, terminal commands, code search), where tools are naturally well-defined and outputs are machine-checkable. Domains with fuzzier tool boundaries lag far behind.

V The Toolbox Problem

It seems intuitive: more tools should make an agent more capable. But in practice, there's a sharp tradeoff. As you add more tools, three things break down:

ProblemWhat HappensExample
Selection accuracy dropsThe LLM confuses similar tools or picks the wrong one5 tools: 97% accuracy. 50 tools: below 60%
Prompt size growsEvery tool eats context tokens, crowding out conversation and reasoning50 tool definitions can eat 7,500+ tokens of prompt before the user says a word
Latency increasesLarger prompts take longer to process; the agent slows downEach tool adds ~50ms; 50 tools add 2.5s per call

Every tool you add has a cost — not just in engineering effort, but in reliability.

Explore the tradeoff below:

Explore the tradeoff
The Toolbox Dilemma
Drag the slider to add more tools and watch how it affects accuracy, latency, and prompt usage.
5
Tool Selection Accuracy
94%
Prompt Tokens Used by Tools
9%
Response Latency
1.1s
5 tools — this is the sweet spot for most agents. High accuracy, low overhead.
Summary
Start small with 3-5 tools. Measure accuracy, then expand one tool at a time based on real user needs — not hypothetical ones. Most production agents work best with 5-15 well-designed tools. If you need dozens, use tool routing: a lightweight classifier that selects a relevant subset per request instead of dumping the entire catalog into the prompt. Boris Cherny, who leads Claude Code at Anthropic, frames this as the shift from "coding" to "directing" — the human's job is no longer to write every tool call, but to design the toolbox and validate the system's decisions.
Test your understanding
Article Recap
5 questions covering the key concepts from this article.
1 of 5

An agent calls delete_customer(id: 12345) and the customer record is removed. Who actually deleted the record?

VI What's Next

You now understand how agents interact with the world: tool definitions the LLM reads, function calls it outputs, results your code sends back. The tools you choose shape capability, reliability, and speed — making tool design a product decision, not just an engineering one.

But even with perfect tools, agents still fail. In Part 3, we'll confront the hard realities: infinite loops, wrong tool calls, hallucinated parameters. We'll build a cost model, explore failure modes, and give you a framework for when to use agents versus simpler alternatives.