SMSBulk MCP 服务器
直接在 Claude Desktop、Cursor 或任何兼容 MCP 的客户端中使用 SMSBulk——订购短信号码和一次性邮箱地址，并读取验证码。
模型上下文协议（MCP）让 AI 助手能够调用外部工具。这个开源服务器将 SMSBulk API 连接到你的 AI 客户端，不含业务逻辑，也不存储任何密钥。
功能说明
该服务器是纯转发层：它使用你自己的 API 密钥将每个请求转发到 SMSBulk 公共 API。它提供分为四组的 18 个工具——目录、短信、钱包和邮箱。
与仅提供短信的服务商不同，SMSBulk 同时提供电话和邮箱验证。在大多数竞争对手的 MCP 服务器中，邮箱工具没有对应功能。
安装
需要 Node.js 18 或更高版本。克隆仓库、安装依赖并构建：
git clone https://github.com/Tolunay3434/smsbulk-mcp.git
cd smsbulk-mcp
npm install
npm run build然后让你的 MCP 客户端指向构建好的 dist/index.js。目录工具无需密钥即可使用；其他所有工具都需要你的 SMSBulk API 密钥。
客户端配置
Claude Desktop
{
"mcpServers": {
"smsbulk": {
"command": "node",
"args": ["/absolute/path/to/smsbulk-mcp/dist/index.js"],
"env": {
"SMSBULK_API_KEY": "your_api_key_here",
"MAX_SPEND_PER_SESSION": "5"
}
}
}
}将其添加到 claude_desktop_config.json，然后重启 Claude Desktop。SMSBulk 工具会出现在工具菜单中。
Cursor
{
"mcpServers": {
"smsbulk": {
"command": "node",
"args": ["/absolute/path/to/smsbulk-mcp/dist/index.js"],
"env": {
"SMSBULK_API_KEY": "your_api_key_here"
}
}
}
}将其添加到 ~/.cursor/mcp.json（全局）或 .cursor/mcp.json（按项目）。
将 /absolute/path/to/smsbulk-mcp 替换为你克隆仓库的真实路径。切勿提交你的 API 密钥。
工具参考
共 18 个工具。目录工具无需密钥；其他工具会发送你的 x-api-key。
目录
无需 API 密钥list_services—所有可用服务，附库存和最低价格摘要。
list_countries—所有支持的国家/地区，附旗帜和 ISO 代码。
get_serviceslug按 SEO 短链或服务代码查询的单个服务。
get_service_countriesslug某项服务有库存的国家/地区，含价格、库存和速度等级。
短信验证
需要 API 密钥request_numberserviceCode, countryIso, operator?, idempotency_token?扣费为短信验证预留一个号码。带重试保护。
get_statusid某次激活的状态及短信验证码（收到后）。
completeid将一次激活标记为完成。此操作不可撤销。
cancelid取消激活；若未收到短信则退款到钱包。
request_resendid请求服务商向同一号码再发送一条短信。
list_activationslimit?, cursor?, status?你的激活记录，按游标分页，最新在前。
钱包
需要 API 密钥get_balance—你当前的钱包余额。
list_transactionslimit?, cursor?最近的充值、扣费和退款。
邮箱验证
需要 API 密钥仅短信服务器不具备email_get_domainssite目标网站可用的邮箱服务商域名，含价格和库存。
email_requestsite, domain, idempotency_token?扣费预留一个一次性邮箱地址。带重试保护。
email_listlimit?你最近的邮箱激活记录，最新在前（最多 100 条，无游标）。
email_get_statusid状态、解析出的 OTP 以及原始 HTML 正文（收到后）。
email_reorderid扣费重新开启同一地址以接收另一个 OTP。
email_cancelid取消；若未收到 OTP 则退款到钱包。
安全与限制
这些防护是为方便而设的安全带，并非保证。
尽力而为的重试保护——并非保证的幂等性
request_number 和 email_request 在内存中维护一个小型防护，用于捕捉常见的误操作情形：如果同一个下单工具在一个会话中以相同参数被调用两次，第二次调用会返回第一次的结果，而不会再次扣费。这并非保证的幂等性——它仅存在于本进程的内存中，重启后即清零，不在多个客户端之间协调，也无法防止真正的服务器端竞态。要安全地重试同一笔订单，请传入相同的 idempotency_token；要有意下第二笔订单，请传入不同的 token。
软性消费上限（MAX_SPEND_PER_SESSION）
设置后，服务器会跟踪每笔成功订单的真实成本，并在累计总额达到你的上限时阻止下一笔订单。它是软性的且存于内存——重启后清零，仅覆盖本会话，且阻止的是下一个请求，而非拆分单个请求。在仍低于上限时下的订单会被允许，即使它使总额超出上限。它是叠加在你账户服务器端限制（余额、每日配额、频率限制）之上的额外一层。