MCPツールのレイジーローディング：対応状況とその方法
多くの人は、MCPサーバーのコストはコード内に存在すると考えていますが、それは間違いです。
MCPサーバーを構築する場合、2種類のトークンコストに直面します。
- 固定コスト：ターンごとにコンテキストに読み込まれるツールの定義。
- 変動コスト：ツールが返すレスポンスのサイズ。
変動コストは制御可能です。結果をページネーションしたり、出力サイズを制限したりできます。
固定コストは制御できません。それはホスト（クライアント）の役割です。
もし多くのツールを持つ10個のサーバーがある場合、モデルが最初のメッセージを読む前に、40,000トークンを無駄にしてしまう可能性があります。これは、ホストがあらかじめすべてのツール定義を読み込むために起こります。
解決策はレイジーローディング（遅延読み込み）です。これは、ホストが小さな検索ツールのみを読み込み、他の定義は必要になったときにのみ取得することを意味します。
問題は？ ほとんどのクライアントがまだこれに対応していないことです。
レイジーローディングの現状：
- Claude Code：対応済み。検索ツールを介して、オンデマンドでツールが読み込まれます。
- Cursor、Devin、その他：未対応。すべてを一度に読み込みます。
レイジーローディングに対応していないクライアントでコンテキストが肥大化している場合、2つの選択肢があります。
レイジープロキシを使用する ホストの接続先を実際のサーバーではなく、プロキシサーバーに向けます。プロキシは
search_toolsとexecute_toolという2つのツールのみを公開します。リクエストがあったときにのみ、実際の定義を読み込みます。これによりコンテキストは縮小されますが、きめ細かな権限管理ができなくなります。ルーターパターンを使用する 1つのサーバーが大きくなりすぎている場合は、ツールを追加しないでください。代わりに、操作パラメータを持つ1つのツールを作成します。例えば、"list"、"get"、"search" といったコマンドを持つ1つの "docs" ツールを使用します。これにより、ホストが読み込む必要があるスキーマの数を減らすことができます。
戦略のまとめ：
- 6〜15個のツール：何もしなくてよい。コストは心配するほど低いためです。
- 1つのサーバーに多くのツールがある場合：ルーターパターンを使用する。
- 多数の異なるサーバーがある場合：レイジープロキシを使用する。
コードの最適化に何時間も費やす前に、クライアントの挙動を確認してください。解決策はサーバー側には全くないかもしれません。
出典: https://dev.to/ismaestro/lazy-loading-mcp-tools-which-clients-support-it-and-how-4414
オプションの学習コミュニティ: https://t.me/GyaanSetuAi