Forager

@pipeworx/forager

Forager（forager.ai）経由で、LinkedIn プロフィール URL から人物の電話番号を検索します。enrich-waterfall の新しい enrich_find_phone ファインダーローテーションの一部です （フリート #2860）。

Pipeworx の一部です — AI エージェントを 1879 以上の稼働中データソースに接続する MCP ゲートウェイです。これは独立した非公式の統合であり、上流プロバイダーとは提携関係になく、承認も公開もされていません。

ツール

• forager_find_phone(linkedin_url?, person_id?, _accountId, _apiKey) — 電話番号と種類を取得します。Forager のアカウント ID と API キーの両方が必要です。

認証

BYO のみです。Forager のアカウント ID を _accountId、API キーを _apiKey として渡します（ヘッダー X-API-KEY。アカウント ID はパスセグメント /api/{account_id}/... に含めます）。どちらも Forager ダッシュボードで確認できます。プラットフォームキーはありません（D4）。

データソース

• https://api-v2.forager.ai/api/{account_id}/datastorage/person_contacts_lookup/phone_numbers/

検証メモ（フリート #2860、2026-10-08、プロバイダーのキーなし）— このパックはバッチ内で確認が最も不十分です

• URL パスは稼働中であることを確認済みです。 アカウント ID に "0" を指定して .../phone_numbers/ に対して試したすべての認証形式で、HTTP 403 が返されます（404 は一度も返されません）。 したがって、パスとアカウント ID をパスに含める規則は実在します。
• ヘッダー名は独立して確認できていません。 ヘッダーなし、 X-API-KEY: invalidkey123、Authorization: Api-Key invalidkey123、および Authorization: Bearer invalidkey123 はすべて、バイト単位で同一の {"detail":"Authentication credentials were not provided."} を返します。 サーバーの汎用スキームメッセージがこのように汎用的な場合、プレースホルダーキーでのプローブでは「ヘッダーが間違っている」のか「ヘッダーは正しいがキーが無効」なのかを判別できません。 Forager 自身のドキュメントを説明する検索結果でこの指定が使われていたため、ここでは X-API-KEY を使用していますが、このバッチ内でこの認証形式だけは、実際のキーが機能するか、異なる 401／403 の本文が返るまでは、確認済みの事実ではなく仮説として扱う必要があります。
• リクエスト／レスポンス本文のフィールドは、確認済みのスキーマではなく、最善を尽くした推測です。 この特定のエンドポイントについて、docs.forager.ai のスキーマページは取得できませんでした（取得できた範囲では、詳細検索、メールアドレスによる逆引き、電話番号による逆引き、役職検索という関連エンドポイントのみ見つかりました）。このパックは {"linkedin_url": ...} または {"person_id": ...} を送信し、Forager の他の REST 規約にならって、phone_numbers 配列（文字列または {number, type} オブジェクト）を読み取ります。実際のキーで異なる形式の 200 が返る場合、修正が必要なのは src/index.ts の findPhone() だけです。
• 未検証（キーなし）であり、このパックでは通常より重要な前提です： 認証ヘッダー名、リクエスト本文のフィールド名、レスポンスのフィールド名、そして _accountId が正しい概念なのかどうか（アカウント ID はキー自体から導出できるのか）。

クイックスタート

MCP クライアント（Claude Desktop、Cursor、Windsurf など）に追加します：

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

このエンドポイントが実際に提供するもの

https://gateway.pipeworx.io/forager/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 も同じゲートウェイと同じ 1879 以上のデータソースに接続します。異なるのは、どのパックのツールが直接一覧表示されるかだけです。どちらからでも、ask_pipeworx を使ってすべてのツールにアクセスできます。

MCP クライアントをお持ちでない場合：HTTP で呼び出す

このパックでは、ご自身の API キー（_apiKey）を使用します。こちらではキーを用意していないため、キーなしで実行できる curl コマンドはありません。任意のツールを確認するには、GET https://gateway.pipeworx.io/v1/tools/forager_find_phone を実行します。ツールを探すには、{"query":"..."} を指定して POST https://gateway.pipeworx.io/v1/tools/search_packs を実行します。

スタンドアロン（ゲートウェイアカウント不要）

このパッケージは、ローカルの stdio MCP サーバーとしても実行できます。Pipeworx アカウントも、ゲートウェイへの往復通信も不要です。

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

または、直接実行して起動を確認できます。

npx -y @pipeworx/mcp-forager

stdin/stdout 経由で MCP を使用し、initialize／tools/list／tools/call に応答します。対象はこのパックのツールのみで、上記のゲートウェイ接続で追加される共有メタツールは含まれません。同じソース、同じツールを使用し、ask_pipeworx によるルーティングはありません。

ask_pipeworx の使用

ツールを直接呼び出す代わりに、自然な英語で質問できます。これは、上記のパックエンドポイントとフルゲートウェイの両方で利用できます。

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

ゲートウェイが適切なツールを選択し、引数を自動的に設定します。

詳細

• ドキュメントとガイド
• pipeworx.io

ライセンス

MIT