Tool calls are just API wrappers, to be honest, not completely true.
Although the most common use case is to call a search engine, hit a database, or fetch a URL. That framing is too narrow, and it limits how you design agents.
At the end, a tool call is just a function call. The agent decides to invoke it, passes arguments, and gets a result back. There is nothing in that contract that says the function has to be external.
Tool calls can also be used to decompose the agent’s business logic and keep the scope of each one minimal. This is a pattern that helped me structure some agents better.
Thus, instead of one massive prompt that handles routing, validation, transformation, and decision-making all at once, you break those responsibilities into discrete tools. The agent calls them in sequence, or conditionally, based on what it needs.
To me, this is like how we structure a codebase. We do not write one 500-line function. You write small, focused functions with clear inputs and outputs, and you compose them. Tool calls give you the same leverage as an agent.
One of the biggest advantages that I got out of this is that the decision chain is super observable, and each step is testable in isolation.
Again, this does not mean it is the best way, but some use cases fit this kind of flow better, where a decomposition is possible and essential.
By the way, every tool call does add a round-trip through the model, so over-decomposing compounds latency and gives reasoning errors more places to accumulate.