MCPサーバーのURLはどこに置く？33のアドレスを調べました

公開されているMCPサーバーは、どんなURLを使っていますか？

多くは、専用のmcp.サブドメインで、パスはたいてい/mcpです。調べたのは、mcp.scorestarling.com/mcpと、ElevenLabsが使っている形のapi.scorestarling.com/v1/mcpのどちらにするかを選ぶときで、ほかのサービスが実際にどうしているかを知りたかったからです。

2026年10月2日のUTC 17:40〜17:42に、27サービスの33のアドレスそれぞれに、認証なしのPOSTを1回送りました。ボディは{}、ヘッダーはAccept: application/json, text/event-stream、タイムアウトは8秒で、記録したのはステータスコードだけです。401は、そのアドレスで何かが応答してトークンを求めていることを意味し、保護されたMCPサーバーがログインを始めるときの形です。404は、そのパスに何も提供されていないことを意味します。アドレスの一部は各サービスが公開しているもので、残りは、どのパスが応答するかを見るために試した変形や推測です。これは有名なサービスのスナップショットであり、全数調査ではありません。この中のどれも、その後に変わっている可能性があります。

404が示す実用上の教訓は、MCPのURLはドメインから導き出せない、ということです。StripeとVercelはホスト名だけで応答し、/mcpでは404を返します。Higgsfieldはその逆です。ElevenLabsには/v1が必要です。クライアントは、与えられたURLをそのまま使い、RFC 9728は、そのURLを、サーバーのメタデータが一致すべきIDと定めています。そのため、同じ文字列を、ドキュメント、インストール用のリンク、プラグインのマニフェストのすべてに載せる必要があります。マニフェストにはさらにばらつきがあります。私たちがインストールしていたプラグインには、gitlab.com自身のパスであるgitlab.com/api/v4/mcpと、mcp.hubspot.com/anthropicがありました。この2つは調べていません。

MCPエンドポイントは、ウェブサイトとホストを共有すべきですか？

そうは考えていません。エンドポイントはソフトウェアのためのもので、セットアップのページは人のためのものですが、どちらもわかりやすいアドレスを欲しがります。2026年10月2日まで、scorestarling.com/mcpは私たちのMCPサーバーだったので、ガイドは別の場所に置くしかありませんでした。そのURLが返す401は、どのクライアントもログインを見つける手がかりなので、ウェブページを兼ねることもできませんでした。

1つのURLで、ブラウザにはページを、クライアントにはMCPを返すことも考えましたが、恒久的な構成としては退けました。リクエストを1回読み違えるだけで、すべてのクライアントでログインの検出が壊れるからです。トランスポート仕様は、クライアントがイベントストリームを開くためにエンドポイントにGETを送ることも認めていて、その返事として期待されるのは、そのストリームか405であって、HTMLのページではありません。

別のホストにすると、ウェブサイトの変更がエンドポイントに及ばないという利点もあります。サイトのリニューアルでエンドポイントが動くことはなく、マーケティングサイトに向くCDNキャッシュやブラウザチャレンジが、エンドポイントの前に置かれることもありません。アシスタントは、ブラウザからではなく、自分たちのインフラからサーバーを呼び出します。Anthropicのコネクタのドキュメントによると、ClaudeはAnthropicのクラウドから接続し、IDプロバイダーの前段にファイアウォールがあるとログインが壊れることがあります。私たちが見た2つの同業サービスも、同じように分けています（2026年10月2日と10月3日にも確認）。Higgsfieldのガイドはhiggsfield.ai/mcp、サーバーはmcp.higgsfield.ai/mcpにあります。ElevenLabsのガイドはelevenlabs.io/mcp、サーバーはapi.elevenlabs.io/v1/mcpにあります。

ScoreStarlingのMCPホストが提供するのは、/mcpと/.well-known/*だけです。それ以外のパスは、ウェブサイト上の同じパスとクエリへ308で転送されるので、ログイン、同意、ページ、ダウンロードのリンク、Cookieは1つのホストにとどまります。ウェブサイトの/mcpは、いま、Claude、ChatGPT、ほかのクライアント向けのセットアップガイドです。

$ curl -si "https://mcp.scorestarling.com/login?x=1"
HTTP/2 308
location: https://app.scorestarling.com/login?x=1

mcp.example.com/mcp、ホスト名だけ、api.example.com/v1/mcpのどれにしますか？

どれでも動きます。そのホストにほかに何が載っているかで選んでください。MCPの認可仕様は、有効な正規のサーバーURIとしてhttps://mcp.example.com/mcpとhttps://mcp.example.comを挙げ、スラッシュが重要な場合を除いて、末尾にスラッシュのない形を求めています。トランスポート仕様が求めるのは、POSTとGETを受け付けるエンドポイントのパスが1つあることだけで、例にはhttps://example.com/mcpを使っています。Anthropicのコネクタのドキュメントは、https://mcp.example.com/mcpを使っています。

小さなルールが2つあります。Streamable HTTPのエンドポイントは/sseで終えないでください。Anthropicのドキュメントによると、そのような形で終わるURLは、Claudeのコネクタのフォームで古いSSEトランスポートが選ばれます。また、意図がない限り末尾のスラッシュは付けないでください。401を返した23のアドレスのうち、スラッシュ付きだったのはGitHubのものだけです。

MCPサーバーを新しいURLに移すには、どうすればいいですか？

しばらくは両方のアドレスで応答し、それぞれが単独で完結するようにします。専用の401、専用のメタデータ、どちらのオーディエンスのトークンも受け付ける、という形です。私たちは4つの手順で移し、すべて、2026年10月2日（UTC）の夕方の1時間以内に本番に入りました：

1. まだ誰も使っていないうちに、エイリアスのサポートを出荷します。1つの設定に、以前のアドレスを並べます。どれもHTTPSで、/mcpで終わります。トークンは、オーディエンスが現在のアドレスかエイリアスなら検証に通り、それ以外のオーディエンスは拒否されます。ホストの許可リスト（Starletteのtrusted hostsと、MCP SDKのDNSリバインディング対策）には、すべてのアドレスとウェブサイトを入れます。エイリアスを設定しなければ、本番はこれまでどおりに動きました。

2. ホストを追加し、そのあとアドレスの切り替えとエイリアスの設定を、1回の変更で行います。新しいサブドメインにDNSレコードを設定し、約6分後に証明書が付き、サーバーがそのホストを信頼するよう設定されるまで、ホストは400を返しました。1回の設定変更で、新しいリソースURLを設定し、古いものをエイリアスとして並べたので、再デプロイ1回で両方が反映されました。手順1が本番に入る前にこれを行っていたら、動いているコードが、ウェブサイト自身のホストを拒否していたはずです。

3. 人がコピーするものをすべて、新しいアドレスに向け直します。セットアップガイド（Claude、Cursor、VS Code向けの、エンコードされたワンクリックのインストール用リンクを含む）、プラグインのマニフェスト、ドキュメントです。

4. トークンのオーディエンスを切り替え、そのあと古いアドレスを廃止します。マイグレーションで、アクセストークンのフックが新しいオーディエンスを発行するようにし、コードを出荷する前にCIがそれを適用しました。エイリアスが残っているあいだは、どちらのオーディエンスのトークンも使えました。そのあとエイリアスを削除し、再デプロイしました。そのリリースから再デプロイまでの数分間は、ウェブサイトの/mcpが、ブラウザにはガイドを、MCPクライアントにはサーバーを返していました。いまはガイドだけを返し、ガイドの古いアドレスである/connectは、そちらへ308で転送します。

メタデータは、見落としやすい部分です。RFC 9728は、resourceがクライアントの接続先のURLと同一であることを求め、Anthropicのドキュメントは、Claudeに入力したURLと等しいことを求めています。そのため、両方が動いていた期間は、各ホストが自分自身について説明し、各401は、自分のホストのドキュメントを指していました：

GET https://scorestarling.com/.well-known/oauth-protected-resource/mcp
→ "resource": "https://scorestarling.com/mcp"

GET https://mcp.scorestarling.com/.well-known/oauth-protected-resource/mcp
→ "resource": "https://mcp.scorestarling.com/mcp"

/mcp自体は転送しませんでした。トランスポート仕様はエンドポイントのリダイレクトについて述べておらず、そのURLは、リソースとトークンのオーディエンスとして、OAuthのハンドシェイクの一部です。そのため、転送せずに、両方のアドレスでMCPを提供しました。それ以外のパスでは、301ではなく308を使うことでメソッドが保たれます。RFC 9110は、クライアントが308のあとにPOSTをGETに変えることを認めていないからです。オーディエンスがトークンに入る仕組みは、リモートMCPサーバーのOAuthメモにあります。

これほど速く移せたのは、ScoreStarlingがまだ小さな招待制のパイロットで、古いアドレスを頼りにしている人がいなかったからです。エイリアスがなくなったあとは、scorestarling.com/mcpのままで設定されているクライアントは、つなぎ直す必要があります。運用手順書では、すでに新しいアドレスにつないでいるが、古いオーディエンスのトークンを持っているクライアントは、401のinvalid_tokenを1回受け取り、更新して、新しいオーディエンスのトークンを受け取ることになっています。本物のClaudeやChatGPTのクライアントがそうなるのは、まだ確認していません。実際のユーザーがいる場合は、古いアドレスへのアクセスが止まるまで、エイリアスを残してください。

移行中に何が壊れましたか？

途中で、小さな問題が3つ起きました：

• 確認用のスクリプトが、resource.replace('/mcp', '/.well-known/oauth-protected-resource/mcp')でメタデータのURLを組み立てていました。古いアドレスでは、それで動きました。https://mcp.scorestarling.com/mcpでは、/mcpが//mcp.の中にも一致してしまい、結果はhttps://.well-known/oauth-protected-resource/mcp.scorestarling.com/.well-known/oauth-protected-resource/mcpになりました。代わりに、URLを解析した部品から組み立ててください。スキームとホスト、次にwell-knownのセグメント、そしてパスの順です。
• 長くなったアドレスは、幅320ピクセルの画面で、ガイドからはみ出していました。インラインのコードを折り返せるようにして解決しました。
• Railwayのコマンドラインツールでエイリアスの変数を削除しても、変更がステージされるだけで、古いアドレスは、手動で再デプロイするまで受け付けられたままでした。

MCPサーバーのアドレスを選ぶためのチェックリスト

• エンドポイントには、人向けのものを何も提供しないホストを割り当てます。mcp.に自分のドメインを付けた形が、サンプルでいちばん多い選び方です。
• パスは一度だけ決めます。/mcpがいちばん多く、ホスト名だけも有効です。末尾のスラッシュと、/sseで終わるパスは避けます。
• 人向けのセットアップのページは、メインサイトの、推測できるアドレスに置き、ナビゲーションからリンクします。
• RFC 9728のメタデータを、正確なURLに対して、/.well-known/oauth-protected-resourceにパスを加えた場所と、ルートで提供し、resourceをクライアントが使ったアドレスと等しくします。
• そのURLをトークンのオーディエンスにし、移行が必要になる前に、エイリアスのサポートを作っておきます。
• MCPホストのそれ以外のパスはすべて、クエリ文字列を保ったまま、308でウェブサイトへ転送します。
• ブラウザチャレンジとHTMLのキャッシュは、MCPホストに近づけません。
• 同じ文字列を、あらゆる場所（ガイド、インストール用のリンク、プラグインのマニフェスト、ドキュメント）で公開し、すべてのコピーが一致していることをテストします。
• 移行の手順は、まずエイリアス、次に新しいアドレスとエイリアスを1回の変更で、すべてのコピーを向け直し、オーディエンスを切り替え、古いアドレスへのアクセスが止まってから廃止する、です。