Skip to main content
The Wixzel Voice MCP server lets Claude, Cursor or any MCP client build voice agents and place real phone calls over your own SIP trunk. It is the official Model Context Protocol server for Wixzel Voice, published as wixzel-voice-mcp. It puts every /v1 operation in front of an AI agent as a tool, 65 of them, with each tool annotated so the client knows which are read-only, which delete, and which spend money or ring a real phone. Those ask before they run. Two ways to use it: The console’s AI clients page at voice.wixzel.com/connect generates the exact commands below with a key already filled in.
Added it while the product was called Wixzel Phone? A connector pointing at https://mcp.phone.wixzel.com/mcp, and the wixzel-phone-mcp package up to 0.3.0, keep working; there is nothing to redo. New setups use the addresses on this page.

​
Claude Code

1

Add the server

With the hosted form, type /mcp in Claude Code and choose Authenticate. Your browser opens the console, you sign in, tick what the client may do, and Claude Code is connected. No key changes hands.
2

Let it set things up

The server ships three prompts, which Claude Code exposes as slash commands: quickstart connects a carrier, registers a number, builds an agent and places a first call, stopping before anything that dials; diagnose_call explains why a call failed from its record, usage events, trunk status and SIP logs; spend_report turns a period’s usage into dollars by component and by call.

​
Claude.ai and Claude Desktop

  1. Settings → Connectors → Add custom connector.
  2. Enter https://mcp.voice.wixzel.com/mcp and add it.
  3. Press Connect. You are sent to the console to sign in and approve the scopes the client may use.
  4. Approve. The client receives a key of its own; nothing is pasted anywhere.
Disconnect it at any time from AI clients in the console. The key stops working immediately.

​
Other clients

Clients that launch stdio servers from an mcpServers JSON config (Claude Desktop’s claude_desktop_config.json, Cursor and Windsurf) use the local form:
VS Code reads .vscode/mcp.json, which names the same server under a top-level servers key instead:
Clients that connect over HTTP but cannot do OAuth send a key as a bearer:

​
Scopes

An OAuth-connected client asks for a set of scopes, and you can untick any of them on the consent screen. A client that asks for nothing specific is offered the standard set for agents: everything under Agents, Calls, Telephony, Contacts, Knowledge & scheduling, plus usage:read and billing:read.
billing:write (start a top-up), api_keys:write (mint more keys) and phone_numbers:purchase (buy a number on your carrier account) are never offered by default. Grant them deliberately, if at all. There is no admin scope, and one cannot be created.
For a locally run server, the key you put in the environment decides what the agent can do. The console preselects the same standard set when you create one from the AI clients page.

​
Security

  • The token is a key. When a client signs in with OAuth, the API mints an ordinary scoped API key for that grant and hands it over as the access token. Nothing downstream needs to know OAuth happened; revoking the grant revokes the key. Because the token is valid against the API directly, it carries only the scopes you approved, and it is hidden from the ordinary key list so that the AI clients page is its one home.
  • PKCE only, S256 only. The authorization server refuses the plain method and any request without a code challenge. Redirect URIs match exactly against what the client registered; an unregistered one gets an error in place, never a redirect. A code is exchanged once and expires in a minute; a code presented with the wrong verifier burns the grant.
  • Money asks first. place_call, test_call_agent, start_campaign and create_topup are annotated as open-world and their descriptions tell the model to confirm with you. place_call, test_call_agent and create_topup send an idempotency key, generated when the model does not pass one. A retry is safe only when the client passes the same idempotency_key again, which the tool descriptions ask it to do; a retry with a new key dials again. start_campaign takes no key, and a second start while the campaign is running is refused. purchase_phone_number buys a number on your own carrier account, which your carrier bills. Its description tells the model to show you the number and the carrier’s price and buy only after you say yes. It always sends an idempotency key.
  • Nothing leaks through tools. SIP passwords are write-only. A minted key appears once, in the tool result that created it. The key the server itself runs with is never exposed through any tool or resource.
  • Errors are actionable. A failure returns the API’s machine-readable code, the request_id, and a hint: which scope is missing, that the balance is short, that a cursor was mangled.

​
Tools

Resources: wixzel://guide (the operating guide the server also sends as its instructions) and wixzel://connection (base URL and whether the key is live or test; never the key itself).

​
Are these docs available to coding agents over MCP?

Yes, from a second and separate server. These docs are also served by a read-only documentation MCP server at https://docs.voice.wixzel.com/mcp, which Mintlify hosts for this site. It searches and reads these pages, so a coding agent in Claude Code, Cursor or VS Code can look up an endpoint while it writes your integration. It has no access to your account: it cannot place a call, read a transcript or spend credit.
The page menu at the top of every docs page can also copy that address, or add it to Cursor or VS Code in one step.

​
Self-hosting

The package runs the hosted mode too:
A connector discovers sign-in on its own: a request without a bearer is answered 401 with WWW-Authenticate: Bearer resource_metadata="…", that document names https://api.voice.wixzel.com as the authorization server, and /.well-known/oauth-authorization-server there lists the endpoints.