Prospeo

@pipeworx/prospeo

通过 Prospeo 的人员信息增强 API（prospeo.io），按姓名和公司域名查找已验证的工作邮箱。属于 enrich-waterfall 查找器轮换（fleet #2860）。

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

工具

• prospeo_find_email(first_name, last_name, domain, company_name?, _apiKey) — 仅当 Prospeo 实际提供邮箱时才返回已验证的邮箱；经过掩码处理或未公开的猜测地址会报告为未找到。

身份验证

仅使用自带密钥。将你的 Prospeo API 密钥作为 _apiKey 传入。前往 https://app.prospeo.io/api 获取密钥。不提供平台密钥——PII 供应商从不使用平台密钥（Bruce 默认 D4）。

数据来源

• https://api.prospeo.io/enrich-person — 用于查找邮箱的人员信息增强接口。

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

• 旧版 /email-finder 接口已失效。 已通过边缘探测进行实时验证：HTTP 400 {"req_status":false,"error_code":"DEPRECATED","error_toast":"...migrate by using our new APIs: https://prospeo.io/api-docs"}。多篇第三方文章（Apify、Pipedream、一个 glama.ai MCP 服务）仍在介绍此接口——请勿照搬。当前替代接口是此处使用的 POST /enrich-person。
• 已实时确认身份验证请求头。 根据 https://prospeo.io/api-docs/authentication 使用 X-KEY: <key>。未提供密钥时对真实的 /enrich-person 接口进行边缘探测：HTTP 400 {"error":true,"error_code":"INVALID_API_KEY"}——这确认了请求头名称，也表明该接口正常运行且要求身份验证。此集成包的拒绝消息为“Prospeo requires an API key... get one at app.prospeo.io/api.”
• 响应结构仅来自供应商文档（https://prospeo.io/api-docs/enrich-person， 2026-10-08 阅读）——我们没有 Prospeo 密钥，因此未进行任何成功的实时调用。文档中的示例：

  { "error": false, "free_enrichment": false,
    "person": { "person_id": "...", "first_name": "Eoghan", "last_name": "Mccabe",
      "email": { "status": "VERIFIED", "revealed": true, "email": "eoghan.*****@intercom.com" } },
    "company": { "company_id": "...", "name": "Intercom" } }
  

  请注意，文档自身的示例也对邮箱地址进行了掩码处理（eoghan.*****@intercom.com），即使 revealed: true 也是如此——此集成包的解析器只接受不含 * 的邮箱字符串，因此实时调用返回的掩码地址或预览地址会正确地标记为 found: false，而不会作为可用联系人返回。这是唯一需要通过实时密钥确认的事项：付费完整解锁后是否始终会返回未经过掩码处理的完整地址。下文已标注为未验证。
• 尚未验证（未持有密钥）： 成功的付费调用是否会返回未经过掩码处理的地址；当 Prospeo 只有猜测（未验证）地址时，only_verified_email: true 的确切行为。

快速开始

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

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

此端点实际提供的内容

https://gateway.pipeworx.io/prospeo/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 都连接到同一个网关和相同的 1745+ 个数据源。唯一的区别是，哪个工具包的工具会被直接列出；无论连接哪一个，ask_pipeworx 都能访问所有工具。

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

此工具包需要你自己的 API 密钥（_apiKey）——我们不会为它提供密钥，因此没有无需密钥即可运行的 curl 命令。查看任意工具：GET https://gateway.pipeworx.io/v1/tools/prospeo_find_email。查找工具：使用 {"query":"..."} 向 POST https://gateway.pipeworx.io/v1/tools/search_packs 发送请求。

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

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

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

或者直接运行，以确认服务已启动：

npx -y @pipeworx/mcp-prospeo

它通过 stdin/stdout 使用 MCP，并为仅此工具包的工具响应 initialize/tools/list/tools/call——不包含上述网关连接额外提供的任何共享元工具。相同的源码，相同的工具，但不支持 ask_pipeworx 路由。

使用 ask_pipeworx

你可以用通俗英语提问，而不是直接调用工具——无论是上面的工具包端点还是完整网关，都支持此功能：

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

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

更多

• 文档和指南
• pipeworx.io

许可证

MIT