MCPツール名の命名規則とサーバー間衝突の防ぎ方

MCPのツール名は1〜128文字、使える記号は3つだけ

MCP(Model Context Protocol)の現行仕様は、ツール名の書式を明確に規定しています。長さは1〜128文字、大文字小文字を区別し、使える文字は英数字(A-Z、a-z、0-9)とアンダースコア(_)、ハイフン(-)、ドット(.)のみです。スペースやカンマなど、これ以外の記号は含めるべきではありません。

有効な名前の例として仕様書が挙げるのはgetUser、DATA_EXPORT_v2、admin.tools.listの3つです。いずれも英数字と許可された3記号の組み合わせで、ドットを使ったadmin.tools.listのような階層的な命名も許容されます。この書式ルールは「SHOULD」(推奨)として書かれており、MUST(必須)ではありません。ただし相互運用性を最優先するなら従うべき基準として位置付けられています。

この規定はSEP-986という提案が起点になりました。SEPは仕様変更提案(Specification Enhancement Proposal)の略で、プロセスの全体像はMCPのSEPプロセスにまとめています。

SEP-986が提案した書式と、現行仕様で変わった点

SEP-986「Specify Format for Tool Names」は2025年7月16日にkentcdodds氏が提出し、Standards Trackとして最終的にFinalステータスに達しました。提案の動機はシンプルです。ツール名の書式が未規定だったため、実装ごとに区切り文字や大文字小文字の扱いがばらつき、ツール呼び出しのミスやドキュメント作成の手間につながっていました。

提案が掲げた狙いは4つです。ツール名をクライアント間で予測可能・相互運用可能にする、スラッシュやドットを使った階層的で名前空間分けされた命名を可能にする、人間が読める名前と機械生成された名前の両方に対応する、有効なユースケースを不必要に妨げる制限を避ける、というものでした。

提案文書の元の内容と、現行仕様(2026-07-28)に実際に反映された内容には、見落としやすい差分があります。

提案段階ではuser-profile/updateのようにスラッシュで階層を表す名前も有効例として挙げられていましたが、現行仕様の許可文字リストにスラッシュは含まれていません。文字数上限も64文字から128文字へ緩和されています。SEPはあくまで議論の出発点であり、実装に落ちる過程で細部が調整されることを示す実例です。プロトコル自体の改訂履歴はMCP仕様のバージョン履歴で扱っています。

なぜスペースとカンマを禁止したのか

SEP-986のRationale(論拠)節は、書式を決める際の判断基準も記録しています。提案の出発点は、既存の実装がすでにばらばらの区切り文字・大文字小文字の使い方・文字集合を採用していたという現状でした。lower-kebab-case(小文字とハイフン)が一般的な慣習の1つではあったものの、多くのツールやクライアントは、名前空間分けや可読性のために大文字・アンダースコア・ドットも使っていました。そこで提案は、特定の1つの慣習に絞り込むのではなく、複数の慣習を横断的に許容する方向を選んでいます。

一方でスペースとカンマは明確に除外されました。理由はパースの曖昧さです。ツール名をコマンドライン引数やCSV形式のリストに埋め込む場面を想定すると、スペースやカンマを名前の一部として許すと、区切り文字なのか名前の一部なのかを機械的に判別できなくなります。文字数の上限も同様に、人間が読める名前と機械生成された名前の両方を想定しつつ、乱用を防ぐための上限として設定されたものです。セキュリティ面では、書式を標準化すること自体が新たなリスクを持ち込むことはないとSEPは明記しています。

一意性は「サーバー単位」— 複数サーバーを束ねるクライアントが踏む落とし穴

現行仕様が明記するもう1つの重要な点は、ツール名の一意性が単一サーバーの中でのみ保証されるということです。仕様書の注記は次のように述べています。

ツール名の一意性はサーバー単位のスコープです。複数サーバーからツールを集約するクライアントやプロキシは名前の衝突(たとえば2つのサーバーがそれぞれsearchという名前のツールを公開している場合)に遭遇する可能性があり、サーバー識別子をツール名にプレフィックスするなどのディスアンビギュエーション(名前衝突解消)戦略を実装すべきです。

Claude CodeのようにMCPサーバーを複数接続して使うクライアントは、この衝突が実際に起きる場面です。接続した2つのサーバーが同じsearchやget_statusのような一般的な名前のツールを公開していれば、クライアント側で区別する仕組みが必要になります。

仕様が示す対策は、サーバー識別子をツール名の前に付けるプレフィックス方式です。ただし注記はもう1点、見落としやすい制約も添えています。serverInfoに含まれるサーバーのnameフィールドは、サーバー間で一意であることが保証されておらず、ディスアンビギュエーションの根拠として頼るべきではないとされています。つまり「サーバー名を頭に付ければ安全」という単純な実装では、サーバー名自体が別のサーバーと重複するケースを取りこぼします。実装側は接続時に割り当てる固有の識別子か、ユーザーが設定したエイリアスのような、サーバー名とは別の一意な値を衝突解消の軸にする必要があります。

名前が仕様に沿っているかを見分ける

命名規則を読んだだけでは、実際にどの名前がアウトかを判断しづらいものです。同じ意味の名前でも、記号1つで仕様の範囲を外れます。

スラッシュを使った階層表現は、SEP-986の提案段階では有効例として挙げられていました。現行仕様のドキュメントを読まずに提案書だけを参考にすると、この点で仕様から外れた実装をしてしまう可能性があります。ツール名に階層構造を持たせたい場合は、スラッシュではなくドット(admin.tools.listのような形)を使うのが現行仕様に沿った書き方です。

大文字小文字を区別する点も見落としやすい要素です。getUserとgetuserは仕様上まったく別のツール名として扱われます。命名の慣習を途中で崩すと、同じ意味のツールが大文字小文字違いで複数登録され、LLMがどちらを呼ぶべきか判断しづらくなります。1つのサーバー内では大文字小文字の使い方も統一しておくのが安全です。

既存のツール名を変更するときの配慮

サーバーを運用しながら命名規則に合わせてツール名を変更する場面では、呼び出し側のクライアントやエージェントが古い名前を前提に動いていることがあります。SEP-986の提案書は、この移行を扱ううえでの配慮として次の3点を挙げていました。

• 許可文字から外れる、または文字数上限を超える既存のツール名は、少なくとも1つのメジャーバージョンの間はエイリアスとして残し、非推奨の警告を添える
• ツール作者はドキュメントとコードを新しい書式に更新する
• 実装者の移行を助けるガイドを用意する

これらはSEP提案書に書かれた推奨であり、現行の仕様書本体に同一の文言があるわけではありません。ただし、後方互換性を壊さずに命名規則へ追随するための実務的な指針として参考になります。急に名前を変更してツール呼び出しを壊すより、エイリアスを一定期間残す方が、接続先のクライアント側の実装を待つ猶予を作れます。

SEP提案書はさらに、参照実装のイメージとしてMCPコアライブラリ側でツール登録時にこの検証ルールを強制する仕組みにも触れています。サーバー実装者が手作業で命名規則を確認するのではなく、SDKやフレームワークのレイヤーで機械的に弾く方が、規則からの逸脱を防ぎやすいという発想です。

実装者が命名規則を守るべき理由

ツール名はLLM(大規模言語モデル)がツール呼び出しを判断する際の直接の手がかりです。書式が仕様の許可文字から外れていても動くクライアントは多いものの、複数のMCPサーバーを横断してツールを検索・実行するホストやプロキシが増えるほど、非準拠の名前は次のような形で問題になります。

• 名前空間のプレフィックスを自動生成するツールが、想定外の記号でパースに失敗する
• 128文字の上限を超える名前を、切り詰めずにそのまま送るサーバー実装との組み合わせで表示が崩れる
• ドット区切りの階層的な名前(admin.tools.list)を前提にしたUIが、独自の区切り文字を使うサーバーで階層を認識できない

新しくMCPサーバーを実装するなら、ツール名は英数字とアンダースコア・ハイフン・ドットの範囲に収め、128文字以内、同一サーバー内で一意にする。この3点を満たしておけば、現行仕様が想定する相互運用性の恩恵を受けられます。個々のツール定義の残りのフィールド(inputSchemaやannotationsなど)はMCPのTools仕様を読み解くで扱っています。

まとめ — 命名規則は「1〜128文字・4種の記号・サーバー単位の一意性」

MCPのツール名は英数字と_・-・.の4種類の記号のみを使い、1〜128文字に収め、単一サーバー内で一意にすることが現行仕様の要件です。SEP-986の提案段階からはスラッシュが許可文字から外れ、文字数上限が64文字から128文字に広がるという変化がありました。

複数サーバーを束ねる実装では、ツール名の衝突が起こり得ることを前提に、サーバーのnameフィールドに頼らないディスアンビギュエーション戦略を用意しておく必要があります。MCPの基礎から確認したい場合はMCPとはを先に読むと文脈がつかみやすくなります。