When an LLM "uses a tool," no code jumps from the model into your application. What happens is a structured conversation. The model is given a list of tools — each with a name, description, and JSON schema — and asked to respond either with text or with a proposed function call.
The loop
- Declare. The application tells the model which tools exist and what they expect.
- Propose. The model returns a call:
{tool: "slug", data: {...}}. It does not execute anything. - Execute. The application runs the tool with the proposed input and gets a result.
- Feed back. The result is appended to the conversation, and the model continues — revising its answer, calling another tool, or finishing.
That is the whole mechanism. The reliability of the loop depends almost entirely on two things written by humans: the tool descriptions and the schemas.
Related reading: How to Remain Valuable When Intelligence Becomes Cheap — a 224-page practical book on staying valuable as intelligence gets cheap. $3.84. Read it on Gumroad →
Where the loop breaks
- A vague description makes the model pick the wrong tool.
- A schema without required fields lets the model omit critical input.
- An inconsistent output shape makes the model misinterpret results on the next turn.
This is why the tools on this site ship with explicit inputSchema values and tight descriptions in the manifest — the schema is the contract the loop runs on. Fix the contract and the loop gets more reliable for free.
Practical takeaway
If you are building tools for agents, spend as much time on the description and schema as on the implementation. The implementation runs once; the description is read on every single call.
