Skip to main content
Tool calls (tool_calls) let the Kimi large language model go beyond “talking” to “doing”: the model decides whether to call a tool based on the conversation context, generates the call arguments in JSON, and your application executes the tool and returns the result so the model can produce the final reply. With tool_calls, the Kimi large language model can help you search the internet, query databases, and even control smart home devices. This page walks through the full flow — defining, registering, and executing tools — with an internet-search example, plus notes for streaming and other scenarios.

The Complete Flow of a Tool Call

A tool call involves the following steps:
  1. Define the tool using JSON Schema format;
  2. Submit the defined tool to the Kimi large language model via the tools parameter. You can submit multiple tools at once;
  3. The Kimi large language model will decide which tool(s) to use based on the context of the current conversation. It can also choose not to use any tools;
  4. The Kimi large language model will output the parameters and information needed to call the tool in JSON format;
  5. Use the parameters output by the Kimi large language model to execute the corresponding tool and submit the results back to the Kimi large language model;
  6. The Kimi large language model will respond to the user based on the results of the tool execution;
If your application needs a large tool inventory (dozens or hundreds of tools), use Dynamically Loaded Tools to inject tool definitions on demand instead of submitting them all at once — this significantly reduces token usage and improves tool-selection accuracy.

Give the Model Internet Access with Tool Calls

The knowledge of the Kimi large language model comes from its training data, so it cannot answer time-sensitive questions from what it already knows. The example below uses two tools — a “search engine” and a “web browser” — to show how the model can search for the latest information and answer based on it.

Define Tools with JSON Schema

When people look up information online, they usually open a search engine (such as Baidu or Bing), browse the search results, and then open one or more result pages to get the knowledge they need. Abstracting these two actions into tools gives us a “search engine” and a “web browser” — described in JSON Schema and submitted to the Kimi large language model, so it can search and browse the web just like humans do. Tool definitions are written in JSON Schema format:
JSON Schema is a vocabulary that you can use to annotate and validate JSON documents. JSON Schema is a JSON document used to describe the format of JSON data.
We define the following JSON Schema:
This JSON Schema defines a JSON Object that contains a field named name, and the type of this field is string, for example:
By describing our tool definitions using JSON Schema, we can make it clearer and more intuitive for the Kimi large language model to understand what parameters our tools require, as well as the type and description of each parameter. Now let’s define the “search engine” and “web browser” tools mentioned earlier:
When defining tools using JSON Schema, we use the following fixed format:
Here, name, description, and parameters.properties are defined by the tool provider. The description explains the specific function and when to use the tool, while parameters outlines the specific parameters needed to successfully call the tool, including parameter types and descriptions. Ultimately, the Kimi large language model will generate a JSON Object that meets the defined requirements as the parameters (arguments) for the tool call based on the JSON Schema.

Register the Tools with the Model

Submit the search tool to the Kimi large language model and see if it can call the tool correctly:
The examples on this page use the latest model kimi-k3 by default. K3 uses the top-level reasoning_effort field (currently only "max"). To use another model such as kimi-k2.6 or kimi-k2.5, just replace the model field — parameter configurations differ across models. See the Model Parameter Reference.
When the above code runs successfully, we get the response from Kimi large language model:
Notice that in this response, the value of finish_reason is tool_calls, which means that the response is not the answer from Kimi large language model, but rather the tool that Kimi large language model has chosen to execute. You can determine whether the current response from Kimi large language model is a tool call tool_calls by checking the value of finish_reason. At this point the content field in message is empty, because the model is executing tool_calls and has not yet generated a reply for the user. The newly added tool_calls field is a list containing all the tool call information for this turn — which shows that the model can choose to call multiple tools at once, which can be different tools or the same tool with different parameters. Each element in tool_calls represents one tool call: the Kimi large language model generates a unique id for each call, uses function.name to indicate the name of the tool function, and places the call parameters in function.arguments (arguments is a valid serialized JSON Object; additionally, the type parameter is currently a fixed value function). Next, use the tool call parameters generated by the Kimi large language model to execute the corresponding tools.

Execute the Tools and Return the Results

The Kimi large language model does not execute tools for you — once you receive the parameters it generates, your application must execute them. Why can’t the model execute tools itself? Imagine a typical scenario: you provide users with a smart robot based on the Kimi large language model. In this scenario, there are three roles: the user, the robot, and the Kimi large language model. The user asks the robot a question, the robot calls the Kimi large language model API, and returns the API result to the user. When using tool_calls, the user asks the robot a question, the robot calls the Kimi API with tools, the Kimi large language model returns the tool_calls parameters, the robot executes the tool_calls, submits the results back to the Kimi API, the Kimi large language model generates the message to be returned to the user (finish_reason=stop), and only then does the robot return the message to the user. The entire tool_calls process is transparent and implicit to the user: users never directly “see” the tool calls, only the final reply presented by the robot. The full example below executes the tool_calls returned by the Kimi large language model from the perspective of the “robot”, demonstrating the tool-execution loop:
We use a while loop to execute the code logic that includes tool calls because the Kimi large language model typically doesn’t make just one tool call, especially in the context of online searching. Usually, Kimi will first call the search tool to get search results, and then call the crawl tool to convert the URLs in the search results into actual web page content. The overall structure of the messages is as follows:
This completes the entire process of making “online query” tool calls. If you have implemented your own search and crawl methods, when you ask Kimi to search online, it will call the search and crawl tools and give you the correct response based on the tool call results.

Handle tool_calls in Streaming Output

In streaming output mode (stream), tool_calls work as well, but there are a few extra things to note:
  • During streaming output, since finish_reason will appear in the last data chunk, it is recommended to check if the delta.tool_calls field exists to determine if the current response includes a tool call;
  • During streaming output, delta.content will be output first, followed by delta.tool_calls, so you must wait until delta.content has finished outputting before you can determine and identify tool_calls;
  • During streaming output, we will specify the tool_call.id and tool_call.function.name in the initial data chunk, and only tool_call.function.arguments will be output in subsequent chunks;
  • During streaming output, if Kimi returns multiple tool_calls at once, we will use an additional field called index to indicate the index of the current tool_call, so that you can correctly concatenate the tool_call.function.arguments parameters. We use a code example from the streaming output section (without using the SDK) to illustrate how to do this:
Below is an example of handling tool_calls in streaming output using the openai SDK:

Use tool_calls Instead of function_call

tool_calls evolved from function calls (function_call), and function_call is a subset of tool_calls — in certain contexts, or when reading compatibility code, you can treat the two as equivalent. Since OpenAI has marked function_call and related parameters (such as functions) as “deprecated”, our API will no longer support function_call; use tool_calls instead. Compared to function_call, tool_calls has the following advantages:
  • It supports parallel calls. The Kimi large language model can return multiple tool_calls at once. You can use concurrency in your code to call these tool_call simultaneously, reducing time consumption;
  • For tool_calls that have no dependencies, the Kimi large language model will also tend to call them in parallel. Compared to the original sequential calls of function_call, this reduces token consumption to some extent;

Notes

  • When finish_reason=tool_calls, message.content is occasionally not empty: it is usually the Kimi large language model explaining which tools it needs to call and why. If your tool call process takes a long time, or a single turn requires several sequential tool calls, this descriptive message can reduce the anxiety or dissatisfaction users feel while waiting, and helps them understand the tool call flow and intervene and correct in time (for example, terminating an incorrect tool call, or correcting the model’s tool selection with a prompt in the next turn);
  • The content in the tools parameter is also counted in the total Tokens. Please ensure that the total number of Tokens in tools and messages does not exceed the model’s context window size.

Keep Every tool_call Matched to a tool Message

In tool call scenarios, messages are no longer a simple alternation of system / user / assistant:
Instead, they look like this:
When the Kimi large language model generates tool_calls, make sure every tool_call has a corresponding message with role=tool, and that this message carries the correct tool_call_id: if the number of role=tool messages does not match the number of tool_calls, an error will occur; likewise, if the tool_call_id in a role=tool message cannot be matched with the tool_call.id in tool_calls, an error will occur.

Troubleshoot the tool_call_id not found Error

If you encounter the tool_call_id not found error, it may be because you did not add the role=assistant message returned by the Kimi API to the messages list. The correct message sequence should look like this:
You can avoid the tool_call_id not found error by executing messages.append(message) each time you receive a return value from the Kimi API, to add the message returned by the Kimi API to the messages list. Note: Assistant messages added to the messages list before the role=tool message must fully include the tool_calls field and its values returned by the Kimi API. We recommend directly adding the choice.message returned by the Kimi API to the messages list “as is” to avoid potential errors.