Call MCP Server

One MCP server. Any call provider. Fully local, fully hosted, or bring your own frontier model.

CallMCP is a single Model Context Protocol server that defines one tool contract — 14 tools, identical schemas, identical error shapes — for outbound/inbound telephony: calls, SMS, recordings, transcripts, and phone-number lifecycle. Point it at a hosted backend, a fully local backend, or a bring-your-own-key composed backend, and your agent code doesn't change. What changes is which tools are present (via capability-gated dynamic discovery), never the shape of a tool that's there.

The normative reference is SPEC.md. This README is the pitch; the spec is the contract.

npx -y @callmcp/server

See examples/ for ready-to-paste Claude Desktop / Claude Code configs for each of the three legs below.

---

Three structural claims

This isn't "a Twilio wrapper with a marketing page." Three things are actually built into the contract, not bolted on:

1. Provider-neutral, multi-backend contract

Every driver — hosted, local, or BYOK — implements the same 14 tools defined in SPEC.md. Driver-specific behavior lives exclusively inside a namespaced options.<driver_id> passthrough object. There is no make_call_twilio or make_call_kaicalls. A tool either exists for your configured driver (and works, fully, per spec) or it's absent from tools/list — never present-but-broken. Swapping your call backend is a config change, not a rewrite.

2. x402-funded autonomous provisioning to production

search_numbers, buy_number, configure_number, and list_numbers are never human-approval-gated — they don't contact a third party, they contact your own provider account. That includes settling cost via x402 machine payments when a driver requires prepayment (INSUFFICIENT_FUNDS embeds a full x402 challenge an agent can settle and retry). An agent can search for a number, pay for it, configure it, and go live — autonomously, in production, with real money — without a human clicking anything. This is a deliberate contrast with vendor MCPs whose autonomous/self-serve paths are trial- or sandbox-scoped only.

3. Human-in-the-loop outbound approval as designed consent architecture

make_call and send_sms — anything that contacts a phone number that isn't the calling agent's own infrastructure — structurally require a valid approval_id or a standing allowlist match before they act. This isn't a policy suggestion layered on top; it's enforced in the server core, so no driver implementation can bypass it. Primary path is MCP elicitation; the fallback for non-elicitation clients is a single-use out-of-band approval URL — the gate is designed to never silently block forever and never silently open. Read as a TCPA-consent posture: the contract makes "who approved contacting this number, and when" a first-class, auditable object (request_call_approval / list_approvals), not an assumption baked into application code you have to get right yourself.

---

CallMCP vs. single-vendor MCPs vs. DIY

Every "(unverified, recheck before publishing)" cell is a placeholder, not a claim — we do not put a number or a fact about a competitor's product in this table without a citation behind it. If you're reading this before that recheck has happened, treat those cells as unknown, not as "no."

---

Who builds this, and what's actually free

CallMCP is built and maintained by CallMCP / KaiCalls. Full transparency, because hiding this costs more credibility than stating it:

• This OSS server is not a loss-leader funnel with the real functionality locked behind a paywall. It routes to any configured driver — hosted, local, or BYOK — with no markup and no artificial capability gating. A self-hosted Dograh driver or a BYOK Twilio+LLM driver gets the exact same 14-tool contract as the KaiCalls driver.
• KaiCalls is the hosted default — the path of least resistance if you want a call backend running in minutes with nothing to self-host. It is not the only supported path, and the spec and conformance suite exist precisely so that claim stays true as the driver ecosystem grows.
• The driver interface is public and the conformance suite runs in CI. Any driver — including ones we didn't write — can claim conformance, and community PRs are held to the same bar KaiCalls' own driver is held to (see SPEC.md §6).

If any of the above stops being true, that's a bug in this README, not a hidden asterisk — open an issue.

---

Driver capability matrix

Capability is expressed by presence, not by runtime errors (see SPEC.md §2.2). This table mirrors the spec's degradation appendix (SPEC.md §7) — the honest state of the wider backend landscape at spec-writing time (2026-07-09), not a ceiling on what CallMCP itself can do.

Launch drivers (this repo)

Known gaps across the wider backend landscape (context for driver authors)

A driver claiming a capability it can't demonstrate against the conformance suite fails CI (see SPEC.md §6.2) — this table is a snapshot, not a promise about backends CallMCP doesn't control, and any driver author whose backend's real capability differs from this snapshot updates their own manifest, not this README.

---

Repo shape

callmcp/callmcp
├── SPEC.md                   canonical tool contract (start here)
├── packages/
│   ├── server/                @callmcp/server — MCP core: transports, driver
│   │                          registry, config resolution, approval state
│   │                          machine, elicitation + fallback-URL flow,
│   │                          dynamic tools/list
│   ├── driver-interface/      @callmcp/driver-interface — TS interface,
│   │                          capability manifest types, conformance test harness
│   ├── driver-kaicalls/       hosted default driver
│   ├── driver-dograh/         local/self-hosted driver
│   └── driver-byok/           bring-your-own transport + bring-your-own LLM
├── examples/                  Claude Desktop / Claude Code config blocks per leg
├── server.json                official MCP Registry manifest — published as
│                              ai.callmcp/server (registry.modelcontextprotocol.io)
├── smithery.yaml               Smithery container deployment config
└── Dockerfile                  self-host / Smithery container build

Packages

Contributing a driver

Implement the interface in @callmcp/driver-interface, ship a callmcp.manifest.json per SPEC.md §6.1, and run the conformance suite. A capability your manifest doesn't claim true simply results in that tool being absent from tools/list — that's the whole mechanism, not a workaround.

License

MIT for this repository's code. SPEC.md is released under Apache-2.0 as documented in its own header, specifically so anyone can implement a conformant driver without asking permission.