Vendor Signals

ベンダーシグナル — 各アカウントがリリースしたばかりのもの

31 の追跡対象ソフトウェアベンダーの変更履歴、リリースノート、製品発表を、日付とリンク付きで掲載し、ターゲットリストのドメインと照合できます。

Pipeworx の一部です — AI エージェントを 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 リリースです。汎用のウェブ差分クローラーは意図的に対象外です。タイトル、要約、リンクを保存しますが、ページの全文が保存されることはありません。

ベンダーリスト：vendor_doc_sources（scripts/ingest-vendor-signals.mjs --seed で初期登録）。スキーマ：supabase/migrations/*_vendor_signals.sql。

次の担当者が同じ調査を繰り返さずに済むための情報

• 停止したフィードはエラーにならず、エントリーを 0 件返すため正常に見えます。 Slack の変更履歴フィードは、エントリーがないまま text/html を返す HTTP 200 に応答します。候補 30 件のうち 6 件（Cloudflare、Linear、Twilio、Datadog、Atlassian、初回に推測した URL の Slack）がこの状態でした。初期登録前にすべての候補を確認し、ポーラーは解析可能なエントリーが 0 件の場合、静かに成功したものとして扱わず、失敗として扱います。そのため、古くなったフィードはいつまでも「変更なし」と報告されることなく、vendor_coverage に表示されます。
• ベンダーに変更履歴フィードがない場合、GitHub の releases.atom が信頼できる代替手段です — https://github.com/<org>/<repo>/releases.atom は、公開 SDK がある大半のベンダーで機能し、ここでは 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 を通じて回答できます。そのため、2つ目の 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