Don't Rush to Deploy AI Agents: A Complete Design Guide to Tool Use and Function Calling

Large language models are fundamentally just text generators—they can write an email template but can't send the email; they can describe a query's logic but can't read a database. Turning a model from "talks the talk" into "walks the walk" depends on Tool Use and Function Calling. This article is based on a systematic explainer video and revolves around one core question: how do you give the model "hands," and what price do you pay for installing them?

Text Isn't Enough: Why Models Must Have "Hands"

A model can describe an action, but it cannot actually execute it. Having it output JSON as free text is an extremely fragile approach—one extra word or one missing bracket breaks parsing, and there is no contract guaranteeing valid output. Real business state lives in APIs, databases, and file systems; a sentence describing a request doesn't change anything. Something must call external systems, perform operations, and bring back results.

Function calling solves exactly this breakpoint: the model no longer "prays" that a piece of text can be parsed, but instead emits a structured call that explicitly names the tool and parameters. The system can validate and reliably execute this structure, so a description truly becomes an action.

The Essence of a Tool: Name, Description, and JSON Schema

A tool consists of three parts: a name, a description, and a JSON Schema. The name is the identifier; the description tells the model what the tool does and when to use it; the Schema defines the parameter types (string, number, etc.) and which are required versus optional.

It's worth emphasizing that tool descriptions are themselves prompt engineering. If the description is vague, the model will pick the wrong tool; if it's clear, the choice becomes reliable. Take get_weather as an example: the name signals the intent, the description states "query the current weather for a city," and the Schema specifies that city is a required string—after reading this information, the model knows it must provide a city to answer a weather question.

JSON Schema is a declarative specification (IETF standards draft) used to describe and validate JSON data structures. It defines which properties an object may contain, the type of each property (such as string, number, boolean, object, array), which fields are required, numeric ranges, string regex patterns, and other constraints. In function calling, the model generates valid arguments precisely based on the JSON Schema provided by the tool—the Schema is both a "parameter spec sheet" for the model and a "contract template" for runtime validation. Major model vendors (such as OpenAI's function calling and Anthropic's tool use) all use a subset of JSON Schema to describe parameters, because it naturally aligns with JSON data and can express nested objects and arrays, covering the vast majority of API input shapes.

The Execution Loop: Model Requests, Code Executes, Model Continues

The mechanism of tool calling is a multi-step loop:

1. Send the conversation history and the Schemas of all available tools to the model together;
2. The model returns a tool call (rather than a final answer), specifying the tool name and parameters;
3. Your code actually executes the tool and captures the result—the model itself cannot run code or access external systems;
4. Append the result to the conversation and call the model again;
5. Repeat until the model gives a final answer rather than a new tool call.

The key insight of this loop is: execution authority always stays in your hands; the model only "requests."

In the industry, this mechanism is usually called Function Calling (first introduced by OpenAI in June 2023) or Tool Use (the naming used by vendors such as Anthropic). The two are essentially the same: the model outputs a structured call object (containing the tool name and a parameter JSON) rather than natural language. It is in the same lineage as the earlier ReAct pattern—ReAct has the model alternate between "thought—action—observation," but parsing the action part relies on free text and breaks easily; Function Calling upgrades "action" into a Schema-constrained structured output, greatly improving reliability. Understanding this helps clarify: tool calling is not an entirely new paradigm, but rather replaces the execution step in the agent loop from "text parsing" with "contract calling"—a key piece of infrastructure for agents moving from experiments to production.

Parameter Validation: Treat Every Input as Untrusted

The first rule of security design: treat every parameter as unvalidated input, even if it comes from your own model. Based on this premise, four things need to be done:

• Validate type, range, and allowed values: confirm that numbers are numbers and fall within a reasonable range, and that strings match a whitelist;
• Never concatenate parameters into shell or SQL strings: directly splicing user input opens the door to injection attacks; parameters must remain separate from commands or queries;
• Explicitly reject on validation failure: return a clear error rather than guessing and continuing; once the model sees the feedback, it can retry with better parameters, turning errors into a learning loop.

Tool Categories Determine Protection Strategy

Different types of tools have different risk surfaces, and the focus of protection should adjust accordingly:

• Retrieval tools read data; the main risk is privacy leakage, so the design focus is access boundaries;
• Action tools produce irreversible side effects (such as transferring money or deleting data), so protection must be moved upstream to "what is allowed to happen" rather than remediated after the fact;
• Computation tools carry the risk of resource exhaustion, so the amount of resources they can consume must be limited;
• Write tools carry the risk of data corruption or loss, so the focus is on protecting integrity and preventing loss.

Error Handling: Make Failure a Feedback Signal, Not a Crash

When a tool call fails, the correct approach is to return an error and keep the loop alive rather than crashing the entire agent. Send the error text back to the model, and it will see whether a parameter is missing or the format is wrong, adjusting its next attempt. At the same time, you must set retry limits and total step limits—an agent without limits will repeat the same failure forever, burning time and tokens. Also distinguish transient failures (where a retry may succeed) from parameter errors (which require correction rather than blind retries); the error text should help the model tell these two cases apart.

Security Is the Real Difficulty

The content returned by tools may itself carry prompt injection—attackers can hide instructions in tool output to hijack the agent's behavior. Therefore tool output can never be fully trusted. The three lines of defense are:

• Least-privilege credentials: each tool gets only the permissions needed to do its job, so even if manipulated, the damage is confined to a narrow range;
• Human approval for irreversible operations: actions such as deleting data, moving money, or sending messages on someone's behalf must pause for human confirmation—the agent proposes, the human decides;
• Log every call and result: a complete trace lets you review after an incident and identify which tool or response went wrong.

Prompt Injection is the most prominent attack surface in tool-calling scenarios. It refers to attackers embedding malicious instructions into content the model will read—which may be user input, but also web pages, documents, emails, or tool return results—inducing the model to deviate from its assigned task, leak the system prompt, or perform unauthorized actions. When the injection is hidden in tool output, it is called "Indirect Prompt Injection" and is more dangerous, because developers often guard only against user input while trusting tool returns. Since current large models cannot fundamentally distinguish "data" from "instructions," there is no perfect solution to prompt injection; the industry generally adopts defense in depth: least privilege, human approval, output isolation, input filtering, and full logging together form the defense line, and no single measure is sufficient on its own.

Common Mistakes Checklist

Recurring pitfalls cluster in four places: vague tool descriptions that prevent the model from distinguishing options; parameters passed through without validation; no step limit, so the loop never terminates; and swallowed errors that deprive the model of feedback and the ability to correct course.

Four Engineering Practices for Production

After launch, several practices can take the system from "it runs" to "it's reliable": streaming tool call returns so users can see progress; budgeting tokens, time, and cost per request; generating a trace for every call and result for debugging and auditing; and versioning tools like public APIs, distinguishing breaking changes from non-breaking changes.

Summary

The model cannot act on its own; tool calling gives it a structured way to ask your code to act on its behalf. Each tool is a combination of name, description, and JSON Schema, and the model makes choices by reading the descriptions. The skeleton of the execution loop isn't complicated; the real difficulty lies entirely at the edges: validating parameters as untrusted input, treating errors as feedback rather than crashes, and enforcing least privilege and human approval for irreversible operations. Get this design right, and the agent is worth deploying.

One-line Summary

Tool calling gives large models "hands," but parameter validation, error handling, and security protection are the real challenges in practice.

Paragraph Summary

The article systematically explains how to turn a large language model from "talks the talk" into "walks the walk." The core mechanism is tool calling (Function Calling): the model no longer outputs fragile JSON text but emits a structured call request, which application-side code validates and executes before returning the result to the model, forming a multi-step execution loop. Each tool consists of a name, description, and JSON Schema; description quality directly determines the accuracy of tool selection and is a form of prompt engineering. The article emphasizes that execution authority always remains on the application side and lays out engineering guidelines: validate all parameters as untrusted input, never concatenate them into shell or SQL, return errors as feedback rather than crashing the loop, and set retry and step limits. Security is the real difficulty, requiring defenses against prompt injection in tool output, combined with least-privilege credentials, human approval for irreversible operations, and full call logging. Finally, it divides risk surfaces by four tool types—retrieval, action, computation, and write—and presents production practices such as streaming returns, budget control, traces, and version management.