Tool Use & Function Calling

Tool use is what turns an LLM from a clever text generator into something that can actually do work. The pattern is simple: declare functions the model can call, let it choose when and how to call them, then loop on the results.

The Loop

A tool-use turn looks like:

1. Send the model the user request and the available tools.
2. The model returns either a final answer or a tool call.
3. If it's a tool call, execute the function with the model's arguments.
4. Send the result back to the model.
5. Repeat until the model produces a final answer.

This is the foundation of every agent framework. Everything else is layered on top.

Designing Good Tools

• One thing well. A tool that does one specific operation is easier for the model to use correctly than a tool that takes a mode parameter.
• Self-describing names. search_customer_by_email is better than query.
• Clear, short descriptions. The description is part of the prompt; treat it like one.
• Typed arguments with constraints. Enums, regexes, ranges. Less freedom = fewer mistakes.
• Error messages the model can act on. "Invalid date format, expected YYYY-MM-DD" beats "400".

When to Use Tools vs Knowledge

• Knowledge that changes (prices, inventory, user data) → tools.
• Knowledge that's stable but specific (your codebase, your docs) → retrieval.
• Knowledge the model already has → just ask.
• Computation beyond rough arithmetic → tools (calculators, code execution, SQL).

The general rule: if accuracy matters and the answer can be looked up or computed, give the model a tool.

Tool Choice Strategies

• Auto — the model decides whether to call a tool. Good default.
• Required — force the model to call some tool this turn. Useful when you've narrowed the user intent.
• Specific tool — force a specific call. Useful for structured extraction.

Operational Concerns

• Latency — every tool round-trip adds latency. Prefer parallel tool calls when supported.
• Cost — tool definitions live in the prompt on every turn. Trim aggressively.
• Safety — tools that mutate state (send email, charge card, delete file) need separate confirmation, rate limits, and auditing.
• Observability — log every tool call with inputs, outputs, and timing. This is your debugging substrate.

What "Agentic" Actually Means

When you let the model loop on tool calls without a fixed step count, you have an agent. The interesting engineering questions become: when does it stop? How do you bound runaway loops? How do you keep the context coherent across many turns? Those questions belong in the agents section.