Tools and Function Calling

Tools and Function Calling

The ability to use tools transforms a language model from a text generator into an agent that can interact with the world. Function calling (also called "tool use") is the mechanism that makes this possible.

How Function Calling Works

When you define tools for a model, you describe each tool as a function with:

• A name
• A description (what it does — the model reads this to decide when to use it)
• A schema of parameters (what inputs it takes)

The model doesn't directly call the function. Instead, when it decides to use a tool, it outputs a structured message saying "call this function with these arguments." Your code then runs the function and returns the result to the model. The model continues from there.

This design is intentional: the model can't directly execute code. It can only request that code be executed. You control what tools exist and whether to actually run them — which is where safety guardrails live.

Common Tool Categories

Web search: lets the model find current information not in its training data. Most capable agents have this.

Code execution: run Python or JavaScript, perform calculations, process data. Reduces reliance on the model's arithmetic (which is unreliable) and enables real computation.

File operations: read, write, and search files. Enables document processing and code editing agents.

APIs: weather, maps, databases, email, calendar, Slack, GitHub — any system with an API can become a tool.

Browser/web scraping: navigate web pages, fill forms, click buttons. Enables more complex web automation.

Memory tools: read from and write to a memory store, enabling long-term state across agent runs.

Well-designed tools have clear names and descriptions. The model chooses tools based on those descriptions, so precision matters.

Practical Tool Design

Be specific in descriptions: "Search the web for current information" is clearer than "web tool". The model uses the description to decide when to call the tool.

Validate inputs: the model might pass unexpected values. Validate parameters before executing anything dangerous.

Handle errors gracefully: tools fail. Return structured error messages the model can reason about, not stack traces.

Limit blast radius: read-only tools first. Add write tools incrementally. Require confirmation for destructive operations.

Log everything: every tool call and result should be logged. You need this for debugging, cost tracking, and safety review.

Test in isolation: test each tool independently before wiring it to an agent. Many bugs come from the tool, not the model.