Vendor Signals

Vendor Signals——你的客户刚刚发布了什么

为 31 家受追踪的软件供应商提供带日期和链接的变更日志条目、发布说明和产品公告，可按域名与目标名单关联。

Pipeworx 的一部分（https://pipeworx.io）——一个将 AI Agent 连接到 1684+ 个实时数据源的 MCP 网关。

GTM 解读

“这家客户刚刚发布了 X”就是联系他们的理由。这就是这里提供的信息——附有日期和来源的供应商变更，而不是 dev-feeds 已涵盖的开发者新闻。

工具

工具	可回答的问题
vendor_recent_changes	Stripe 这个月发布了什么？
vendor_signal_sweep	我的哪些客户本周有动态？
vendor_coverage	追踪了哪些供应商？每个信息源是否正常？

身份验证

无需密钥。

本工具包围绕的区别

“已追踪但近期无动态”和“未追踪”是不同的答案，销售人员对这两种情况的处理方式也不同。如果两者都返回空列表，就会让未监控的客户看起来像是处于休眠状态。

• 已追踪且近期无动态 → found: true, count: 0，并附注说明这是一个确实没有动态的时期。
• 未追踪 → found: false, reason: "vendor_not_tracked"，并明确指出缺少的是覆盖范围，而非动态。
• 信息源当前故障 → 在响应中标记出来，因为此时空结果表示未知，而非不活跃。

vendor_signal_sweep 会出于同样的原因返回 quiet_vendors：未出现在任一列表中的供应商根本未被追踪。

范围

仅限结构化发布源——变更日志 RSS/Atom 和 GitHub releases。明确不是通用网页差异爬虫。会存储标题、摘要和链接；绝不保留完整网页内容。

供应商列表：vendor_doc_sources（由 scripts/ingest-vendor-signals.mjs --seed 初始化）。架构：supabase/migrations/*_vendor_signals.sql。

否则后来接手的人可能会重新发现的问题

• 失效的信息源不会报错——它会返回零条目，看起来一切正常。 Slack 的变更日志信息源返回 HTTP 200 和 text/html，但没有条目；三十个候选信息源中有六个出现了这种情况（Cloudflare、Linear、Twilio、Datadog、Atlassian、Slack 的初始猜测 URL）。所有候选信息源都在初始化前经过探测，轮询器会将零条可解析条目视为失败，而非安静成功，因此失效的信息源会显示在 vendor_coverage 中，而不会永远悄无声息地报告“没有变更”。
• 当供应商没有变更日志信息源时，GitHub releases.atom 是可靠的备用方案——对于大多数拥有公开 SDK 的供应商，https://github.com/<org>/<repo>/releases.atom 都能正常使用；本工具包正是通过它覆盖 Twilio、Linear、Datadog 和 Slack。
• Vercel 的信息源会返回约 1,500 条目，而大多数信息源只返回 10 条。假设每个信息源的页面都很小是错误的。
• Prefer: return=minimal 返回状态码 201 和空响应体，而不是 204——仅根据 204 切换的代码会尝试解析空内容。

快速开始

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

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

此端点实际提供的内容

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

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

curl -X POST https://gateway.pipeworx.io/v1/tools/vendor_recent_changes \
  -H 'Content-Type: application/json' \
  -d '{"vendor":"stripe","days":30}'

首次调用无需账户。查看任意工具：GET https://gateway.pipeworx.io/v1/tools/vendor_recent_changes。查找工具：使用 {"query":"..."} 调用 POST https://gateway.pipeworx.io/v1/tools/search_packs。

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

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

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

或者直接运行，以确认其能够启动：

npx -y @pipeworx/mcp-vendor-signals

它通过 stdin/stdout 使用 MCP 通信，并针对仅此工具包中的工具响应 initialize/tools/list/tools/call——不包含上文网关连接提供的任何共享元工具。相同的源代码、相同的工具，但没有 ask_pipeworx 路由功能。

使用 ask_pipeworx

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

ask_pipeworx({ question: "your question about Vendor Signals data" })

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

更多信息

• 文档和指南
• pipeworx.io

许可证

MIT