Tools are what turn a model that can only produce text into a system that can actually do things - search the web, query a database, send a message, run code. The "act" step of the agent loop only works because tools exist, so understanding how tool calling actually functions is worth doing properly rather than treating it as a black box.
What a tool actually is, mechanically
A tool is, at minimum, three things: a name, a description, and a schema describing what arguments it expects. When you give a model a set of tools, you're not handing it working code to execute - you're handing it a menu of options described in text, and the model's job is to decide whether one of them applies and, if so, what arguments to call it with. The model outputs a structured request (tool name plus arguments); your application code is what actually executes the real function and returns the result.
The model never runs code directly - it requests a call, your application executes it, and the result comes back as the next observation.
The description is doing more work than it looks like
Because the model decides which tool to use by reading its name and description, not by inspecting its implementation, a vague or overlapping description is one of the most common reasons agents pick the wrong tool. "get_data" tells the model almost nothing; "get_customer_order_history(customer_id)" tells it exactly when to reach for it. This is the same principle covered from the server-building side in this site's MCP 101 series - whether you're exposing a tool through MCP or wiring it directly into an agent framework, the description is the interface the model actually reasons over.
Narrow tools beat broad ones
A single tool that can do many different things with different argument combinations is harder for a model to use correctly than several narrow, single-purpose tools - narrow tools reduce the space of ways to get the call wrong. This is a recurring tradeoff: fewer, broader tools mean less setup work but more room for the model to misuse them; more, narrower tools mean more upfront design work but a lower error rate in practice.
Parallel vs. sequential tool calls
Some situations call for multiple independent tool calls that don't depend on each other's results - looking up weather in three different cities, say - and many modern models can request several tool calls in a single planning step rather than looping through them one at a time. Other situations are genuinely sequential: you can't look up an order's shipping status before you've looked up which order the customer means. Whether a framework parallelizes independent calls automatically or requires you to structure the loop for it varies - worth checking explicitly rather than assuming.