Bolti MCP Server

Bolti ships an official Model Context Protocol (MCP) server that exposes most of the platform — agents, tools, phone numbers, calls, conversations, billing — as tools that an LLM in your editor can call directly.

Hooked up to Cursor or Claude Desktop, it means you can stay in your editor and say things like:

"Show me the last 10 calls for the support agent and pull the transcript of any one over 3 minutes."

"Create a tool called lookup_order pointing at https://api.acme.com/orders/{id}, assign it to my support agent, and run a test."

"Place an outbound call from the sales agent to +14155551212."

The model figures out which Bolti API calls to make. You confirm. It runs. This is Bolti's main differentiator vs. similar voice-AI platforms — the MCP surface is treated as a first-class control plane, not an afterthought.

What MCP is, briefly

MCP is an open protocol for letting LLM clients (Cursor, Claude Desktop, etc.) talk to external "tool servers" over a standard interface. A tool server exposes a set of named tools with input schemas; the client's LLM picks which to call and with what arguments. Same underlying idea as tool calling inside a Bolti agent, but applied to Bolti itself.

You don't need to know the protocol details to use the Bolti MCP server. You just install it, point your editor at it, and start asking questions in chat.

What you can do with it

The server registers around 40 tools grouped into the following surfaces:

Surface	What it covers
Auth	Log in with a token, list / create / revoke MCP personal access tokens, see who you're authenticated as.
Agents	List, get, create, update, delete agents. Pull agent configuration options (LLMs, voices, languages). Manage share-links for browser previews.
Tools	List, create, update, delete workspace HTTP tools. Test a tool with mock variables. Assign or unassign tools on an agent.
Calls & conversations	List calls, fetch a single call, get a signed recording playback URL, browse an agent's conversation history, pull the transcript of any conversation.
Phone numbers	List assigned numbers, list available DIDs from your provider, assign a number to an agent for inbound, remove a number.
SIP	List, create, delete inbound and outbound SIP trunks; place an outbound call to a number.
Settings	List workspaces in an org, get/update workspace settings, list members, fetch supported models, see workspace credit balance.
System	A system_health tool that pings the backend and reports MCP version.

Full reference list of tool names: Available Tools.

Why this is different

Most platforms hand you a REST API and a dashboard. The MCP server gives you a third surface that's especially good for:

• One-off operational tasks — "rotate the API key on tool X for every agent in the workspace"
• Agent iteration loops — "show me the system prompt, change the greeting to be warmer, save it"
• Reading data — pulling transcripts, recordings, or call lists into your current chat for analysis
• Automating multi-step flows — "for each agent, list its assigned tools, dedupe by name, report"

Anything you'd otherwise click through the dashboard for, or write a small script for, the MCP server can usually do in one chat turn.

Smart defaults: workspace and org auto-resolution

You don't have to remember UUIDs. When the MCP server has an active session, it automatically:

• Fills in org_id from the user's default organization
• Fills in workspace_id from the user's default workspace, or the only workspace if there's exactly one in the org

So a tool call like agents_list works with no arguments — it lists agents in your default workspace. You only need to supply IDs when you want to act in a different workspace or organization than your default.

If a tool call still requires a UUID (e.g. an agent_id for a get-agent call), the server returns a clear VALIDATION_ERROR listing exactly which fields are missing.

A small ergonomic touch: agent creation

Creating an agent normally requires choosing an LLM provider/model, a TTS voice, an STT model, and so on. The agent_create tool fetches your workspace's available options and fills in sensible defaults for any field you didn't specify. Practically, this means you can say:

"Create a new agent called Customer Support with greeting 'Hi, this is Bolti support.'"

…and you get back a fully-configured agent with default LLM, voice, and STT picked from what your workspace supports. You can override anything by passing it explicitly.

Authentication

The MCP server needs a Bolti access token to do anything beyond system_health. You have two paths:

1. Personal access token (recommended for personal use)

Generate a long-lived Personal Access Token from the dashboard (profile -> Access Tokens -> Create Token). Creating it in the dashboard is recommended - the value is shown only once, so you can copy it safely. You can also mint one from chat with token_create:

> Use token_create to make a token named "cursor-laptop"

Save the token; configure the MCP server to use it via the BOLTI_API_TOKEN env variable so your editor session is authenticated automatically on launch.

Details: Personal Access Tokens.

2. One-shot login

Call login_with_token from chat with a token you paste in. The session is held in memory until the MCP process exits.

Tokens are scoped to the user that created them — they pick up your org and workspace memberships automatically. Check who you're authenticated as with whoami, and revoke any time with token_revoke.

Safety

The MCP server is designed so that a model acting on your behalf cannot do harm you didn't intend:

• Confirmation gating. Read tools and write tools are separate. Destructive or billed tools (deletes, outbound_call_start, workspace_update, and similar) require an explicit confirm: true. Without it they return a CONFIRMATION_REQUIRED error so your client can check with you first.
• Write-only secrets. Credentials such as tool authorization values and SIP trunk passwords can be set but never read back - read tools return a redacted placeholder.
• Workspace scoping and roles. All access is enforced by the Bolti backend against your token's workspace membership and role. A read-only (viewer) member cannot create, update, or delete resources or place calls, and a workspace-scoped token cannot reach any other workspace.
• Rate limits. Write and call-initiating tools are rate-limited.

See Personal Access Tokens for how token scope shapes all of this.

Configuration

The server is a standard stdio MCP process. Configure it via environment variables:

Variable	Default	Purpose
BOLTI_API_TOKEN	(none)	Personal Access Token starting with mcp_. Required unless you use login_with_token.
BOLTI_API_BASE_URL	https://api.bolti.co.in	Backend the server talks to. Override only for self-hosted or staging.
BOLTI_TOOL_TIMEOUT_MS	15000	Per-tool HTTP timeout against the Bolti backend.
BOLTI_MAX_PAGE_SIZE	100	Upper cap for paginated list responses.
BOLTI_DEFAULT_PAGE_SIZE	20	Default page size when a list tool is called without one.

For the actual installation steps for Cursor and Claude Desktop, see Installation.

Compared to the REST API

You can do everything the MCP server does via the REST API. The MCP server is a thin, typed proxy on top of the same endpoints, with a few quality-of-life additions:

	MCP	REST
Best for	Conversational ops, in-editor work, exploration	Programmatic integrations, your own services
Auth	Personal MCP tokens	User JWTs or service tokens
Workspace scoping	Auto-resolved from session	You pass it on every request
Agent defaults	Auto-filled on create	You pass everything
Long-lived	Lives as long as your editor's MCP session	Standard request/response

If you're building an integration that runs on a server, use the REST API. If you're a human doing operational work, use the MCP.

Where to go next

If you want to…	Read
Install the server in Cursor or Claude Desktop	Installation
Manage your access tokens	Personal Access Tokens
See the full tool reference	Available Tools
Get inspired with concrete prompts	Use Cases

If this is your first time, start with Installation. You'll be running tools from chat in about five minutes.