Skip to main content
Function calling enables dynamic workflows by allowing the model to select and suggest function calls based on user input, which helps in building agentic workflows. By defining a set of functions, or tools, you provide context that lets the model recommend and fill in function arguments as needed.

How function calling works

Function calling enables adaptive workflows that leverage real-time data and structured outputs, creating more dynamic and responsive model interactions.
  1. Submit a Query with tools: Start by submitting a user query along with available tools defined in JSON Schema. This schema specifies parameters for each function.
  2. The model processes and suggests: The model interprets the query, assesses intent, and decides if it will respond conversationally or suggest function calls. If a function is called, it fills in the arguments based on the schema.
  3. Receive a model response: You’ll get a response from the model, which may include a function call suggestion. Execute the function with the provided arguments and return the result to the model for further interaction.
Not all models support function calling. See Infercom Inference Service models for the list of available models and their capabilities.
When using gpt-oss-120b for function calling, set reasoning_effort to "high" for best results.

Model support

Function calling is supported on the models below. Always check Supported models for current availability. Vision requests support the same tools, tool_choice and response_format options as text-only requests. The constraint is applied during generation. See Vision.

Example usage

The examples below describe each step of using function calling with an end-to-end example after the last step.

Step 1: Define the function schema

Define a JSON schema for your function. You will need to specify:
  • The name of the function.
  • A description of what it does.
  • The parameters, their data types, and descriptions.
Example schema for getting the weather

Step 2: Configure function calling in your request

When sending a request, include the function definition in the tools parameter and set tool_choice to the following:
  • auto : allows the model to choose between generating a message or calling a function. This is the default tool choice when the field is not specified.
  • required : This forces the model to generate a function call. The model will then always select one or more function(s) to call.
  • To enforce a specific function call, set tool_choice = {"type": "function", "function": {"name": "get_weather"}}. This ensures the model will only use the specified function.
A forced tool_choice is not guaranteed on every model. Two behaviours to plan for.gemma-4-31B-it does not always honour the constraint. On prompts that do not obviously call for a tool, roughly a third to a half return a plain text answer instead of the forced call. The other models in the table above are not affected. If you need a reliable forced call on Infercom’s EU infrastructure, use MiniMax-M2.7 or gpt-oss-120b.An unhonoured forced call returns HTTP 400. When the model produces no valid function call, the request fails with the body below. Note that this response does not use the standard error envelope: error is a string, not an object, and there is no request_id.
The error_model_output field carries the text the model produced instead. Read it if you need to recover the answer. Handle this status in any workflow that forces a call. See API error codes.
The following code block shows a fake weather lookup that returns a random temperature between 20°C and 50°C. For accurate and real-time weather data, use a proper weather API.

Step 3: Handle tool calls

If the model chooses to call a function, you will find tool_calls in the response. Extract the function call details and execute the corresponding function with the provided parameters.
Example code

Step 4: Provide function results back to the model

Once you have computed the result, pass it back to the model to continue the conversation or confirm the output.
Example code

Step 5: Example output

An example output is shown below.

End-to-end example

The following code block shows a fake weather lookup that returns a random temperature between 20°C and 50°C. For accurate and real-time weather data, use a proper weather API.

Streaming tool calls

Set stream: true to receive tool calls as they are generated. Arguments arrive in the tool_calls field of the delta. No reasoning scaffolding appears in delta.content.
Ignore delta fields you do not recognise. The set of keys in delta is not fixed across models.gpt-oss-120b adds a channel field to the delta on streams that carry no tools. It holds the value analysis while the model reasons. The field is absent as soon as you supply a tools array, and no other model emits it.A client that validates delta keys strictly will break on the first case. Parse the fields you need and discard the rest.

JSON schema

You can set the response_format parameter to your defined schema to ensure the model produces a JSON object that matches your specified structure.
Ensure to set the "strict" parameter to false, as true isn’t supported yet. When it is available, it will ensure the model strictly follows your function schema instead of making a best-effort attempt.

JSON mode

You can set the response_format parameter to json_object in your request to ensure that the model outputs a valid JSON. In case the mode is not able to generate a valid JSON, an error will be returned.
In case the model fails to generate a valid JSON, you will get an error message Model did not output valid JSON.
Example response

Other methods of structured outputs

Beyond JSON mode, structured outputs can also be generated using the Instructor library, which provides a convenient wrapper for extracting structured data from LLM responses using Pydantic models.