Definition
Tool calling is when an LLM, instead of answering in words, returns a structured request to run a named function, such as looking up an order. The application runs it and gives the result back so the model can continue its reply.
How tool calling works
The LLM never runs anything itself. The developer describes each tool to the model with a name, a plain-language description and a schema for its parameters. During the conversation, the model can reply with a tool request that names a tool and fills in the parameters, for example get_order_status with an order number. The application checks the request, runs the function, and returns the result as a new message. The model then reads that result and writes the spoken reply.
In Cartesia’s documentation, the description of each tool is what guides the model on when to use it. Parameter values can come from three places: the model itself, a fixed constant, or a dynamic variable, such as the caller’s phone number. Managed Agents has built-in system tools such as end_call, send_dtmf, transfer_to_number and voicemail_detection, and custom tools that call your own webhook endpoint.
Three consequences follow from the design. The model chooses tools from the descriptions, so vague descriptions cause wrong or missing calls. The model supplies parameters, so values it invents must be validated by the receiving code. And the call is a round trip, so the model’s reply is paused until the result returns.
Why it matters for voice agents
Tool calls are what let an agent do work, such as booking an appointment or transferring a call, instead of only talking. They are also where the wait gets long. The tool’s response time lands inside voice latency, and a three second lookup is three seconds of silence on a phone line.
Voice agents therefore handle tool calls differently from chat. They speak before slow work, with a short line such as “Let me check that”. Cartesia’s system tools have a pre_tool_speech setting for this, with the values auto, force and off. They also need a plan for failure. If a tool times out or returns an error, the agent should say so and offer a next step, and never invent the answer. See hallucination.
Tools also carry risk. A tool that cancels a booking or moves money should sit behind checks that do not depend on the model’s judgment, such as a read-back and a confirmation from the caller, and permissions in the receiving system. A caller’s words can influence which tool the model calls, so the tool, not the prompt, should enforce what is allowed.
Example
An illustrative call:
- Caller: “Where’s my order? It’s 5521.”
- Agent: “Let me look that up.” (the model requests
get_order_statuswith order number 5521) - Tool result: shipped Tuesday, arriving Friday
- Agent: “It shipped Tuesday and should arrive Friday.”