What tool calling actually is

Tool calling sounds like the model reaching out and doing something. It is not. Understanding the real mechanism makes both debugging and security straightforward.

The mechanism

You give the model a list of tools. Each one is a name, a description, and a schema for its arguments:

{
  "name": "read_file",
  "description": "Read the contents of a file at the given path",
  "input_schema": {
    "type": "object",
    "properties": { "path": { "type": "string" } },
    "required": ["path"]
  }
}

When the model decides a tool would help, it emits a structured request: read_file with path set to src/index.ts.

The harness receives that, runs the actual function, and puts the result back into the conversation. The model reads the result and continues.

The model never executes anything

This is the part worth internalising. The model produces a request. Something else decides whether to honour it.

That gap is where every safety control lives. Permissions, approval prompts, and sandboxes all sit between the request and the execution. Without the gap there would be nowhere to put them.

It also means a "dangerous" model output is inert on its own. The danger is always in what the harness is willing to run.

Why descriptions matter so much

The model chooses tools using the name and description alone. It cannot experiment.

A tool described as "Search" will be called for everything. A tool described as "Search the project's source files by regular expression, returning matching lines with line numbers" gets called when that is genuinely the right move.

Bad tool descriptions produce agents that look stupid. Usually the model is fine and the menu is unreadable.

Everything counts against the context

Each tool contributes its full definition to every request. Schemas are verbose, especially with nested objects and long enums.

Ten tools might be a few thousand tokens on every single turn. This is why connecting every MCP server you have heard of is a bad default.

What goes wrong

Wrong arguments. The model guesses a parameter shape from a vague schema. Fix the schema, not the prompt.

Right tool, wrong moment. Usually a description that does not say when to use it.

Loops. The tool fails, the model retries identically, forever. Error messages that say what to do differently break the cycle: "path not found, list the directory first" is far better than "ENOENT".

Where MCP comes in

Every harness invented its own way of defining tools, so a tool built for one did not work in another. MCP is the standard that fixes that. It is covered next in MCP explained.