Function Calling Across Providers, Step by Step

How function calling connects models to your application

Function calling lets a model request an action through a structured interface. Your application receives that request, runs the appropriate code, and returns the result so the model can continue. The action might retrieve an order, search documentation, or calculate a shipping estimate.

The basic workflow travels well across providers, but request formats and supported features vary. This numbered walkthrough shows how to build the loop first, then adapt it without tying your application logic to one API.

Choose one small tool with a clear purpose

1. Start with an action that reads information, such as checking an order’s delivery status. Define what it accepts and what it returns before connecting a model. For example, get_order_status could accept an order_id and return a status plus an estimated delivery date. Keep authentication and access checks inside your application; a model-generated order identifier does not prove the user can access that order.

Describe the tool with a precise input schema

2. Give the model a tool name, a useful description, and an input schema. Many APIs use JSON Schema or a supported subset to describe function arguments. For the order tool, declare an object with a required string field named order_id. Explain when the tool should be used and any expected identifier format.

Keep the first schema simple. Providers can differ in their support for nested structures, schema constraints, and strict validation modes. Even when an API offers strict argument generation, validate the received arguments in your application before execution.

Send the tool definition through your chosen API

3. Submit the user’s question alongside the available tool definitions. A request such as “Where is order A123?” gives the model enough context to choose the order tool. Depending on the API and its tool-selection settings, the response may contain ordinary text, a tool request, or several tool requests.

An OpenAI-compatible endpoint can simplify client integration, but compatibility does not establish identical behavior across models. When evaluating a model such as Gemini 2.5 Flash, check whether the chosen endpoint supports your schema, tool-selection settings, and response format.

Execute requested tools and return matching results

4. Inspect the response for tool requests. For each request, confirm that the tool name is allowed, parse and validate its arguments, check the user’s permissions, and execute your application function. Preserve the tool-call identifier supplied by the API and attach the result to the matching request using that API’s expected message structure.

Send the result back with the conversation context, then let the model continue. It may answer the user or request another tool. Add limits for execution time, tool calls, and conversation rounds so a failed lookup cannot create an uncontrolled loop.

Adapt provider formats around a shared execution loop

5. Put provider-specific serialization in a small adapter. Your application can represent a tool request internally as a name, arguments, and request identifier, while each adapter translates the provider’s messages into that representation. Preserve any additional fields the provider requires for subsequent turns.

Test missing arguments, unknown tools, multiple calls, timeouts, and tool errors. Begin with complete responses before adding streaming, where arguments may arrive in fragments. Treat retrieved text as untrusted data, and require appropriate confirmation before actions such as issuing refunds or deleting records.

Use a relay to simplify access while testing behavior

6. Relay365 fits when you want pay-as-you-go access to multiple model families through a shared service. Its API base is https://api.api365relay.com; OpenAI clients add /v1. It also works with Claude Code, Codex, and Gemini CLI. Check tool support for the specific model and route you choose, then run the same representative tasks across your candidates.

Compare argument validity, correct tool selection, error recovery, latency, and actual usage costs. Once your execution loop works, create a Relay365 account to evaluate the models that fit your application. Members can also earn a referral bounty when people they invite pay.