Tool Use

Tool use is the capability that separates an AI agent from a plain chatbot: the model can call out to external tools rather than only generating text. Anthropic uses the term "tool use" for the same underlying primitive that OpenAI labels function calling. A tool is any capability exposed to the model with a name, a description, and an input schema — a web search, a calculator, a shell command, a database query. The model reads the tool descriptions, decides which to invoke, and emits a structured request; the host application runs the tool and returns the output. The model never executes anything itself — it only asks, which is the design property everything else builds on.

From single tools to toolchains

A model rarely uses a tool once. In an agentic workflow it observes a result, reasons about it, and may call another tool, repeating until the task is done: list files, read one, edit it, run the tests, read the failure, edit again. The quality of a tool's description matters as much as its code, because the model selects tools purely from the natural-language and schema hints it is given — vague descriptions cause wrong or missing calls, and overlapping tools cause dithering. Well-designed toolsets are small, orthogonal, and return errors the model can act on rather than opaque stack traces. Standard interfaces like the Model Context Protocol (MCP) make tools portable across models and applications: a tool server written once can serve any MCP-capable client, without surrendering control of where execution happens.

The security boundary

For a self-hosted operator, tool use is where a local model gains real reach over your infrastructure — and therefore where the security boundary lives. Three disciplines matter. First, least privilege: a tool should expose the narrowest capability that does the job (a "read miner telemetry" tool, not a raw shell). Second, input validation: treat every tool argument the model produces as untrusted input, exactly as you would a web form. Third, injection awareness: any text a tool returns — a web page, an email, a log line — can contain instructions that try to steer the model, the failure mode known as prompt injection. Irreversible or dangerous actions should pass through a human-in-the-loop checkpoint, and the system prompt should state the rules of engagement explicitly rather than assuming the model infers them.

On the sovereign bench

Tool use is what turns a local model served through Ollama or llama.cpp from a novelty into an operator. A modest open-weight model with a good toolset — query the node, pull pool stats, read a miner's API, file a note — often outperforms a larger model armed with nothing but its training data, because tools supply fresh, verifiable facts the weights cannot contain. That is the practical case for learning this primitive well: the tools are yours, they run on your hardware, and the model's reach extends exactly as far as you decide to let it. D-Central treats tool definitions as a first-class part of any sovereign AI deployment — designed, reviewed, and permissioned like the infrastructure they are.

A practical starting exercise: give a local model exactly three read-only tools against your own infrastructure — say, query node status, fetch miner telemetry, and search your notes — and watch how it chains them before you grant anything that writes. Read-only agents teach you the failure modes cheaply: where descriptions mislead, where outputs confuse, where the model over-calls or gives up. Only after the read-only version behaves for a week does a write-capable tool earn its place, one narrow capability at a time. That graduation path — observe, then act; narrow, then broader — is how tool use stays an asset instead of an incident report.