Function Calling Basics: A Step-by-Step Guide

Formats d'échangeEN2026-10-25

Function calling connects a language model to capabilities your application controls. Instead of only generating an answer, the model can request a named function with structured arguments. Your application executes the function and returns its result. The important boundary is simple: the model requests an action; your code performs it. This walkthrough builds a read-only order lookup using the OpenAI-compatible Chat Completions format. ([platform.openai.com](https://platform.openai.com/docs/guides/function-calling))

§ Step 1: Connect your client

Create a Vana API account, obtain an API key, and configure your OpenAI SDK with api.vanaapi.com/v1 as its base URL. Vana API provides one address with OpenAI-compatible access alongside Anthropic Messages and Gemini native protocol entry points. This walkthrough uses the OpenAI-compatible interface; keep its request and response format consistent throughout the integration. ([vanaapi.com](https://vanaapi.com/))

§ Step 2: Choose one narrow function

Start with a function named get_order_status. Its only job is to retrieve an order's current status. Keep cancellation, refunds, and address changes outside this first example. A narrow tool is easier to describe, validate, and test.

Define the intended interaction before implementing it: the user asks, “Where is order ORD-1042?” Your application should retrieve the record and let the model explain the result. If the order identifier is missing, instruct the model to ask for it rather than invent one.

§ Step 3: Describe the tool with a schema

In Chat Completions, add a tools array containing a function definition. Set its type to function, then supply the function name, description, and parameters schema. The description should explain when the lookup is appropriate, not merely repeat its name. ([platform.openai.com](https://platform.openai.com/docs/api-reference/chat/object?lang=ruby&utm_source=openai))

Name: get_order_status.
Description: Retrieve the current status of an order using its order identifier.
Parameters: An object with an order_id property whose type is string.
Required: Include order_id in the required array.
Additional properties: Set additionalProperties to false to disallow unexpected fields in the schema.

Strict schema enforcement is a separate capability. Check support for your selected model and route before enabling it; do not assume every OpenAI-compatible integration implements every option. OpenAI's strict mode supports a subset of JSON Schema. ([platform.openai.com](https://platform.openai.com/docs/api-reference/chat/object?lang=ruby&utm_source=openai))

§ Step 4: Send the first request

Send the conversation, your selected model identifier, and the tool definition together. Set tool_choice to auto so the model can either answer normally or request a tool. In Chat Completions, required forces a tool call, while none prevents one. For this walkthrough, auto leaves room for a clarification question when information is missing. ([platform.openai.com](https://platform.openai.com/docs/api-reference/chat/object?lang=ruby&utm_source=openai))

§ Step 5: Validate and execute the request

Inspect the assistant message for tool_calls. Each function call includes a name and arguments encoded as a JSON string. Parse those arguments and validate them before execution; generated arguments may be malformed or contain unexpected parameters. ([platform.openai.com](https://platform.openai.com/docs/api-reference/fine-tuning/list-checkpoints?utm_source=openai))

Route the name through an explicit allowlist of implemented functions. Check that order_id has the expected format, then verify that the authenticated user may access that order. Derive identity from your server session, not model-generated arguments. For this example, make authorization a prerequisite to the database lookup.

§ Step 6: Return the result to the model

Append the assistant message containing the tool calls to the conversation. Then append a message with role set to tool, tool_call_id matching the original call ID, and content containing the serialized lookup result. Send the updated conversation back for the next response. The matching identifier connects each result to its request. ([platform.openai.com](https://platform.openai.com/docs/api-reference/fine-tuning/list-checkpoints?utm_source=openai))

For your first test, return an illustrative status such as “shipped” with an estimated delivery date. Ask the model to summarize only the returned information and distinguish an estimate from a guarantee.

§ Step 7: Test the full loop

Before adding more tools, test a valid order, a missing identifier, an inaccessible order, malformed arguments, and a backend timeout. Add a maximum number of tool rounds and bounded retries. Keep sensitive fields out of logs. Treat successful lookup, safe refusal, and clear failure handling as separate acceptance criteria. Once those paths work, expand the same pattern to another narrowly scoped function.