← Back to all guides

Tool Use and Function Calling: A Developer Quick Start

Understand the loop before writing code

Tool use lets a model request capabilities outside its own text generation: querying an order database, checking inventory, or running a calculation. Function calling is a structured way to express those requests using a function name and arguments.

The model does not execute your backend function. Your application receives the request, validates it, executes authorized code, and sends the result back. The model then uses that result to answer the user—or requests another tool.

For a first implementation, build one read-only tool. An order-status lookup is easier to secure and debug than a payment or account-deletion action.

1. Connect your client and choose a model

59API provides low-cost, pay-as-you-go access to Claude and GPT models, with native, official-quality models and no downgrade. It is compatible with OpenAI SDKs, Claude Code, and Codex, making it a practical option for experimenting without committing to a subscription.

Configure your client with a 59API key and the relay host https://api.59api.com. Check the current integration instructions for the exact SDK base URL, including whether it needs a versioned path such as /v1. Select an available model that supports tool calling; model identifiers and supported options can vary.

Keep the key in a server-side environment variable. Never embed it in browser code or include it in tool arguments.

2. Define a small, explicit tool contract

For an OpenAI-compatible Chat Completions request, add a tools array containing a function definition. This minimal example describes the contract, not the implementation:

{"type":"function","function":{"name":"get_order_status","description":"Look up the current status of an order belonging to the authenticated user.","parameters":{"type":"object","properties":{"order_id":{"type":"string","description":"The order identifier, such as ORD-1042."}},"required":["order_id"],"additionalProperties":false}}}

Send that definition alongside your messages and model selection. Where supported, tool_choice: "auto" lets the model decide whether a tool is needed. Clear descriptions matter: explain when to call the function, what each argument means, and what the function cannot do.

Schema constraints improve reliability, but they do not replace application-side validation. Treat every generated argument as untrusted input.

3. Execute the request and return the result

When the user asks, “Where is order ORD-1042?”, inspect the assistant response for tool_calls instead of assuming it contains a final answer.

• Preserve the assistant message containing the tool calls in your conversation history.
• Parse function.arguments as JSON. Validate the structure, required fields, and value limits.
• Dispatch through an allowlist. Map get_order_status to a known handler; never evaluate a model-provided function name as code.
• Check authorization. Resolve the authenticated user from your application session and verify that the order belongs to them.
• Append a tool message using the matching tool_call_id and a string containing the result.
• Call the model again with the updated history so it can produce the user-facing answer.

A tool-result message could look like this, replacing call_123 with the actual returned identifier:

{"role":"tool","tool_call_id":"call_123","content":"{\"order_id\":\"ORD-1042\",\"status\":\"shipped\"}"}

If the response contains multiple tool calls, handle each and return a corresponding result. Only run calls concurrently when they are independent.

4. Add safety limits before shipping

Set tool timeouts, cap output sizes, and limit the number of tool-calling rounds. Return structured errors rather than fabricated success. Require confirmation for destructive or financial actions, and use idempotency keys where retries could duplicate a write.

Treat tool output as data, not instructions. Retrieved pages or database text must not override your application’s rules. Test malformed arguments, unauthorized orders, timeouts, and repeated requests.

Keep protocol and cost decisions separate

Claude’s native Messages API uses tool_use and tool_result content blocks, while OpenAI-compatible Chat Completions uses tool_calls and tool messages. Follow the format of your chosen endpoint rather than mixing them.

Tool schemas, results, and follow-up requests all consume tokens. Send only relevant tools, keep results compact, and benchmark a cheaper model before moving to a larger one. 59API’s pay-as-you-go pricing makes that comparison accessible; its referral rebate can offer additional savings subject to current terms. When you are ready to test this loop, consider signing up for 59API and starting with one read-only tool.

Pricing · Docs