Using function-calling
Introduction
Function calling enables models to intelligently select and utilize tools based on user input. This powerful feature allows you to build dynamic agents that can access real-time information and generate structured outputs. The function calling API doesn’t execute functions directly. Instead, it generates OpenAI-compatible function call specifications that you can then implement.
How function calling works
- Tools specifications: You specify a query along with the list of available tools for the model. The tools are specified using JSON Schema. Each tool includes its name, description, and required parameters.
- Intent detection: The model analyzes user input and determines whether to provide a conversationsl response or generate function calling specifications.
- Function call generation: When appropriate, the model outputs structured function calls in OpenAI-compatible format, including all necessary parameters based on the context.
- Execution and response generation: You execute the specified function calls and feed results back to the model for continued conversation.
Supported models
A subset of models hosted on Fireworks supports function calling using the described syntax. These models are listed below. The supportsTools field in the model response also indicates whether the model supports function calling.
- Llama 3.1 405B Instruct
- Llama 3.1 70B Instruct
- Qwen 2.5 72B Instruct
- Mixtral MoE 8x22B Instruct
- Firefunction-v2: Latest and most performant model, optimized for complex function calling scenarios (on-demand only)
- Firefunction-v1: Previous generation, Mixtral-based function calling model optimized for fast routing and structured output (on-demand only)
These models can all utilize function calling with the same syntax, shown below.
Basic example: City population data retrieval: Llama 3.1 405B Instruct
For this example, let’s consider a user looking for population data for a specific city. We will provide the model with a tool that it can invoke to retrieve city population data.
- To achieve this, we detail the purpose, arguments, and usage of the
get_city_population
function using JSON Schema. This information is provided through thetools
argument. The user query is sent as usual through themessages
argument.
- In our case, the model decides to invoke the
get_city_population
tool with a specific argument. Note that the model itself does not invoke the tool. It just specifies the argument. When the model issues a function call - the completion reason would be set totool_calls
. The API caller is responsible for parsing the function name and arguments supplied by the model & invoking the appropriate tool.
- The API caller obtains the response from the tool invocation & passes its response back to the model for generating a response.
This results in the following response
Advanced example: Financial data retrieval
TL;DR This example tutorial is available as a Python notebook [code | Colab].
For this example, let’s consider a user looking for Nike’s financial data. We will provide the model with a tool that the model is allowed to invoke & get access to the financial information of any company.
- To achieve our goal, we will provide the model with information about the
get_financial_data
function. We detail its purpose, arguments, etc in JSON Schema. We send this information in through thetools
argument. We sent the user query as usual through themessages
argument.
- In our case, the model decides to invoke the tool
get_financial_data
with some specific set of arguments. Note The model itself won’t invoke the tool. It just specifies the argument. When the model issues a function call - the completion reason would be set totool_calls
. The API caller is responsible for parsing the function name and arguments supplied by the model & invoking the appropriate tool.
- The API caller obtains the response from the tool invocation & passes its response back to the model for generating a response.
This results in the following response
Tools specification
The tools
field is an array where each component includes the following fields:
type
(string
) Specifies the type of the tool. Currently, onlyfunction
is supported.function
(object
) Specifies the function to be called. It includes the following fields:description
(string
): A description of what the function does, used by the model to choose when and how to call the function.name
(string
): The name of the function to be called. Must be a-z, A-Z, 0-9, or contain underscores and dashes, with a maximum length of 64.parameters
(object
): The parameters the functions accepts, described as a JSON Schema object. See the JSON Schema reference for documentation about the format.
Tool choice
The tool_choice
parameter controls whether the model is allowed to call functions or not. Currently, we support values auto
, none
, any
or a specific function name.
auto
(default) The model can dynamically choose between generating a message or calling a function. This is the default tool choice when no value is specified fortool_choice
.none
Disables the use of any tools, similar to not specifying thetool_choice
field.any
Allows the model to call any function. You can also specify:
This ensures that a function call will always be made, with no restriction on the function’s name.
- Specific function name
To force the model to use a particular function, you can explicitly specify the function name in the
tool_choice
field. For example:
This ensures that the model will only use the get_financial_data
function.
OpenAI compatibility
Fireworks AI’s function calling API is fully compatible with OpenAI’s implementation, with a few differences:
- No support for parallel function calling
- No nested function calling
- Simplified tool choice options
Best practices
- Number of Functions: The length of the list of functions specified to the model, directly impacts its performance. For best performance, keep the list of functions below 7. It’s possible to see some degradation in the quality of the model as the tool list length exceeds 10.
- Function Description: The function specification follows JSON Schema. For best performance, describe in great detail what the function does under the “description” section. An example of a good function description is “Get financial data for a company given the metric and year”. A bad example would be “Get financial data for a company”.
- System Prompt: In order to ensure optimal performance, we recommend not adding any additional system prompt. User-specified system prompts can interfere with the function detection & calling ability of the model. The auto-injected prompt for our function calling model is designed to ensure optimal performance.
- Temperature: Setting temperature to 0.0 or some low value. This helps the model to only generate confident predictions and avoid hallucinating parameter values.
- Function descriptions: Providing verbose descriptions for functions & its parameters. This is similar to prompt engineering: the more elaborate & accurate the function definition/documentation - the better the model is at deciphering the accurate intent of the function and its parameters.
Function calling vs JSON mode
When to use function calling vs JSON mode?
Use function calling when:
- Building interactive agents
- Requiring structured API calls
- Implementing multi-step workflows
- Needing dynamic decision making
Use JSON mode when:
- Performing simple data extraction
- Working with static data
- Needing non-JSON output formats
- Processing batch data without interaction
Example apps
- Official demos
- Langchain integrations
Resources
- Fireworks Blog Post on FireFunction-v2
- Open AI Docs on Function Calling
- Open AI Cookbook on Function Calling
- Function Calling Best Practices
Data policy
Data from Firefunction is logged and automatically deleted after 30 days to ensure product quality and to prevent abuse ( bulk data on average # functions used, etc). This data will never be used to train models. Please contact raythai@fireworks.ai if you have questions, comments, or use cases where data cannot be logged.
Was this page helpful?