Function Calling with GPT and Claude via 59API
Function Calling with GPT and Claude via 59API
Function calling, often called tool use, lets a language model ask your application to perform a real action: query a database, call a weather API, create a ticket, search documents, or run a calculation. Instead of hoping the model invents an answer, you give it a structured list of tools it may request. Your code executes the selected tool, then returns the result to the model so it can produce a useful final response.
This tutorial shows a practical, provider-neutral workflow for using tools with both GPT and Claude models. It also explains where 59API fits: it is a low-cost, pay-as-you-go AI API relay with official-quality GPT and Claude models, support for Claude Opus, Sonnet, Haiku, and Fable, compatibility with Claude Code, Codex, and OpenAI SDK clients, and a simple base URL: https://api.59api.com.
Step 1: Choose the right tool use case
Start with a task where the model needs fresh, private, or deterministic information. Good examples include checking order status, retrieving account data, searching an internal knowledge base, converting currencies, booking meetings, or validating user input. Avoid tools for simple text transformations that the model can already do reliably, because each tool round trip adds latency and cost.
A strong first project is a support assistant with a tool named get_order_status. The model receives a customer question, decides whether it needs the tool, extracts the order ID, and asks your application to run the lookup. Your application never gives the model direct database access; it only exposes the narrow function you define.
Step 2: Configure your client for 59API
If your app already uses an OpenAI-compatible SDK, the migration pattern is usually simple: set the API key from your 59API dashboard and point the SDK base URL to https://api.59api.com. Then choose the GPT or Claude model you want to call. This is useful for teams that want to test Claude Sonnet for coding workflows, GPT models for broad ecosystem compatibility, or cheaper Haiku-style models for high-volume classification.
59API is especially attractive during tool-calling development because debugging often requires many small calls. A low-cost relay helps you iterate without burning budget, while still using native, official-quality models rather than downgraded substitutes. If you are building production agents, the referral rebate can also reduce ongoing spend as usage grows.
Step 3: Define tools with strict input schemas
A tool definition should include three things: a clear name, a concise description, and a JSON-style input schema. For example, get_order_status should accept order_id as a required string. Do not define broad tools such as run_sql or browse_any_url for early prototypes. Narrow tools are safer, easier to test, and easier for models to call correctly.
For GPT-style APIs, tools are commonly sent as function definitions with parameters. For Claude-style APIs, tools are also described with names, descriptions, and input schemas, though the exact field names may differ by endpoint or SDK. The implementation detail changes, but the design principle is the same: tell the model exactly what it can call and what arguments are valid.
- Use descriptive names: get_customer_invoice is better than fetch_data.
- Keep arguments minimal: ask only for the fields your backend needs.
- Validate every argument: never trust model-generated inputs without checking them.
- Return compact results: send the model the facts it needs, not entire database rows.
Step 4: Send the user request and available tools
Your first model call includes the user message and the tool list. For example: the user says, I need the delivery date for order A12345. The model should not guess. It should respond with a tool request for get_order_status and an argument like order_id: A12345.
In your code, inspect the assistant response. If it contains a tool call, pause the conversation and execute the matching server-side function. If it contains a normal text answer, you can return that answer directly. This loop is the core of tool use: model decides, application executes, model explains.
Step 5: Execute tools safely in your backend
The tool call is not the tool itself. It is only a structured request from the model. Your backend should map the requested name to an approved function, validate the arguments, enforce authentication, apply rate limits, and handle errors. If a user is not allowed to see an order, return an authorization error as the tool result rather than exposing hidden data.
For external APIs, add timeouts and retries. For database lookups, use parameterized queries. For write actions, consider a confirmation step before executing high-impact operations such as refunds, cancellations, or account changes. The safest agent is one where the model proposes actions and your application enforces policy.
Step 6: Return the tool result to the model
After execution, send a second model call that includes the tool result in the expected message format for your provider. Keep the result factual and concise, such as status: shipped, carrier: DHL, estimated_delivery: 2026-07-12. The model can then produce a natural response: Your order has shipped with DHL and is estimated to arrive on July 12.
This second call is important because it lets GPT or Claude translate raw tool data into helpful language, apply tone instructions, and answer follow-up questions. It also keeps your UI consistent: users get a conversational answer, while your backend remains the source of truth.
Step 7: Test with both GPT and Claude models
Tool behavior varies slightly by model. GPT models may be a convenient default when using OpenAI SDK patterns. Claude Sonnet is often strong for coding assistants and multi-step reasoning. Claude Haiku-style models can be cost-effective for simple routing or extraction. With 59API, you can compare these options behind one relay instead of wiring separate billing and access paths for every provider.
Create a small test suite with realistic prompts: missing order IDs, invalid IDs, multiple orders in one request, unauthorized users, and ambiguous wording. Measure tool-call accuracy, latency, total cost, and final answer quality. The best model is not always the largest one; for many tool workflows, a cheaper model with a strict schema performs extremely well.
Step 8: Ship with observability and cost controls
Log the model, prompt version, tool name, validated arguments, tool latency, and final outcome. Redact personal data before storing logs. Add alerts for spikes in tool errors or token usage. Because 59API is pay-as-you-go and among the cheapest relays, it is a practical choice for production workloads where every agent turn may include multiple model calls.
If you are ready to experiment, sign up for 59API, create an API key, set your base URL to https://api.59api.com, and run the same tool-calling flow against GPT and Claude models. You will quickly see which model gives your application the best balance of accuracy, speed, and cost.
Final checklist
- Define narrow tools with clear schemas and required fields.
- Let the model request tools, but let your backend execute them.
- Validate and authorize every tool call before running it.
- Return concise results so the model can produce the final answer.
- Compare GPT and Claude through 59API to optimize cost and quality.
Function calling turns GPT and Claude from chat models into practical application interfaces. With a careful schema, safe backend execution, and a low-cost relay like 59API, you can build reliable AI agents that do real work without giving up control of your systems.