Tool calling, from first principles

Tool calling is what turns a language model into an agent. Without it, a model can only talk about the world. With it, the model can look things up and take actions. The mechanism is simpler than it sounds, and understanding it makes you better at building on top of it.

A model cannot call anything

A model produces text. It has no network access and runs no code. “Calling a tool” means the model produces a structured request, and some other system executes it.

The exchange, step by step

1. You describe the tools. Each has a name, a description and an input schema.
2. The model reads the task and the tools. It decides whether answering requires one.
3. The model emits a tool call: the tool’s name and arguments, as structured data.
4. The executor runs it. It calls the real API with real credentials and gets a result.
5. The result goes back to the model as new context.
6. The model continues: it calls another tool, or writes the final answer.

What a tool call looks like

Illustrative shape:

{
  "tool": "customer_context",
  "arguments": { "customer": "acme.com" }
}

Nothing in it says how to reach a CRM or which credentials to use. That is the executor’s job.

Everything the executor has to do

• validate the arguments,
• find the right user’s credentials, and refresh them if they expired,
• call the provider’s API correctly,
• shape the response so it does not flood the model’s context,
• handle the case where the user never connected the account,
• repeat for every call, until the model is done.

This is the part most teams end up building by hand, and rebuilding for every new service.

Where Agent200 sits

Inside a run() request, Agent200 is the executor. It gives the model the definitions of the tools you allowed, runs each call through the right connector or workflow for the user you named, returns the result to the model and keeps the loop going until the answer is ready. You send one request and receive one result.

Three things worth remembering

• Available is not called. Listing a tool gives the model the option; it decides during execution whether to use it.
• Descriptions are the interface. The model chooses from the name and description, so write them carefully.
• Results are context. Every result takes space in the window; compact results leave room for reasoning.

Go deeper with Inside run() and writing tool descriptions.