LLMに数千の準備済みパーサーを接続する方法

実際のプロジェクトで言語モデルを扱う場合、同じ問題にすぐに直面します。モデルは推論やコード作成に優れていますが、盲目です。外部世界からの新鮮なデータが必要です：ソーシャルネットワークからの最新投稿、地図からの企業連絡先、マーケットプレイスからの商品カード、検索エンジンの新鮮な結果など。

通常、この時点で開発者はFunction Calling用のカスタムツールを書き始め、Playwrightのラッパーを作ったり、Cheerioでパイプラインを構築したりします。このようなスクリプトを数週間保守した後、時間の半分がCAPTCHA、レイアウト、古いセレクターとの戦いに費やされていることに気づきます。

ApifyチームはModel Context Protocolを通じてこの問題を解決し、apify-mcp-serverプロジェクトをリリースしました。本質的に、何千もの готовыхクラウドスクレイパーの全カタログをAIエージェント向けの統合ツール呼び出しインターフェースに変換しました。

何それで、なぜ必要なのか

リポジトリには、MCPサーバー実装が含まれており、ローカルまたはクラウドクライアント（Claude Desktop、Cursor、VS Code、ChatGPT）をApifyプラットフォームに接続します。プラットフォームは何千もの готовыхスクリプト（Actor）を実行します。各Actorは特定のサイト（Google Maps、Facebook、Instagram、オンラインストアなど）から構造化データを取得できます。あるいは、RAG用にシンプルにウェブサイトをクロールすることもできます。

モデルのために何十ものAPIのスキーマを手動で記述する代わりに、単一のエンドポイントを接続します。アシスタント自体がカタログから適切なスクレイパーを検索し、そのJSONスキーマを読み取り、入力パラメータを検証し、データ収集を開始します。

ツール呼び出しの仕組み

サーバーの主な特徴は動的なツール検出です。各必要なパーサーの設定を事前にハードコードする必要はありません。

デフォルトでは、サーバーはエージェントに基本的なアクションのセットを提供します：

1. search-actors テキストクエリでカタログから適切なスクレイパーを検索します。
2. fetch-actor-details 見つかったスクリプトの入力パラメータースキーマとドキュメントを取得します。
3. call-actor Apifyインフラストラクチャでタスク実行を開始します。
4. get-dataset-items ページネーションサポート付きでバッチ готовых構造化結果をフェッチします。
5. apify--rag-web-browser RAG用のクイックWeb検索とコンテンツ解析ツールとして組み込まれています。

Claudeに「Google Mapsでプラハのトップ10カフェを電話番号付きで探して」と尋ねると、エージェントはアクセスできないとは言わず、search-actorsを呼び出し、Google Maps Scraperを見つけ、座標と都市を渡して、結果を待ち、データセットを読み取ります。

モデル自体は選択したスクレイパーのパラメータースキーマを検証しながらこのJSONを生成します。

接続オプション：クラウドvsローカル実行

サーバーをクライアントに接続するには2つの方法があります。選択はエージェントがどこにあるかによって異なります。

1. Streamable HTTPを通じたホスト型オプション

Claude.aiまたはVS Codeへの最も簡単なパスです。Apifyのチームがmcp.apify.comでホストしています。OAuth認証がサポートされているため、一部のクライアントではAPIトークンを手動でコピーする必要すらありません。

モデルコンテキストに追加の負荷をかけずに特定のツールのみが必要な場合は、パラメータをURLに直接渡せます：

このモードでは、サーバーは他のパーサーからのメタデータでコンテキストを乱雑にするのではなく、エージェントに1つの検索ツールのみを提供します。

2. stdioを通じたローカル実行

Claude Desktopまたはターミナル内のローカルエージェントを設定している場合、npxでサーバーを起動します：

ローカルプロセスは環境変数を読み取り、スキーマを収集し、標準入力/出力ストリームを通じてクライアントと通信します。

アカウント作成なしの支払い

エージェント経済学に関連する興味深いアーキテクチャの詳細があります。AIエージェントが自律的に動作し、リンクされたカードを持つ登録済みApifyプロファイルを持っていない場合はどうなりますか？

開発者は自動支払いプロトコルのサポートを組み込みました：

• AGI：エージェントはx402またはMPP経由で制限付きの的前払いトークンをマイクロ決済で購入し、標準のBearerトークンとして使用します。
• Direct x402：各特定の実行に対してBaseネットワーク上のUSDCで支払い、mcpcユーティリティ経由。未使用の残高は60分間の非アクティブ後に自動的にエージェントのウォレットに返されます。
• Skyfire：エージェントはSkyfireインフラストラクチャを通じて支払いトークンを生成し、ツール呼び出しパラメータに渡します。

これにより、エージェントが完全に分離された環境で動作する場合の請求書の面倒がなくなります。

技術的なニュアンスと制限

コードベースには、統合時に考慮する価値のあるいくつかの実用的なソリューションが含まれています：

• 入力パラメータースキーマはトリムされています。長いフィールドの説明は500文字に切り捨てられ、enum値のリストは20,000文字に制限されています。これは、複雑なパーサーからの重いスキーマがモデルのコンテキストウィンドウを消費しないようにするための意図的な設計です。
• call-actor呼び出しは最初の応答で解析されたデータ配列全体を一度に返しません。データセットIDと実行メタデータを返します。行を取得するには、エージェントは次のステップでget-dataset-itemsを通じてフェッチします。これにより、コンテキストがギガバイトのテキストでオーバーフローするのを防ぎます。
• テレメトリの送信とSentryはstdioモードでデフォルトで有効になっています。--telemetry-enabled=falseフラグまたはTELEMETRY_ENABLED=false環境変数でそれらを無効にできます。

誰が実際にこのプロジェクトを役立つか

研究、競合分析、リード生成、価格監視用の自律型エージェントを構築している場合、スクレイピングインフラストラクチャに関するweeksの作業を節約できます。独自のクローラーを書く代わりに、標準化されたプロトコルを通じて готовыхパーサーへの готовыхアクセスを取得します。

始める最も簡単な方法は、Claude DesktopまたはCursorにホストされたエンドポイントhttps://mcp.apify.comを接続し、基本的なツールapify/rag-web-browserをテストすることです。狭い本番タスクには、toolsパラメータを通じてツールのリストをすぐにハードコードして、エージェントが不必要なカタログ検索にトークンを費やすのを防ぐのが良いでしょう。