Function Calling Through a Relay Endpoint

Start with one function you can inspect

Function calling lets a model request an operation that your application knows how to perform. The model supplies a function name and structured arguments. Your application checks the request, runs the function, and sends the result back so the model can answer the user.

A relay endpoint carries those messages between your application and the selected model. Your application remains responsible for executing the function. For a first project, use a small reading list assistant with a function that looks up a book’s availability in a local collection. Keep the collection fixed while you learn the message flow.

Connect your client through MyRelay

Create a MyRelay account to get a personal key and start with a budget you are comfortable spending. MyRelay gives one person one key and one pay-as-you-go budget across its supported providers. An OpenAI-compatible SDK can connect through the API base https://api.myapirelay.com.

Set the API base and key using your SDK’s connection settings, and keep the key in your application’s server environment. Check whether your SDK expects a version suffix in its base URL. Select a model whose current relay documentation confirms support for function calling and your chosen API format. Compatibility with ordinary chat requests does not establish support for every tool feature.

Before adding a function, send one short text request. This separates connection problems from mistakes in your tool definition and makes the first paid test easy to inspect.

Describe the lookup function precisely

Give the function a clear name, such as lookup_book_availability. Explain that it searches your collection and returns whether a matching title is available. Define its arguments with a JSON Schema object containing a required title string. Add an author field only if your collection needs it to distinguish books.

A useful description tells the model when to request the function. For example, explain that availability must come from the collection whenever someone asks whether they can borrow a book. Keep the schema small, and enable stricter argument constraints only where the selected model and endpoint support them.

Decide what your application will return for an unknown title before testing. A clear result such as no matching book found gives the model something truthful to explain.

Send a question and inspect the requested action

Send a user question asking whether a particular book is available, together with the function definition. Where supported, automatic tool selection allows the model to decide whether the lookup is needed. Avoid forcing a call unless you are specifically testing the execution loop.

Inspect the response for tool calls instead of assuming it contains a final answer. A call normally includes an identifier, a function name, and serialized arguments. Preserve the assistant message because the following tool result must connect to that request.

Some responses can contain multiple calls. For this small exercise, process them individually and set a maximum number of calls per user question.

Validate arguments before running the lookup

Parse the arguments and check them against your application’s rules. Confirm that the requested function is allowed, the title is a string, and its length is reasonable. Treat model-generated arguments as untrusted input, even when a schema is present.

Run only the lookup function you explicitly implemented. Return a compact result containing the matched title and availability, or a clear error if the request cannot be completed. Avoid returning the entire collection: extra data increases token use and can distract the final answer.

Return the result and finish the conversation

Add the tool result to the conversation in the format your endpoint expects, referencing the original call identifier. Send the conversation again, including the assistant’s tool request and your result. The model can now explain the availability in ordinary language.

Continue checking for additional tool calls until the model produces a final response or your application reaches its limit. If the limit is reached, stop and give the user an honest explanation rather than leaving the loop running.

Measure the whole exchange before expanding

A function calling interaction commonly needs at least two model requests, so budget for the complete exchange. Repeated instructions, function definitions, conversation history, and tool results all contribute to token usage.

Use MyRelay’s per-request token and cost records to inspect a successful lookup and an unsuccessful one. Keep outputs concise, cap response length where supported, and test a few predictable questions before adding more functions. A small, observable loop makes both behavior and spending easier to understand.