Tool Calling
Extend ASI:One models with custom functions and real-world actions through intelligent tool selection.
Tool calling in ASI:One allows models to go beyond text generation by invoking external functions with the right parameters. This enables integration with APIs, tools, or your own code to retrieve live data, perform tasks, or trigger actions based on user input.
Overview
Function calling enables you to integrate your custom code with the Chat Completion API in ASI:One. When given access to defined tools, the model can choose to call them based on the conversation context. After the function is called, you execute the corresponding code, return the results, and the model incorporates the output into its final reply. This guide provides instructions for connecting ASI:One models to your custom functions to retrieve data or perform specific actions.
Tool calling is enabled with models :
asi1-mini
,asi1-fast
andasi1-extended
.
Here’s a basic example of how tool calling works with ASI:One:
Example Response
When you make a tool call request, the model will respond with the tool call details. Here’s an example response:
Sample Tools
Let’s look at the steps to allow a model to use a real get_weather
tool defined below:
Sample get_weather
function implemented in your codebase
Complete Tool Execution Cycle
Let’s walk through the complete cycle of executing a tool call with ASI:One, using the weather example:
Step 1: Initial Request with Tools
First, we make a request to the model with the tool definition and user message:
Step 2: Parse Tool Calls from Response
The model responds with a tool call that we need to parse:
Step 3: Execute Tools and Format Results
Next, we execute the tool and format the results:
Step 4: Send Results Back to Model
Now we send the tool results back to the model:
Step 5: Receive Final Answer
Finally, we get the model’s response incorporating the tool results:
Tool Result Handling in ASI:One
Here are key guidelines to ensure correct behavior and prevent common errors.
Preserving Tool Call IDs
Each tool call comes with a unique id
that must be preserved when sending results back.
Message History Order
The message history must maintain this exact order:
- Original user message
- Assistant message with
tool_calls
(content should be null or empty) - Tool result messages (one for each tool_call, identified by
tool_call_id
)
Content Formatting
Tool results must be JSON-stringified within the content
field.
Error Handling
If a tool fails, send back a result message indicating the error.
Tool Definition
Functions are specified using the tools parameter in each API request, where each tool is described as a function object.
Each function is defined using a schema that tells the model what the function does and what input arguments it requires. The schema includes the following key fields:
-
name
(string) : A unique, descriptive identifier for the tool (e.g.,get_weather_forecast
,send_email
). Use underscores or camelCase formatting. Avoid spaces or special characters. -
description
(string) : A detailed explanation of what the tool does and when it should be used. Clear, specific descriptions improve the model’s ability to use the function correctly. -
parameters
(object) : Defines the input parameters the tool expects.-
type
(string) : Usually set to"object"
to represent input parameters. -
properties
(object) : Lists each input parameter and its details: -
type
(string): The data type (e.g.,string
,integer
,boolean
,array
). -
description
(string): A clear explanation of the parameter’s purpose and expected format. Example:"City and country, e.g., 'Paris, France'"
-
enum
(optional): An array of allowed values, useful when inputs must be restricted. Example:"enum": ["celsius", "fahrenheit"]
-
required
(array of strings) : Lists the parameter names that must be included when calling the function.
-
Example Tool Schema
Additional Configurations
ASI:One provides several options to control how and when tools are called, as well as how strictly the model adheres to your function schemas.
Tool Choice
By default, the model determines when and how many tools to use. You can control this behavior with the tool_choice
parameter:
- Auto (default): The model may call zero, one, or multiple functions.
- Required: The model must call at least one function.
- Forced Function: Force the model to call a specific function.
- None: Prevent the model from calling any functions.
Parallel Tool Calling
By default, the model may call multiple functions in a single turn. To restrict this and ensure only one (or zero) tool is called per turn, set:
Note: If parallel tool calls are enabled, strict mode may be disabled for those calls.
Strict Mode
Setting strict
to true
ensures the model strictly follows your function schema. This is recommended for most use cases.
Requirements for strict mode:
additionalProperties
must be set tofalse
for each object in theparameters
.- All fields in
properties
must be listed inrequired
.
Example with strict mode enabled:
Example with strict mode disabled:
Tip: We recommend enabling strict mode for reliable tool calling.