Tool calling is how a language model does something other than produce text. You describe a set of functions — their names, parameters, and purpose — and the model, when it decides a tool is needed, emits a structured call. Your code runs it and returns the result, which the model reads and continues from. It is the foundation every AI agent is built on.
Why it matters in production
This is how a model reaches past its frozen training data: to query your database, search your docs, or take an action in the world. It is also where side effects live. A tool that deletes records is one confidently-wrong model decision away from a bad day, so tool design is a safety surface, not just a feature.
The common mistake
Dumping your entire API surface into the tool list. The model has to choose the right tool from the descriptions you wrote, and a bloated, overlapping, or vaguely-described catalog produces wrong calls — the model picks updateUser when it meant getUser. Tool selection quality is mostly a function of how sharply you wrote the tool descriptions.
How we actually use it
We treat the tool catalog as a designed product: few tools, sharp descriptions, parameters the model can fill unambiguously. We wrote the discipline up in context engineering the tool catalog, and when the tools need to live behind a standard interface, we expose them via the Model Context Protocol — see inside an MCP tool server. Guardrails on destructive tools are covered under guardrails.