Tool Calling

A voice agent without tools is a conversation. A voice agent with tools is an employee — it can look things up, create records, end the call, transfer to a human, send a confirmation, schedule a callback, or do anything else your APIs let it do.

This page is the mental model. Once you've read it, the rest of this section shows you the specific tool types and how to wire them up.

What "tool calling" actually means

During a call, the LLM's job isn't only to talk — it's also to decide whether the conversation needs an action. When the model decides yes, it emits a structured tool call instead of (or alongside) a spoken reply. Bolti executes that tool, captures the result, and feeds the result back to the LLM so the next reply is informed.

Concretely, every turn looks like this:

Caller: "Can you check if my order has shipped?"
   │
   ▼
[STT]  → "Can you check if my order has shipped?"
   │
   ▼
[LLM]  → "I should call check_order_status with order_id=42"
   │      ↳ tool call emitted
   ▼
[Bolti] → executes check_order_status(order_id=42)
   │      ↳ HTTP POST to your API
   │      ↳ response: { "status": "shipped", "tracking": "1Z..." }
   ▼
[LLM]  → "Yes — your order shipped yesterday. Tracking number is 1Z…"
   │
   ▼
[TTS]  → audio
   │
   ▼
Caller hears the answer.

The key insight: the LLM picks which tool to call based on the tool's name and description. You don't write rules. You write good descriptions and let the model choose.

Two kinds of tools in Bolti

Tools come in two flavors. You'll mix and match per agent.

1. Built-in tools

Operational primitives that Bolti ships with — they don't hit your APIs, they control the call itself. You enable them per agent on the Tools tab.

Today this includes:

Tool	What it does
cut_call	Hangs up the call cleanly when the caller asks to end it (or when the agent decides the conversation is done). Enabled by default on new agents.

More built-ins ship in the Custom Function Calls docs as they land.

2. Workspace HTTP tools

The interesting ones. A workspace HTTP tool is a configuration record that says: "when the agent decides to call this, hit this HTTP endpoint with these inputs."

You define each tool once per workspace, then assign it to whichever agents in that workspace should be able to call it. The same lookup_customer tool can be available to your support agent and your sales agent without duplicating its config.

A tool definition looks like this:

Field	What it's for
Name	The identifier the LLM sees. Use a verb-style snake_case name like lookup_customer.
Description	What the tool does, in 1–2 sentences. The model uses this to decide whether to call it. Spend time on this — it's the most important field.
URL & Method	Where Bolti sends the HTTP request and how (GET / POST / PUT / DELETE / PATCH).
Authorization	Static credentials Bolti attaches to outgoing requests (e.g. Bearer token, API key header).
Request headers	Static or templated headers attached to the request.
Request body	Static or templated body. Variables from the call (caller number, agent name, custom context) and from the LLM's chosen arguments can be interpolated.
Input schema	A JSON Schema describing what arguments the LLM needs to provide (e.g. order_id: string). The model is forced to fill this in before the tool runs.
Response schema	Optional JSON Schema describing the response shape. Helps the model interpret what came back.
Response path	A dot-path into the response to extract the relevant field. Useful when your API wraps results (e.g. data.order.status).
Timeout	Per-call timeout in milliseconds. Default is 15s; valid range is 1s–120s.
Active	A kill-switch you can flip without deleting the tool.

You can build, edit, and test these in the dashboard under Tools. Or define them via the API or the MCP server.

Full details: Workspace HTTP Tools.

How the LLM picks a tool

This is the part most people get wrong on the first try, so it's worth spelling out.

The LLM sees, for every assigned tool:

1. Name — short, verb-style, snake_case.
2. Description — what it's for, when to use it, when not to use it.
3. Input schema — what arguments it needs.

It does not see your URL, headers, or response shape. To the model, the tool is just a function it can call by name with arguments matching the schema.

That has practical implications:

• Write descriptions for the model, not for humans. "Looks up a customer's most recent order. Use this whenever the caller asks about an order, shipment, or delivery." — concrete, action-oriented, with hints about when to call.
• Mark required fields in the input schema. If order_id is required, the model will ask the caller for it instead of guessing.
• Don't give the agent too many tools. Five focused tools beats fifteen overlapping ones. With too many, the model loses the plot.
• Avoid overlapping tools. If you have both get_order and lookup_order, the model has to guess. Pick one.

If you want to force the model to call a tool at a certain point in the conversation, you do that through the system prompt in the agent's Basic settings, not through tool config. Tool config controls capability; the prompt controls behavior.

Variables and templating

Tool requests can reference values from the live call:

• The caller's phone number
• The agent's name and ID
• Any custom variables you passed when starting the call (outbound) or that came in via inbound metadata
• The arguments the LLM provided in the tool call

This means the same tool definition can do different things on different calls without you re-deploying anything. Details: Customizations → Context & Variables.

Testing before you ship

Every tool has a Test button in the dashboard that:

1. Resolves any templates against mock variables you supply
2. Sends the actual HTTP request to your endpoint
3. Shows you the request that went out, the response that came back, and the status code

This is the same code path the agent uses live, so if Test passes, the agent will see the same response. If your endpoint is wrong, you see the error here — not on a call with a real customer. Details: Testing Tools.

Common patterns

Most production agents use 3–6 tools. The most common shapes:

Pattern	Examples	Tool type
Lookup	check order status, find appointment, get account balance	HTTP, GET
Create	book an appointment, log a callback request, create a ticket	HTTP, POST
Update	reschedule, update address, mark as complete	HTTP, PUT/PATCH
Notify	send an SMS confirmation, fire a webhook to your CRM	HTTP, POST
Transfer	hand off to a human	Built-in
End	hang up cleanly	Built-in (cut_call)

The bigger your agent's role, the more lookups and creates it needs. The narrower the role, the fewer.

Where to go next

If you want to…	Read
Wire up your first HTTP tool end-to-end	Workspace HTTP Tools
Understand the call-control built-ins	Custom Function Calls, End Call
Test tools without making real calls	Testing Tools
Pass per-call data into tool requests	Context & Variables
Manage tools from Cursor or Claude Desktop	Bolti MCP Server

If you've never built a tool before, start with Workspace HTTP Tools and the Test button. It's the single fastest path from "I have an API" to "my agent can use it."