Callmcp

ai.callmcpPublished by callmcp.aiv0.1.2Updated Nov 10, 2026

One MCP tool contract for telephony — any call provider, hosted, local, or BYOK.

VerifiedSTDIODesktop onlyDeveloper ToolsCommunication & Collaboration

Overview

AI-generated overview

Gives an assistant one provider-neutral tool contract for telephony: calls, SMS, recordings, transcripts, and phone-number provisioning.

What you can do
CallMCP exposes a single set of 14 tools with identical schemas for outbound and inbound telephony: placing and ending calls, sending SMS, retrieving recordings and transcripts, and searching, buying, configuring, and listing phone numbers. The same contract is served by different backends (hosted, local, or bring-your-own-key), so switching providers is a configuration change rather than a rewrite. Tools are capability-gated per driver: a tool either exists and works, or is absent from the tool list. Outbound actions that contact an external number require an approval identifier or a standing allowlist match.
When to use it
Use it when an assistant should place calls, send SMS, or manage phone numbers through a stable tool interface, and when you want to change call backends without changing agent code. It also fits workflows that need call recordings, transcripts, or number provisioning handled by the assistant.
Requirements
Runs locally as a Node.js process, started with npx from the npm package @callmcp/server. Configuration comes from a callmcp.config.json file whose path is set in CALLMCP_CONFIG, or entirely from environment variables if that is omitted; CALLMCP_DEFAULT_DRIVER selects the driver used when a tool call omits one. A configured driver is required — the server fails closed without one, and the mock driver is only available through explicit sandbox configuration. Provider accounts or keys are needed…
Before you install
Number provisioning tools (search, buy, configure, list) are not approval-gated and can spend real money autonomously, including settling cost through x402 machine payments when a driver requires prepayment. Outbound calls and SMS require an approval identifier or allowlist match, and the fallback approval path uses a single-use out-of-band URL. Recordings and transcripts of calls are retrieved through the server, so consider consent and data handling. Provider credentials are supplied through…

Installation

In SourceWeft

  1. Open Callmcp in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

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

[License: MIT] [GitHub stars]

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

Before connecting a real provider, run npx -y @callmcp/server doctor. For a safe local walkthrough, run npx -y @callmcp/server --sandbox. The server fails closed when no driver is configured; the mock driver is only available through explicit sandbox configuration.

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

CapabilityCallMCPVapi MCPTelnyx MCPAgentPhone MCPDIY (Twilio + your own glue)
Tool contractOne schema, 14 tools, portable across backendsSingle-vendor, Vapi onlySingle-vendor, Telnyx onlySingle-vendor, AgentPhone onlyNo contract — you write and maintain it
Swap call backend without rewriting agent codeYes — driver swap onlyNoNoNoNo
Self-hostable / fully local optionYes (Dograh driver)(unverified, recheck before publishing)(unverified, recheck before publishing)(unverified, recheck before publishing)Yes, but you own the entire stack
Bring your own frontier model as the call's "brain"Yes (BYOK driver: any transport + any LLM)(unverified, recheck before publishing)(unverified, recheck before publishing)(unverified, recheck before publishing)Yes, fully manual integration
Autonomous, funded, production-scoped number provisioning (x402)Yes — search_numbers/buy_number/configure_number ungated, x402-payable(unverified, recheck before publishing)Public self-serve docs read as trial-scoped autonomy, not funded production autonomy (unverified, recheck before publishing)(unverified, recheck before publishing)No — manual console purchase, manual compliance
Outbound approval / consent gate structural in the schemaYes — make_call/send_sms require approval_id or allowlist match, enforced server-side(unverified, recheck before publishing)(unverified, recheck before publishing)(unverified, recheck before publishing)No — you build and maintain your own gate
Standalone SMS (not agent-mediated only)Capability-gated per driver, honestly reported — never claimed where it's actually agent-mediated(unverified, recheck before publishing)Yes, native(unverified, recheck before publishing)Yes, native Twilio API
Call recordingCapability-gated per driver, honestly reported(unverified, recheck before publishing)(unverified, recheck before publishing)(unverified, recheck before publishing)Yes, native Twilio API
Real-time transcript streamingCapability-gated per driver, subscribable resource when supported(unverified, recheck before publishing)(unverified, recheck before publishing)(unverified, recheck before publishing)DIY — you build the capture/assembly layer
Source availabilityMIT-licensed server + Apache-2.0 spec, public monorepo(unverified, recheck before publishing)(unverified, recheck before publishing)(unverified, recheck before publishing)N/A — it's your own code
Markup over underlying carrier costZero in the OSS server — it routes at cost; KaiCalls hosted tier is an optional convenience layer, not a requirement(unverified, recheck before publishing)(unverified, recheck before publishing)(unverified, recheck before publishing)Zero markup, 100% of integration cost is yours

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)

Capabilitykaicalls (hosted)dograh (local)twilio_openai (BYOK)
make_call / end_call (hangup)Yes — hangup via Vapi controlUrl, treated as call-scoped statemake_call yes; no external hangup endpoint (supports_hangup: false)Yes, native Twilio call control
search_numbers / buy_number / configure_numberYesNo purchase flow — BYO carrier account (supports_number_purchase: false)Yes, native Twilio number API
send_smsCapability-gated on the underlying Vapi-class backend; not claimed unless a real standalone send path existsNo SMS capabilityYes, native Twilio SMS
get_recordingYes, once wiredCapability-dependent on the local stackYes, native Twilio recording
get_transcript / realtime streamingYesYes, baseline (Dograh's GET /{workflow_id}/runs/{run_id} returns transcript_url — the one fully source-verified transcript path in the wider landscape)DIY assembly from realtime session events; supports_realtime_transcription only claimed once that assembly is genuinely live

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

Tool / capabilityKnown gaps at spec-writing time
buy_numberAbsent on Synthflow (UI-only, no API), ElevenLabs (BYO-number only), Dograh (BYO carrier), Phonely (not independently drivable)
end_callAbsent on Retell and Synthflow (no hangup endpoint); Dograh has no external hangup endpoint; Vapi supports it only via a per-call ephemeral controlUrl, not a stable REST endpoint
send_smsThe most degraded tool in the whole contract. Only Telnyx, Bland, Autocalls, and Thoughtly expose real standalone SMS. Vapi/Retell/Synthflow are agent-mediated only (not a stable API surface, never claimed as supports_sms: true). Millis, Vogent, and Dograh have no SMS capability at all. AgentLine's own public materials contradict themselves on this (SKILL.md forbids SMS while its API spec defines POST /v1/messages) — cited as unresolved upstream, not resolved on AgentLine's behalf
get_recordingAbsent on AgentLine entirely; LiveKit-based backends require standing up a separate Egress service before it's real
get_transcript (realtime)LiveKit/Pipecat-local stacks require DIY event capture; Bolna's transcript endpoint is unconfirmed; Telnyx's exact transcript route is unverified

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

PackagenpmWhat it is
@callmcp/servernpmThe MCP server core — start here if you're running CallMCP.
@callmcp/driver-interfacenpmThe Driver contract, capability manifest types, conformance harness. Start here if you're writing a new driver.
@callmcp/driver-kaicallsnpmHosted default — KaiCalls' production telephony backend.
@callmcp/driver-dograhnpmFully local — wraps a self-hosted Dograh instance.
@callmcp/driver-byoknpmBring-your-own-key — Twilio transport + OpenAI Realtime (or wire-compatible) brain.

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.

Source: README.md at commit 613339b

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v0.1.2LatestSep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts