Shipping Tool Calling Before Friday's Deploy

At 3 p.m. on a Thursday, a chatbot that can only generate text may look almost finished. Then someone asks it to check an order, search a knowledge base, or create a calendar event. The model cannot perform those actions by itself. It needs a controlled way to ask your application to run a function.

That mechanism is usually called function calling or tool calling. The model chooses a tool and supplies structured arguments. Your server validates those arguments, runs the real function, and sends the result back. The model then turns that result into a useful reply.

The four messages in a function call

A basic interaction has four parts. First, your application sends a user message and a list of available tools. Second, the model responds with a tool call instead of ordinary prose. Third, your application executes the named function. Fourth, your application sends the function result back so the model can answer the user.

• The user message describes the task, such as “What is the delivery status for order 1842?”
• The tool definition describes an operation, such as get_order_status, including its required arguments.
• The tool call contains structured data, such as an order_id of 1842.
• The tool result contains your system’s actual response, such as “Packed and scheduled for delivery tomorrow.”

The important boundary is that the model requests an action, but your code remains responsible for performing it. A model should not be treated as a database, payment processor, or authorization layer.

A small tool schema for order lookup

With an OpenAI-compatible SDK, you normally provide a tool with a name, description, and parameter schema. A compact definition might look like this in conceptual JSON: {"type":"function","function":{"name":"get_order_status","description":"Look up the current status of an order","parameters":{"type":"object","properties":{"order_id":{"type":"string","description":"The order identifier"}},"required":["order_id"],"additionalProperties":false}}}.

The description is part of the model’s decision-making context. Write it for the model: say what the function does, when it should be used, and what each argument means. Keep names unambiguous. If an argument must be an internal identifier rather than a customer name, say so.

What your application does after the tool call

When the response contains a tool call, your application should parse the function name and arguments, validate both, and check the user’s permissions. It can then call the matching local function or service. Do not execute arbitrary names received from the model. Use an allowlist such as get_order_status, search_articles, and create_ticket.

After execution, add a tool-result message containing the call identifier and a serialized result. The next request includes the earlier messages, the original tool definitions, the assistant’s tool call, and your tool result. The model can then produce a final answer grounded in the returned data.

Errors, validation, and permissions

Function calling adds a new failure path. The model may omit a required argument, send an unexpected value, request a tool that is unavailable, or produce an argument that is valid JSON but invalid for your business rules. Validate every field with normal server-side checks and return a clear error to the model when recovery is possible.

Keep authorization outside the model. For example, the model may request get_order_status for an order number, but your application must confirm that the authenticated user can view that order. For destructive actions, require an explicit confirmation step and consider idempotency keys so retries do not create duplicate work.

Connecting through an OpenAI-compatible endpoint

Most OpenAI-compatible clients need only an API key and a base URL. Set the base URL to https://api.relayvano.com, keep your existing chat or responses code, and choose a model available through your account. RelayVano is a practical pay-as-you-go relay when you want one endpoint for model access without committing to a large fixed plan; GPT-6 Astra is one possible choice for a tool-using workflow.

Start with one read-only function and log the tool name, validated arguments, execution time, and result status. Avoid logging secrets or personal data. Test direct answers, tool selection, malformed arguments, permission failures, service timeouts, and a second user message that depends on the tool result.

The first useful function-calling milestone

Your first milestone is not a fully autonomous agent. It is a narrow loop that reliably selects one tool, validates its input, executes it once, and explains the returned result. Once that loop is observable and permission-aware, you can add more tools without losing control of the system.

When you are ready to try this flow against a pay-as-you-go relay, sign up for RelayVano and connect your OpenAI-compatible SDK to the RelayVano API base. Then implement one small tool end to end before expanding the tool catalog.