mcp-server

一句话定位

给 agent 开临时手机号的 MCP 服务器：agent 要注册账号时，下单一个 指定国家的私有号码、等短信验证码、读出来、用完还掉——全程没有人在键盘前。

做这个东西的人

SV Number（sms-verification-number.com），一家做"接码"生意的公司， 把自家跑了几年的接码 API 重新包装成 MCP 服务器（sv-number/mcp-server，MIT，TypeScript）， 专门卖给 AI agent。官网有一个专门给 agent 用的落地页，还配了 agent-skill（纯 markdown） 给 Claude Code / Codex 用。

判断：这不是一次新产品发布，是一次渠道重做。同样的接码服务，以前用户是人， 现在用户是 agent。它没有发明任何新能力，只是把接口语言从"人看的网页"改成 "agent 读的 MCP 工具"。企业级媒体（Enterprise DNA）专门报道了这个转身， 把它当作"垂直 API 重做给 agent"的样板案例。

它到底能做哪几件事

• 按国别下单 → 211 个国家、1094 个服务码（Telegram、WhatsApp、Google 等）， 请求里带 country=<id>，agent 基于实时可用性（getCountryAndOperators、 getServicesAndCostWithStatistics）自己选，而不是抄死在 prompt 里
• 读码而不是收件箱 → 轮询 getStatus 直接拿到 STATUS_OK:123456， 验证码已经解析好，不需要从短信文本里抠数字
• 号码独占 20 分钟 → 号在你手里期间别人拿不到，码只有你能看到；超时自动退款
• 顺带处理二要素 → 服务给出 authenticator secret 时，agent 本地按 RFC 6238 算 6 位动态码（30 秒窗口），secret 不出本机
• 九种原生 MCP 工具 → list_countries、list_services、order_number、 wait_for_code、finish_activation、cancel_activation、totp_code 等， Claude Code / Codex / Cursor 都能直接用；不 MCP 就调 API（方法名 getNumber、 getStatus、setStatus，是老接码市场的通用名，存量客户端换个 base URL 就能用）

它明确不做：不能发短信、不能打电话，号码只收验证码不做别的。

它在替代什么旧行为

以前 agent 要完成注册（比如注册一个印尼市场的账号），卡点在手机号验证： 验证平台看号码归属地，美国号去注册印尼账号，短信还没发就被拒了。

旧流程是人去接码平台（sms-activate 这类）手动操作：选国家、下单、等码、 把码填回注册流程，一次要人守着几分钟。更早的替代是买实卡、插卡收码。

SV Number 把这三步全自动化：agent 一条 API 下单、轮询拿码、完成注册， 归属地由请求参数决定。替代的是"人守在验证码前"这个动作本身。 更值钱的一点：它把"每个账号一条新号"变成默认——一个永久号注册第二个账号 就会被服务方拒绝，而接码市场从来就是按"一次一码、号随用随弃"定价的。

商业模式

按码付费，预充值。 典型价 $0.43/次验证（最低 $0.01），20 分钟内码没到 自动退回余额；需要长期收码的账号可以按天租号。限速 150 rps。没有订阅、没有座位费。

判断：这套定价是为 agent 客户设计的——agent 不会讨价还价、不会心疼单次几毛钱， 只要接口稳定它就会一直跑。对卖方来说这是理想客户：用量自动增长、几乎没有服务成本。 风险在合规侧：接码生意天然和批量注册、羊毛党纠缠，这是所有接码服务商头顶的剑。

硬数字

• 573 star / 3 fork（2026-08-14），MIT，TypeScript，官方 MCP Registry 收录
• 企业媒体（Enterprise DNA）报道：3 天内 GitHub 涨 534 个 star，同周还发了配套 skills 仓库
• 211 国 / 1094 服务码 / 典型价 $0.43 / 号码独占 20 分钟 / 150 rps（2026-08-06 官网读数）
• 竞品对比页（vs AgentLine / AgentPhone / AgentNumber / OP）：对方只有美加或美国覆盖，SV Number 211 国
• 团队人数、营收、融资：未披露

四维评估

判断

这是"垂直 API 重做给 agent"的教科书案例，值得每个做 API 生意的人研究。 SV Number 没发明新服务，做的是三件小事：把接口语言换成 agent 的、 把文档换成 agent 能自己读的、把定价换成 agent 不会心疼的。 三件小事合起来，把一个面向人的小生意变成了面向 agent 的基础设施。

可迁移的规律：任何你已经在用的垂直服务，都值得按这个模板过一遍—— 能不能让 agent 不需要人等、不需要人读文档、按用量自动付费地调用你？ 先问"这个服务能不能自主跑"，能自主跑的才值得重做接口。

三个风险要盯：一是合规，接码与批量注册/欺诈只隔一线，平台方封号和 法律风险随时可能爆发；二是它本质是渠道生意，star 涨得快是因为 MCP 生态 在涨，不是因为它不可替代——Twilio 这类大厂把号贩进 MCP 只是时间问题； 三是"面向 agent 的定价"如果竞争对手进入，价格战会来得比 to C 市场更快。

下一步看什么

① 三个月后 star 能否破千——MCP 生态热度退潮后还涨不涨，才是真实需求 ② 有没有 agent 平台（如 Claude Code、Cursor）把它做成内置能力或官方合作—— 被内置等于被收编，也等于品类被验证 ③ 有没有出现封号/合规事件的公开报道——那是这类生意的生死线

可借鉴的做法

产品逻辑：如果你的产品或 API 是"重复、可自主、按量计费"的， 认真考虑做一套 agent 原生入口（MCP 或 skill），并把定价改成"按结果付费、 失败自动退款"。agent 客户不看官网、不问客服，它们只看接口文档和失败率。

定价结构：按次付费 + 未达效果自动退款 + 限速不限额。这套组合对 agent 客户的说服力远大于订阅制。

结论

值得关注。 一次漂亮的渠道转身，让"给 agent 发身份"这件小事变成了一门 明码标价、按量付费的生意。但它的护城河不在技术，在合规处理能力和对 agent 生态的响应速度——这两点都还要看后续。三个月后拿上面三条验证。