Millionverifier

@pipeworx/millionverifier

通过 MillionVerifier（millionverifier.com）验证单个电子邮件地址。 属于 enrich-waterfall 的 enrich_verify_email 有序验证器（fleet #2860）。

属于 Pipeworx — 一个将 AI Agent 连接到 1882+ 个实时数据源的 MCP 网关。这是一个独立的非官方集成，与上游提供商无关联、未获其认可，也未由其发布。

工具

• millionverifier_verify(email, timeout?, _apiKey) — 返回结果 （ok/catch_all/disposable/invalid/unknown）、明确的 catch_all 布尔值、 质量、免费和角色标记。

身份验证

仅使用自备密钥。将你的 MillionVerifier API 密钥作为 _apiKey 传入（作为 api 查询参数，通过 GET 请求发送）。可在 https://app.millionverifier.com/api 查找密钥。无平台密钥（D4）。

数据来源

• https://api.millionverifier.com/api/v3/ — 验证单个电子邮件地址。

验证说明（fleet #2860，2026-10-08，未持有供应商密钥）

• 陷阱，已通过边缘探测确认：MillionVerifier 在身份验证失败时返回 HTTP 200。 密钥无效：

  GET https://api.millionverifier.com/api/v3/?api=invalidkey123&[email protected]
  -> HTTP 200
  {"email":"[email protected]","result":"error","resultcode":4,"subresult":"",
   "free":false,"role":false,"didyoumean":"","credits":0,"executiontime":0,
   "error":"Apikey not found","livemode":true}
  

  仅检查 res.ok 无法发现此问题——该包会检查 result === 'error'（或是否存在 error 字符串），并抛出错误，而不是 将 result: "error" 当作电子邮件地址的判定结果返回。这正是规范中特别指出的静默 200 情形： 返回 200，但负载看起来像正常结果，实际却表示“调用本身失败”。
• 已根据供应商文档确认响应字段名称和 catch_all 的表示方式（https://developer.millionverifier.com/，2026-10-08 阅读）： result 将 catch_all 作为一等值包含在内（而非在“ok”之上另设一个标记）——此包会推导出 catch_all: result === 'catch_all'， 因此调用方仍会获得稳定的布尔字段。
• 尚未验证（未持有密钥）： 文档和错误探测所示范围之外的 result 值完整枚举 （实际出现的值仅有 ok、catch_all、 unverified、invalid、unknown、disposable、error）；以及 resultcode 到 result 的确切映射关系。

快速开始

添加到你的 MCP 客户端（Claude Desktop、Cursor、Windsurf 等）：

{
  "mcpServers": {
    "millionverifier": {
      "url": "https://gateway.pipeworx.io/millionverifier/mcp"
    }
  }
}

此端点实际提供的内容

https://gateway.pipeworx.io/millionverifier/mcp 上的 tools/list 会返回上表中的工具， 以及 Pipeworx 共享元工具——ask_pipeworx、 discover_tools、search_within、remember/recall，以及 网关范围内的其他工具。因此，你看到的工具数量会多于此表：目前，单个工具包端点除了工具包自身的工具外，还会列出约 30 个共享工具。连接的 initialize 响应会说明其确切范围，是判断当天实际范围的权威依据。

这是有意为之，并非意外的多路复用。元工具可以让限定范围的连接回答此工具包无法处理的问题——通过 ask_pipeworx 路由到整个目录——而无需再添加第二个 MCP 服务。目前无法挂载不含这些元工具的工具包端点；如果额外的架构定义占用的上下文超过了路由功能带来的价值，请连接完整网关，而不是连接多个工具包端点。

或者连接完整的 Pipeworx 网关，直接列出所有工具包的工具，而不只是当前工具包的工具：

{
  "mcpServers": {
    "pipeworx": {
      "url": "https://gateway.pipeworx.io/mcp"
    }
  }
}

两个 URL 都连接到同一个网关和相同的 1882+ 个数据源。唯一的区别是哪个工具包的工具会被直接列出；从任一端点都可以通过 ask_pipeworx 使用所有工具。

没有 MCP 客户端？通过 HTTP 调用

此工具包需要你自备 API 密钥（_apiKey）——我们不会为它提供密钥，因此没有可在无密钥情况下运行的 curl 命令。查看任意工具：GET https://gateway.pipeworx.io/v1/tools/millionverifier_verify。查找工具：POST https://gateway.pipeworx.io/v1/tools/search_packs，并传入 {"query":"..."}。

独立运行（无需网关账户）

此软件包也可作为本地 stdio MCP 服务运行，无需 Pipeworx 账户，也无需经过网关往返：

{
  "mcpServers": {
    "millionverifier": {
      "command": "npx",
      "args": ["-y", "@pipeworx/mcp-millionverifier"]
    }
  }
}

也可以直接运行，确认它能正常启动：

npx -y @pipeworx/mcp-millionverifier

它通过 stdin/stdout 使用 MCP 通信，并针对仅限此软件包的工具响应 initialize/tools/list/tools/call——不包含上方网关连接所添加的任何共享元工具。相同的源代码，相同的工具，无需 ask_pipeworx 路由。

使用 ask_pipeworx

你也可以用通俗的英语提问，而不是直接调用工具——这既适用于上方的软件包端点，也适用于完整网关：

ask_pipeworx({ question: "your question about Millionverifier data" })

网关会选择合适的工具并自动填写参数。

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT