MCPツール設計：実用的アプローチとトレードオフ

モデルコンテキストプロトコル（MCP）ツールのパフォーマンスが低下する場合、その原因はプロトコル自体ではなくツール設計にあることがほとんどです。多くのチームは既存のAPIをそのまま公開し、エージェントが残りを処理すると信頼していますが、これによりツール呼び出しの失敗、パラメータ値の誤り、リトライが発生し、コンテキストを浪費してパフォーマンスを低下させます。この記事では、これらの失敗の背後にある2つの主要な問題——肥大化と混乱——を分析し、コンテキストエンジニアリングによる実用的な最適化方法を提案します。

肥大化とは、ツール定義が毎回の呼び出しでLLMのコンテキストにロードされ、使用されなくてもリソースを消費する問題です。複数のMCPサーバーが接続されると、ユーザーが質問する前にコンテキストが埋まり、推論能力が低下します。混乱は、意味的に類似したツール、選択肢の多さ、曖昧な命名により、LLMが誤ったツールやパラメータを選択することから生じます。一般的な対策はツールの説明を充実させることですが、これにより肥大化が悪化する可能性があります。

これらの問題に対処するため、記事では複数の戦略を紹介しています。まず、説明と応答の改善：フィールドの意味を明確に定義し、自然言語マッピングを提供し、エラーメッセージを最適化します。次に、スキーマ制約：パラメータ名をLLMが理解しやすいように変更し、列挙型で有効値を制限し、デフォルト値を設定し、パラメータ数を削減します。AWSはツールのパラメータ数を8以下に保つことを推奨しています。3つ目に、ツールの再構築とレイジーローディング：多目的ツールを専用ツールに分割し、コンテキストをオンデマンドでのみロードします。これによりトークン消費を最大85%削減できます。4つ目に、サーバーサイド推論：独自のLLMを使用する「内省ツール」を追加し、ユーザーの自然言語クエリを解釈して正確な指示を返します。5つ目に、エージェンティックツール：MCPサーバー全体を独自のエージェントでバックアップし、ツールを自然言語エンドポイントとして機能させます。

記事の後半では、模擬K-12コンテンツ検索APIの6つのバージョンを比較しています。このAPIには14のフィルタリング可能なフィールドがあり、LLMは教師の口語的なリクエストを正確な値にマッピングする必要があります。V1は生のパススルーで、内部的なパラメータ名とガイダンスの欠如により頻繁なリトライが発生します。V2は説明を改善し、有効値と同義語マッピングをリストアップして精度を向上させますが、定義が肥大化します。V3はパラメータ名を変更し、列挙型とデフォルト値を使用して誤った値を防止します。以降のバージョンではレイジーローディング、サーバーサイド推論、エージェンティックツールをさらに適用します。テストにより、レイジーローディングとスキーマ制約がコンテキスト消費の削減と初回呼び出しの精度向上に効果的であることが示されています。

結論として、MCPツール設計においては肥大化と混乱のバランスを取ることが重要であり、適切な戦略を選択することで効率的で正確なツールを実現できます。この記事で提供される6つの方法と比較コードは、開発者がさまざまな設計の実際の効果を評価するのに役立ちます。