16.1 What "tools" are (and why they reduce hallucination)
Overview and links for this section of the guide.
On this page
What “tools” are
A tool is a function your app exposes to the model with:
- a name,
- a contract (input schema),
- an output shape,
- clear error behavior.
The model can decide to call a tool instead of guessing. Your system executes the tool and returns the result into the model’s context.
The model doesn’t “execute code.” It requests a tool call with arguments. Your application decides whether to execute it and what to return.
The tool-calling lifecycle (step-by-step)
A typical loop looks like:
- User request: “Summarize this ticket and pull the order details.”
- Model proposes tool call: e.g.,
get_order(order_id=...) - System validates tool call: check schema, allowlist, auth, budgets
- System executes tool: call database/API
- System returns tool result: structured data (or error) to the model
- Model produces final output: grounded in tool result
The important part is step 3: the system is the gatekeeper.
Why tools reduce hallucination
Models hallucinate when they must guess missing facts. Tools reduce hallucination by:
- providing authoritative data: retrieval from docs, DB, or APIs
- enabling verification: run checks instead of guessing
- reducing ambiguity: tool outputs are structured and explicit
Instead of asking the model to “know” something, you give it a way to look it up.
Design your prompts so the model treats tool outputs as the source of truth and prefers them over prior assumptions.
Tool types (read vs compute vs write)
Classifying tools is a safety and reliability technique.
Read-only tools
Retrieve data without side effects. Examples: fetch doc by id, search index, get user profile. These are usually the safest and easiest to retry.
Compute tools
Pure computations with deterministic outputs. Examples: calculate totals, validate schema, parse input. These are also safe and easy to test.
Write tools (side effects)
Create changes in external systems. Examples: create ticket, update database, send email. These require the strongest guardrails: approvals, idempotency, and strict validation.
Most product value comes from read + compute. Add write tools only when you have strong controls and a clear need.
Grounding pattern: cite tool outputs, not vibes
When you use tools, teach the model a grounded behavior:
- tool outputs are the only authoritative source for external facts,
- when tool outputs are missing or unclear, ask clarifying questions or say “unknown.”
This is how you get “don’t make stuff up” behavior without building a full RAG system yet.
Risks and misconceptions
Misconception: tools guarantee truth
Tool outputs can be wrong, stale, or incomplete. Tools reduce hallucination, but they don’t eliminate data quality problems.
Misconception: tools prevent prompt injection
Untrusted data can still influence which tools the model tries to call. You need app-level controls: allowlists, budgets, and instruction separation.
Risk: side effects without approval
Write tools are dangerous. You must design for explicit confirmation, idempotency, and audit logs.