tool

In depth

The declaration

A tool is declared before it is of any use: the harness describes to the model, in the context, what the tool does and what parameters it expects. When the model judges a call relevant, it produces a formatted request, which the harness intercepts, validates, then executes. The result comes back into the context, as text, and the model takes it into account for what follows. The whole circuit therefore passes through text: it is an exchange between the model and its harness, never a direct access to the information system.

Description before code

The quality of a tool depends less on its code than on its description. The model chooses on the strength of a name and a few lines of explanation: two tools with overlapping scopes produce erratic calls, and a badly named parameter produces invented values. Nor is a tool the equivalent of an API: one and the same API often gives rise to several tools, cut for intentions rather than for technical resources. The rule of thumb is to design for a reader in a hurry who will never see the full documentation.

The real risk

The main risk is not that the model picks the wrong tool, it is that it holds tools with no guardrail. A tool that writes, sends or pays is an action on the world, and the text that triggers it can come from a document read along the way rather than from your request. The rule is therefore to separate what reads from what acts, to have irreversible actions confirmed, and to treat every tool result as untrusted input. A quieter trap comes on top of this: every declared tool takes up context and draws on the model’s attention, so that an over-stocked catalogue degrades the choices instead of widening them.