callmcp

一个 MCP 服务。支持任意通话提供商。完全本地、完全托管，或接入你自己的前沿模型。

CallMCP 是一个 Model Context Protocol 服务，为外呼/来电电话服务定义了一套工具契约——共 14 个工具，拥有相同的架构和错误格式，涵盖通话、短信、录音、转录文本和电话号码生命周期。将它连接到托管后端、完全本地的后端，或由你自带密钥的组合式后端，你的 Agent 代码无需更改。变化的只是可用的工具（通过基于能力的动态发现），而非已提供工具的形式。

规范性参考文档是 SPEC.md。本 README 介绍项目；规范才是契约。

npx -y @callmcp/server

连接真实提供商之前，请运行 npx -y @callmcp/server doctor。 如需安全的本地演示，请运行 npx -y @callmcp/server --sandbox。 未配置驱动程序时，服务会采取故障关闭机制；模拟驱动程序仅在显式配置沙盒后才可用。

参见 examples/，其中提供了适用于下文三种模式的 Claude Desktop / Claude Code 配置，可直接粘贴使用。

---

三项结构性主张

这不是“带营销页面的 Twilio 封装”。以下三项特性都内置于契约中，而非事后拼装：

1. 提供商中立的多后端契约

每个驱动程序——托管、本地或 BYOK——都实现 SPEC.md 中定义的同一套 14 个工具。驱动程序特有的行为仅通过命名空间 options.<driver_id> 透传对象实现。不存在 make_call_twilio 或 make_call_kaicalls。对于你配置的驱动程序，某个工具要么存在且完全符合规范地正常工作，要么就不会出现在 tools/list 中——绝不会出现存在却无法工作的情况。切换通话后端只需更改配置，无需重写代码。

2. 通过 x402 资助自主开通并投入生产

search_numbers、buy_number、configure_number 和 list_numbers 从不要求人工审批——它们联系的不是第三方，而是你自己的提供商账户。这也包括在驱动程序要求预付款时通过 x402 机器支付结算费用（INSUFFICIENT_FUNDS 会附带完整的 x402 挑战，Agent 可完成结算后重试）。Agent 可以自主搜索号码、付款、配置号码并上线——在生产环境中使用真实资金，全程无需人工点击。与某些厂商的 MCP 不同，这里有意提供了这一能力；那些 MCP 的自主/自助服务路径仅限试用或沙盒环境。

3. 将人工参与的外呼审批设计为同意架构

make_call 和 send_sms——任何会联系非通话 Agent 自有基础设施上的电话号码的操作——在执行前都必须具备有效的 approval_id，或匹配常设允许列表。这不是叠加在上层的策略建议，而是由服务核心强制执行，因此任何驱动程序实现都无法绕过。首选路径是 MCP 询问；对于不支持询问的客户端，备用方案是一次性带外审批 URL——该机制旨在既不会悄无声息地永久阻塞，也不会悄无声息地放行。可将其视为一种符合 TCPA 同意要求的设计：契约将“谁在何时批准联系此号码”设为一等、可审计的对象（request_call_approval / list_approvals），而不是假定应用代码会自行正确处理。

---

CallMCP 与单一供应商 MCP 和 DIY 方案的比较

能力	CallMCP	Vapi MCP	Telnyx MCP	AgentPhone MCP	DIY（Twilio + 自己编写的胶水代码）
工具契约	一个架构、14 个工具，可跨后端移植	单一供应商，仅支持 Vapi	单一供应商，仅支持 Telnyx	单一供应商，仅支持 AgentPhone	没有契约——由你编写并维护
无需重写 Agent 代码即可更换通话后端	可以——只需更换驱动	不可以	不可以	不可以	不可以
可自托管／完全本地运行选项	可以（Dograh 驱动）	（未核实，发布前重新检查）	（未核实，发布前重新检查）	（未核实，发布前重新检查）	可以，但整个技术栈都由你负责
使用你自己的前沿模型作为通话的“核心”	可以（BYOK 驱动：任意传输方式 + 任意大模型）	（未核实，发布前重新检查）	（未核实，发布前重新检查）	（未核实，发布前重新检查）	可以，但需要完全手动集成
自主、已注资、面向生产环境的号码配置（x402）	可以——search_numbers/buy_number/configure_number 无门槛，支持 x402 付款	（未核实，发布前重新检查）	公开的自助服务文档显示的是试用范围内的自主配置，而非已注资的生产环境自主配置（未核实，发布前重新检查）	（未核实，发布前重新检查）	不可以——需手动在控制台购买、手动完成合规流程
架构中是否内置外呼审批／同意门槛	是——make_call/send_sms 要求提供 approval_id 或匹配允许列表，由服务端强制执行	（未核实，发布前重新检查）	（未核实，发布前重新检查）	（未核实，发布前重新检查）	不可以——需自行构建并维护门槛
独立短信（不局限于由 Agent 代发）	按驱动提供的能力设门槛，如实报告——实际由 Agent 代发时绝不声称支持独立短信	（未核实，发布前重新检查）	支持，原生功能	（未核实，发布前重新检查）	支持，Twilio 原生 API
通话录音	按驱动提供的能力设门槛，如实报告	（未核实，发布前重新检查）	（未核实，发布前重新检查）	（未核实，发布前重新检查）	支持，Twilio 原生 API
实时转录流	按驱动提供的能力设门槛；支持时可订阅资源	（未核实，发布前重新检查）	（未核实，发布前重新检查）	（未核实，发布前重新检查）	DIY——需自行构建采集／组装层
源码可用性	MIT 许可的服务 + Apache-2.0 规范，公开的单体仓库	（未核实，发布前重新检查）	（未核实，发布前重新检查）	（未核实，发布前重新检查）	不适用——这是你自己的代码
在底层运营商成本上的加价	开源服务不加价——按成本路由；KaiCalls 托管层是可选的便利服务，并非必需	（未核实，发布前重新检查）	（未核实，发布前重新检查）	（未核实，发布前重新检查）	不加价，集成成本全部由你承担

每个“（未核实，发布前重新检查）”单元格都是占位内容，并非断言——没有可靠引文支持时，我们不会在此表中填写关于竞品产品的数字或事实。如果你在重新检查完成前阅读本文，请将这些单元格视为未知，而不是“否”。

---

谁在构建它，哪些功能真正免费

CallMCP 由 CallMCP / KaiCalls 构建并维护。我们完全透明地说明这一点，因为隐瞒这件事比直接说明更损害信誉：

• 这个开源服务器不是用来引流的诱饵，真正的功能也没有被锁在付费墙后。 它会路由到任何已配置的驱动程序——托管、本地或 BYOK——不加价，也不会人为限制功能。自托管的 Dograh 驱动程序或 BYOK Twilio+LLM 驱动程序，获得的 14-tool 契约与 KaiCalls 驱动程序完全相同。
• KaiCalls 是默认托管选项——如果你想在几分钟内运行通话后端，且无需自托管任何内容，这是阻力最小的路径。它并非唯一受支持的路径；我们制定规范和一致性测试套件，正是为了确保随着驱动程序生态的发展，这一说法始终成立。
• 驱动程序接口是公开的，一致性测试套件会在 CI 中运行。 任何驱动程序——包括并非由我们编写的驱动程序——都可以声明符合规范；社区 PR 也必须达到与 KaiCalls 自有驱动程序相同的标准（参见 SPEC.md §6）。

如果上述任何一点不再成立，那就是这份 README 的问题，而不是隐藏的附加条件——请提交 issue。

---

驱动程序功能矩阵

功能通过是否存在来表示，而不是通过运行时错误来表示（参见 SPEC.md §2.2）。此表与规范中的降级附录一致（SPEC.md §7）——它反映的是编写规范时（2026-07-09）更广泛的后端生态的实际情况，并非 CallMCP 自身能力的上限。

首发驱动程序（本仓库）

功能	kaicalls（托管）	dograh（本地）	twilio_openai（BYOK）
make_call / end_call（挂断）	是——通过 Vapi controlUrl 挂断，并作为通话范围内的状态处理	make_call 支持；没有外部挂断端点（supports_hangup: false）	是，使用 Twilio 原生通话控制
search_numbers / buy_number / configure_number	是	不支持号码购买流程——需自带运营商账户（supports_number_purchase: false）	是，使用 Twilio 原生号码 API
send_sms	取决于底层 Vapi 类后端的能力；只有在存在真正独立的发送路径时才会声明支持	不支持 SMS 功能	是，使用 Twilio 原生 SMS
get_recording	是，接入后即可使用	取决于本地技术栈的能力	是，使用 Twilio 原生录音
get_transcript / 实时流式传输	是	是，基础支持（Dograh 的 GET /{workflow_id}/runs/{run_id} 会返回 transcript_url——这是更广泛生态中唯一经过完整源码验证的转录路径）	通过实时会话事件自行组装；只有在该组装流程确实已运行时，才会声明支持 supports_realtime_transcription

更广泛后端生态中的已知差距（供驱动作者参考）

工具 / 能力	编写规范时已知的差距
buy_number	Synthflow（仅提供 UI，没有 API）、ElevenLabs（仅支持自带号码）和 Dograh（需自带运营商）不提供；Phonely 无法独立驱动
end_call	Retell 和 Synthflow 不提供（没有挂断端点）；Dograh 没有外部挂断端点；Vapi 仅通过每次通话临时生成的 controlUrl 支持，不提供稳定的 REST 端点
send_sms	整个契约中退化最严重的工具。只有 Telnyx、Bland、Autocalls 和 Thoughtly 提供真正独立的 SMS。Vapi、Retell 和 Synthflow 只能通过 Agent 发送（不是稳定的 API 接口，绝不会声称 supports_sms: true）。Millis、Vogent 和 Dograh 完全不具备 SMS 能力。AgentLine 自己的公开资料对此说法相互矛盾（SKILL.md 禁止发送 SMS，但其 API 规范定义了 POST /v1/messages）——此问题被列为上游尚未解决的问题，不代表已替 AgentLine 作出结论
get_recording	AgentLine 完全不提供；基于 LiveKit 的后端需要先部署独立的 Egress 服务才能真正提供此能力
get_transcript（实时）	LiveKit / Pipecat 本地栈需要自行捕获事件；Bolna 的转录文本端点尚未确认；Telnyx 的确切转录文本路由尚未验证

若驱动声称具备某项能力，却无法通过一致性测试套件验证，将无法通过 CI（参见 SPEC.md §6.2）——此表只是当前快照，并非对 CallMCP 无法控制的后端作出的承诺。任何后端实际能力与此快照不符的驱动作者，都应更新自己的清单，而不是本 README。

---

仓库结构

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

包

包	npm	说明
@callmcp/server	npm	MCP 服务核心——运行 CallMCP 时从这里开始。
@callmcp/driver-interface	npm	Driver 契约、能力清单类型、一致性测试框架。编写新驱动时从这里开始。
@callmcp/driver-kaicalls	npm	托管默认选项——KaiCalls 的生产级电话后端。
@callmcp/driver-dograh	npm	完全本地化——封装自托管的 Dograh 实例。
@callmcp/driver-byok	npm	自带密钥——Twilio 传输层 + OpenAI Realtime（或兼容线路的）大脑。

贡献驱动

实现 @callmcp/driver-interface 中的接口，按照 SPEC.md §6.1 提供 callmcp.manifest.json，并运行一致性测试套件。若清单未将某项能力声明为 true，对应工具就不会出现在 tools/list 中——这就是整套机制，而不是变通方案。

许可证

本仓库代码采用 MIT 许可证。SPEC.md 按其文件头中的说明采用 Apache-2.0 许可证发布，特别是为了让任何人都能在无需许可的情况下实现符合规范的驱动。