Function Calling

Function calling, also known as tool use, is the mechanism that lets a language model interact with external code and services. The developer describes a set of available functions; the model decides when one is needed and returns a structured JSON object naming the function and its arguments. Crucially, the model does not execute anything itself — it only signals that a call should be made, and the surrounding application runs the actual function. That separation is what makes tool use both powerful and governable.

How it works

Each tool is described with a JSON schema specifying the function's name, purpose, and the shape of its arguments. The schemas are passed to the model alongside the prompt, occupying part of the context window. When the model determines a tool is appropriate, it emits a JSON payload conforming to the schema; the application parses it and performs the real work — querying a database, hitting an API, reading a sensor, controlling hardware. The function's result is then fed back into the conversation so the model can continue reasoning with real data. The loop can repeat: call, observe, decide, call again. Strict modes offered by modern runtimes can enforce that the emitted JSON exactly matches the supplied schema, eliminating a once-common class of parsing failures.

Most runtimes also expose control over when tools fire. The default lets the model choose freely; a forced mode requires it to call a specific function, which turns a chat model into a reliable structured-data extractor (define one function whose arguments are the fields you want, force the call, and read the JSON); and a disabled mode guarantees plain text. Parallel tool calling — emitting several independent calls in one turn — cuts latency when the model needs three lookups that do not depend on each other. These knobs matter in practice: a fleet-monitoring assistant that must return a machine list in schema form is a forced call, not a polite request in the prompt.

From tool calls to agents

Function calling is the foundation of AI agents: a model that can call tools can take multi-step actions rather than only producing text. An agent loop is nothing more exotic than a model, a set of tools, and a program that keeps feeding results back until the task is done. Retrieval is usually the first tool wired in — a search function backed by semantic search and reranking lets the agent look things up before it acts, the same pattern that powers RAG.

Sovereignty and safety

For a sovereign operator, function calling is where local AI stops being a chatbot and starts being useful. A locally hosted model served through Ollama or llama.cpp can be wired to local tools and private data sources — your file server, your node's RPC interface, your miner fleet's monitoring API — so an assistant can act on a homelab or mining setup without any tool inputs or outputs traversing a third-party service. Several capable open-weight models support tool use well, making fully self-hosted agents realistic today. The flip side is that tools are an attack surface: a model that reads untrusted content and holds credentials to act on your systems is exposed to prompt injection, so the craftsman's rule applies — give each tool the narrowest permissions that do the job, require confirmation for destructive actions, and log everything.

Practical notes

Good tool design matters more than model size. Small, single-purpose functions with clear names and tight schemas get called correctly far more often than sprawling do-everything endpoints. Return concise, structured results — the model has to read them back through the same context budget as everything else. And keep the executor honest: validate arguments before running anything, because the model's JSON is a request, not a command. D-Central documents function calling as the action layer of a local AI stack: retrieval finds the facts, the model does the reasoning, and tools — under your rules, on your hardware — do the work.