[ 提言 ] 公式MCPサーバーを公開するときは、サービス名をprefixとして付与しよう

Model Context Protocol（MCP）が普及するにつれ、「複数のMCPサーバーが、同じ名前のツールを提供する」場面が増えてきています。この記事では、「なぜツール名が衝突すると良くないのか？」や「公式MCPサーバーを提供する際に、意識すると良いポイント」について紹介します。

MCPにおけるツール名の衝突について

複数のMCPサーバーが同じ名前のツールを提供すると、何が起きるでしょうか？Cursorのコミュニティフォーラムには「MCP Tools Name Collision Causing Cross-Service Tool Call Failures」という投稿があります。ここでは、GitHubとObsidianのMCPサーバーを併用した際に同名ツール間で衝突が発生したと報告されていました。結果として、意図したツールではなく誤ったツールが呼び出され、予測不能な動作やエラーを引き起こした経験が紹介されています。

この他にも、たとえば AWS と Stripe でも同様の問題が発生します。こちらはsearch_documentationツールを両サーバーが提供しているため、誤ったツールを利用した検索が実行されるケースが発生しています。スクリーンショットを見ると、AWSに関する質問をStripeのドキュメントへ検索しようとしていることがわかります。

このように、ツールの名前が重複することによって意図しない操作やデータ取得が発生してしまう可能性が、現在のMCPサーバーにはあります。

prefix設定による解決

この問題の解決策は、「ツール名を重複させないこと」です。汎用的なツール名を設定してしまうと、先ほどのsearch_documentationツールのように複数のMCPサーバーが同名のツールを提供するリスクが発生します。サービス提供社自身が公式のMCPサーバーを提供する場合は、自社のサービス名をprefixとして設定することで、重複リスクを大きく下げることができます。

たとえば以下のようなツール名はどうでしょうか？公式ツール以外のカスタムツールによる衝突が発生するリスクはまだ残っていますが、それでも先の例のような公式ツール同士の衝突リスクは大幅に減らせるでしょう。

• github_create_issue
• slack_send_message
• gdrive_list_files

少なくとも、以下のようなツールに比べると、圧倒的に衝突リスクは少ないと言えます。

• create_issue → どこに作るの？GitHub ? Jira ? Backlog ?
• send_message → 何で送信するの？メール？ LINE ?
• list_files → どこのファイルを見ますか？

このアプローチは一部のコマンドラインツールですでに採用されています。例えばMCPツールのコマンドライン版は「mcp」という名前の衝突を避けるため、「mcpt」という代替名を提供しているんですよ。こうした対応は、名前空間の重要性を認識した実践例といえるでしょう。

Stripe　がサービス名をツールに付与する提案に対応してくれました！

AWS と Stripe でドキュメント検索の MCP が衝突する問題については、前職で Stripe に在籍していたこともあり、GitHub にてレポートと要望提案を行なっていました。

https://github.com/stripe/agent-toolkit/pull/64

すると1営業日以内に開発チームから、「全部の tool に prefix を付与するのは時間がかかる。だけどドキュメント検索については対応したよ」というコメントをいただきました。

リンクされていた Pull Request を見ると、search_documentation ツールが search_stripe_documentation にリネームされています。

https://github.com/stripe/agent-toolkit/pull/66/files

まだリリースはされていない様子ですが、v0.2.1よりも新しいバージョンでは、ツール名衝突問題が解決されていると期待できそうです。

エコシステム全体の発展のために

MCPを利用した業務フローや開発の流れは、もはや不可避な流れになってきているでしょう。そして実際の開発場面では、サービスに必要な複数のSaaSやプラットフォームについて検索・操作するMCPサーバーを登録して利用することとなります。

しかしこのようなツール名衝突のリスクが残っていると、「確実にドキュメントを検索させるため、このMCPサーバーを一時的にオフにする」や「AIサービスごとに登録するMCPを変える」といった迂回策を取らざるを得ません。しかしこのような対応では、本来MCPが解決するはずの効率化や自動化の恩恵を十分に得られなくなります。

このような問題を解決し、より効率的なワークフローを実現するためにも、公式MCPサーバーの提供を検討されている皆様は、サービス名prefixの付与についてご検討ください。

[追記] MCP側でネームスペースの議論がありました

Stripe のGitHubを読み返すと、どうやら MCP 側もこの問題を認識している様子です。RFC としてネームスペースの議論はすでに開始されており、com.githubのようなreverse domain namespacing方式も含めた実装が検討されています。

https://github.com/modelcontextprotocol/modelcontextprotocol/pull/334

この RFC がリリースされ、各社がこの仕様に追従するようになれば、衝突問題も回避しやすくなりそうです。

とはいえ現状まだ無い仕様ですので、やはり今MCPサーバーをリリースする場合は、サービス名をツール名へ含める方がベターと言えるでしょう。

参考リンク

1. MCP Tools Name Collision Causing Cross-Service Tool Call Failures
2. Spring AI Issue: Multiple tools with the same name
3. MCP仕様：ツール定義