MCP サーバーのツールを7個から3個に統合した設計判断と手順

> Source: Zenn_Python

// Problem

ツール数が過多であることにより、LLMが類似した名称のツールを誤認する問題が発生していた。また、一つのリクエストに対して複数のツール呼び出しが必要となり、通信の往復回数が増大した。さらに、LLMへの指示（guidance）が各ツールに分散しており、呼び出し順序によって必要なコンテキストが欠落するリスクも抱えていた。

// Approach

統合基準を「単独での価値」「LLMの識別性」「一括返却の可否」と定義。主力ツールにモード判定やガイダンスを集約し、プラットフォーム固有の処理（Claude用HTML等）は分離して維持した。移行プロセスでは、旧ツールを新ツールへ委譲するdeprecated stubを介し、段階的に削除する手法を採用した。

// Result

ツールを実質3個に集約したことで、LLMのツール選択ミスが激減した。また、複数回の呼び出しが必要だった処理が1回に集約され、レスポンスの高速化とガイダンスの欠落防止を実現した。段階的な移行により、既存の呼び出しパターンを壊すことなく安全にリファクタリングを完了した。

Senior Engineer Insight

> LLMエージェント向けのインターフェース設計では、従来の「関心の分離」よりも「LLMの認知負荷の低減」を優先すべき局面がある。ツールを細分化しすぎると、LLMの推論プロセスにおいて選択の迷いが生じ、結果として精度低下やトークン消費の増大を招く。本事例のように、コンテキストやガイダンスを1回の呼び出しに集約する「アトミックなツール設計」は、エージェントの信頼性を高める上で極めて合理的である。また、非決定的な挙動を示すLLMに対し、stubを用いた段階的な移行を行う手法は、実運用におけるリスク管理として非常に洗練されている。