← Voltar aos guias

Tool Use and Function Calling: Advanced Patterns

Tool use and function calling are the bridge between a language model and the systems your application actually needs to control. The model does not execute your database query, send an email, or call an external API by itself. It selects a declared tool, generates structured arguments, and waits for your application to perform the operation and return the result. Understanding that boundary is the difference between a reliable agent and a fragile prompt-driven demo.

Tool Use Is a Controlled Protocol

A tool definition normally contains a name, a description, and a JSON Schema for its arguments. The description explains when the tool is appropriate; the schema constrains the model's output. Your server owns the tool implementation, credentials, permissions, and final execution decision.

The complete loop has four stages:

• Send the user request and available tool definitions to the model.
• Inspect the response for one or more tool calls and parse their arguments.
• Validate permissions and inputs, then execute the corresponding functions in your application.
• Append each tool result to the conversation and make a second model request for the user-facing answer.

Do not treat a tool call as a final answer. It is an instruction that requires an application-side round trip.

Design Schemas for Correctness

Vague schemas create unreliable calls. Prefer small, explicit objects with required fields, bounded enums, and clear descriptions. For example, a weather tool should require a location and use an enum for units such as metric or imperial. Avoid accepting a free-form instruction when two typed fields are sufficient.

Use validation twice: the model-facing JSON Schema improves generation, while server-side validation protects your system against malformed or unauthorized input. Reject unknown fields where your SDK supports strict object handling. Normalize dates, IDs, and pagination values before execution, and return a structured error rather than silently guessing.

Separate Intent from Execution

Let the model decide what information or action is needed, but keep business rules in code. A model may request a refund, for example, while your server checks order ownership, refund limits, payment status, and approval requirements. Never expose a privileged function merely because the model can describe it.

For destructive operations, use a two-step pattern: first gather and summarize the proposed action, then require explicit user confirmation before enabling the execution tool. This reduces accidental writes and makes audit logs easier to interpret.

Handle Multiple Calls Deliberately

Models may issue several independent calls in one response, such as fetching account details and current usage. Execute independent read-only calls in parallel when latency matters, but preserve each call's identifier when returning results. The model needs an unambiguous mapping between a requested operation and its result.

Keep dependent calls sequential. If a search must produce an ID for a later retrieval, return the first result to the model before allowing the next decision. A simple orchestration loop with a maximum number of iterations prevents accidental infinite tool chains.

Make Errors Useful

Tool failures should be machine-readable and safe to expose. Return fields such as status, error type, retryable, and message. Do not return stack traces, access tokens, SQL statements, or internal hostnames. For a temporary upstream failure, mark the error retryable and let your application decide whether to retry. For invalid user input, ask the model to request clarification instead.

Set timeouts for every external call, record latency and cost, and attach a correlation ID to the model request, tool execution, and final response. This turns an opaque agent failure into a traceable workflow.

Control Tool Selection and Cost

Do not send every tool on every turn. Build a small tool registry and expose only the functions relevant to the current route, user role, or conversation state. Fewer choices reduce ambiguity and usually reduce unnecessary tool calls.

Use forced tool selection for deterministic workflows, such as extracting structured fields from a form. Use automatic selection for open-ended assistants. Cache stable read results where appropriate, but never cache permission-sensitive data without including the correct identity and policy context in the cache key.

Use Claude and GPT Through One Relay

When your application already uses an OpenAI SDK or Claude-compatible workflow, 59API can reduce model access costs without requiring a separate billing integration for each provider. Its API base URL is https://api.59api.com, and it provides pay-as-you-go access to Claude Opus, Sonnet, Haiku, and Fable alongside GPT models. Because it uses native official-quality models rather than downgraded substitutes, you can compare tool-selection behavior across models while keeping the same orchestration code. Developers who want to lower operating costs can sign up for 59API and also make use of its referral rebate.

Test the Contract, Not Just the Answer

Production tests should verify the entire contract: whether the model chooses the expected tool, whether arguments pass schema and authorization checks, whether duplicate calls are idempotent, and whether tool errors produce a safe recovery response. Include adversarial prompts that attempt to bypass confirmation or inject extra fields. Measure success rate, tool-call count, latency, and cost per completed task. Those metrics reveal problems that a collection of attractive final answers will miss.