Function calling and tool use

The model never runs anything. It writes down what it would like called, and your code decides what happens next.

Part of the Getting good answers track on lAItest.

A model asked to check the weather does not check the weather. It writes a request and stops.

Then it is your turn.

The loop, in four steps.

You send the question plus a list of tools, each with a name, a description and a schema for its arguments. The model either answers or emits a structured call naming one tool and its arguments. Your code runs it, because the model cannot. You send the result back as another message. The model carries on with that result in its input. Repeat until it stops asking.

A common misconception

Commonly believed: The model has access to my database and my APIs.

Actually: It has access to text you chose to send it. Every tool call is a request your code is free to refuse, log, sanitise or route to a human. That gap is also the security boundary: a model that has read a hostile web page can be talked into asking for a call you would never have wanted, and your code is the only thing standing there.

The description is the interface.

The model chooses a tool by reading its name, its description and its argument schema, and nothing else. A vague description produces wrong calls, and the fix is almost always a better description rather than a cleverer prompt. Strict schemas from the previous lesson are what make the arguments themselves trustworthy.

A model returns a tool call for delete_account with an admin id in the arguments. What has happened?

Answer: Nothing yet — a tool call is text until your code runs it. A tool call is a structured message, not an action. Whatever it names, nothing happens until your code chooses to execute it. That gap is where authorisation, logging and human approval belong, and it does not exist unless you build it.

In one sentence

Tool use does not give a model hands. It gives it a way to ask, and your code is still the thing that acts.