Cartograph、AIエージェントのMCPツール発見を効率化

背景

Model Context Protocol（MCP）は、AIエージェントが外部ツールを発見し、呼び出すための共通インターフェースを提供します。一方で、接続するサーバーやツールが増えると、名前、説明、スキーマをすべてコンテキストに読み込むコストが大きくなります。Cartographはこの問題に対し、全カタログを最初から提示するのではなく、検索結果を段階的に開示する構成を提案しました。

仕組みの要点

• フェデレーテッド・プロキシ：22サーバー、374ツールの構成で、エージェントに直接見せるのは374個の定義ではなく3つのプロキシツールです。まず関連するサーバーを選び、その後に候補サーバー内のツールを検索します。
• 運用者が証明する能力カード：能力カードはデプロイを管理する運用者の管理下で生成され、Ed25519で署名されます。説明文の出所を明示でき、各クエリのランキングにどの説明が使われたかも記録できます。
• Riftによる混同分析：密度クラスタリング、クエリ間のマージン分析、トークン診断を組み合わせ、似た目的や名前を持つツールの混同リスクを調べます。評価では49の混同クラスタが見つかり、そのうち4つはブートストラップ生成カードにおけるHIGHリスクと判定されました。
• コンテキストの節約：報告されたTop-5発見の通信は475トークンでした。論文の全カタログ計算では42,450トークンとなるため、発見フェーズの入力を候補数に近い規模へ抑える考え方が示されています。

評価と注意点

著者が作成した49クエリのベンチマークで、CartographのR@5は0.816でした。Jaccardキーワードベースラインは0.592です。また、119件のLLM生成説明を使った探索的比較では、観測されていた距離ゼロのクラスタがなくなりました。ただし、異なる生成方式のカードを混ぜるとR@5が低下する可能性も示され、説明文の一貫性が検索品質に影響することが分かります。

ゲートウェイの遅延は、10回の試行で直接のstdio MCP呼び出しより平均5ミリ秒増え、報告された相対増加は0.8%でした。とはいえ、結果は単一の22サーバー構成と著者作成のクエリセットに基づきます。大規模な本番環境や多様なツール群で同じ性能が得られるかは、まだ確認されていません。

意義

Cartographの重要性は、単なるトークン削減にとどまりません。ツール発見を監査可能な検索処理に変え、運用者が管理する説明文の出所と検索結果を結び付けます。多数の社内API、プラグイン、第三者MCPサービスを管理する組織では、誤ったツール選択や不要な定義の投入を抑える仕組みになり得ます。

コード実行型の手法とも競合しません。コード実行はエージェントが能力をどう組み合わせるかを扱い、Cartographはどの説明を先にコンテキストへ出すかを扱います。より広いベンチマークと独立評価は必要ですが、MCPの全カタログを常に読み込むという前提を見直す設計例として注目されます。

出典：arXiv