翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

# ツールの整理
<a name="mcp-tool-strategy-organization"></a>

適切なツールを発見し、LLM がそれらを効果的に使用できることを確認することは、効果的なツール開発の最も重要な部分の 1 つです。MCP サーバーの開発を開始するには、以下を決定する戦略が必要です。
+ 1 つの MCP サーバーに入るツールの数
+ 同じ MCP サーバーに配置するべきではないツール
+ ツールに名前を付けて検索可能にし、名前の衝突を防ぐ方法 (同じ名前の異なるツール)
+ ツールと MCP サーバーをドキュメント化して LLM で使いやすくする方法

*名前空間組織は*、ツール名の衝突を防ぎ、関連機能をグループ化し、LLMs。このパターンは、非構造化蓄積ではなく、整理されたストレージシステムと同様の構造化分類を確立します。ツールの命名には *domain-noun-verb* パターンをお勧めします。例えば、、`github_issue_create``github_issue_list`、、`github_issue_update``github_pullrequest_create`、`github_pullrequest_list`、 などです`github_pullrequest_merge`。このパターンの利点は、アルファベット順のソート動作を調べる際に明らかです。ツールがアルファベット順にリストされている場合、問題関連のすべてのオペレーションはクラスター化され (`create`、`list`、`update`)、プルリクエストオペレーションが続きます (`create`、`list`、)`merge`。名詞 (リソースタイプ) は組織の境界として機能します。この構造により、関連する機能が自然にグループ化されるため、LLM ツールのスキャンとヒューマンドキュメントのナビゲーションの両方が容易になります。

MCP サーバーはドメインレベルで制限する必要がありますが、提供する機能の職務の分離に基づいて分割できます。たとえば、データベースへの書き込みオペレーションと読み取りオペレーション用に個別の MCP サーバーがあるとします。この分離を適用するには、ユーザーのインテントとアクセス許可に基づいてアクセスできる MCP サーバーを制限するガードレールをエージェントレベルで実装することをお勧めします。これは、次の組み合わせによって実現できます。
+ **条件付きサーバーのロード** – エージェントがユーザー入力で読み取りオペレーションを検出した場合にのみ、読み取り専用 MCP サーバーをロードします。
+ アクセス**許可ベースのフィルタリング** – ユーザー認可を使用して、適切な MCP サーバーのみへのアクセスを許可します。

最後に、MCP サーバーによって提供されるツールの数の上限を作成します。エージェントが MCP サーバーをどのように使用するかについて仮定しないでください。使用可能なすべてのツールをナイーブに一覧表示し、すべてを LLM に提供する場合があります。1 つのサーバーに 50 を超えるツールがある場合は、複数のサーバーに分割することを検討する必要があります。

## MPC ツール組織のベストプラクティス
<a name="mcp-tool-strategy-organization-best-practices"></a>
+ **ツールに domain-noun-verb 命名基準を使用する** – MCP サーバーとエージェントの両方で名前の衝突を防ぐための戦略を実装します。
+ **上限を設定する** – 1 つの MCP サーバー内のツールの数を制限します。
+ **MCP サーバーの分割** – 職務の分離を使用して MCP サーバーを論理グループに分割します。