Tools and function calling: how agents act
The mechanism agents use to affect the world — and how to design tools they use well.
An agent that can only talk is a chatbot. What makes it an agent is tools — the ability to act: query a database, send a message, run code, call an API. The mechanism is function calling (also called tool calling), and it's identical in spirit across every model provider.
Here's the actual mechanic. You describe your tools to the model as structured definitions — a name, a description, and a JSON schema of arguments. When the model decides to act, it doesn't run anything itself; it returns a tool-use block naming the tool and the arguments. Your code executes it and returns the result. The model stays a pure reasoner; your code is the hands. This separation is important for reliability and security: nothing happens that your code didn't run.
Because the model chooses tools and fills arguments from a description, tool design is where agent quality is won or lost. Anthropic calls tools "contracts between deterministic systems and non-deterministic agents" — you must design assuming the caller may misunderstand or misuse them. The durable principles:
- Few, sharp, high-quality tools beat many overlapping ones. Every extra tool is more to confuse the model and more schema eating context. Build targeted capabilities, not a mirror of every API endpoint.
- Descriptions are prompt engineering. The description is how the model decides when and how to call the tool. Spell out what each argument means and what's valid. Anthropic's teams spend more time optimizing tool docs than the agent prompt.
- Constrain arguments with the schema — types, enums, required fields — to eliminate bad calls before they happen. (Their famous example: requiring absolute file paths killed a whole class of errors.)
- Return meaningful, token-efficient results. The model reads your return value; give it what it needs to decide the next step, not a raw dump.
- Errors are data. Return a readable error the model can recover from, not an exception that crashes the loop.
If this sounds exactly like designing MCP tools — it is. MCP is the standard way to give agents tools (our companion course builds servers in depth), and everything here applies whether you define tools inline or expose them over MCP. Invest in the tools; the agent is only as good as what you let it do, and how well you described it.
Design (don't code yet) three tools for a 'research assistant' agent. For each, write the name, a model-facing description, and the argument schema. Then critique: could two of them be merged into one sharper tool?
Enjoying the free lessons? Get an email when we publish new courses and updates — no spam, unsubscribe anytime.
Discussion (0)
Ask a question or share what worked for you. Comments are reviewed before they appear.
No comments yet. Be the first to start the discussion!