Where should an MCP server live? We checked 33 addresses

What URLs do public MCP servers use?

Mostly a dedicated mcp. subdomain, usually with /mcp as the path. We went looking while choosing between mcp.scorestarling.com/mcp and api.scorestarling.com/v1/mcp, the form ElevenLabs uses, because we wanted to know what other services actually do.

On October 2, 2026, between 17:40 and 17:42 UTC, we sent one unauthenticated POST to each of 33 addresses from 27 services, with {} as the body, an Accept: application/json, text/event-stream header and an 8-second timeout, and recorded only the status code. A 401 means something at that address answered and wants a token, which is how a protected MCP server starts sign-in. A 404 means nothing is served at that path. Some addresses were published by the services; others were variants and guesses we tried to see which paths answer. It’s a snapshot of well-known services, not a census, and any of these may have changed since.

The 404s carry the practical lesson: an MCP URL can’t be derived from a domain. Stripe and Vercel answer at the bare host and return 404 at /mcp; Higgsfield is the other way round; ElevenLabs needs its /v1. A client uses exactly the URL it is given, and RFC 9728 makes that URL the identity the server’s metadata must match, so the same string has to appear in your docs, install links and plugin manifests. Manifests show still more variety: among the plugins we had installed were gitlab.com/api/v4/mcp, a path on gitlab.com itself, and mcp.hubspot.com/anthropic. We didn’t probe those two.

Should the MCP endpoint share a host with your website?

We don’t think so. The endpoint is for software and the setup page is for people, and both want the obvious address. Until October 2, 2026, scorestarling.com/mcp was our MCP server, so the guide had to live somewhere else; and since that URL’s 401 is how every client discovers sign-in, it couldn’t also be a web page.

We considered serving both at one URL, a page to browsers and MCP to clients, and rejected it as a permanent setup: one wrong guess about a request breaks sign-in discovery for every client. The transport spec also lets clients send GET to the endpoint to open an event stream, and expects either that stream or a 405 in reply, not an HTML page.

A separate host also keeps website changes away from the endpoint: a redesign can’t move it, and a CDN cache or browser challenge that suits a marketing site never sits in front of it. Assistants call the server from their own infrastructure, not from a browser: Anthropic’s connector docs say Claude connects from Anthropic’s cloud, and that a firewall in front of the identity provider can break sign-in. Two peers we looked at split the same way (checked October 2 and again October 3, 2026): Higgsfield’s guide is at higgsfield.ai/mcp and its server at mcp.higgsfield.ai/mcp; ElevenLabs’ guide is at elevenlabs.io/mcp and its server at api.elevenlabs.io/v1/mcp.

Our MCP host serves only /mcp and /.well-known/*. Every other path gets a 308 to the same path and query on the website, so sign-in, consent, pages, download links and cookies stay on one host. The website’s /mcp is now the setup guide for Claude, ChatGPT and other clients.

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

mcp.example.com/mcp, a bare host, or api.example.com/v1/mcp?

Any of them works; choose by what else lives on the host. The MCP authorization spec lists https://mcp.example.com/mcp and https://mcp.example.com among valid canonical server URIs and asks for the form without a trailing slash unless the slash matters. The transport spec only requires one endpoint path that accepts POST and GET, with https://example.com/mcp as its example, and Anthropic’s connector docs use https://mcp.example.com/mcp.

Two smaller rules. Don’t end a Streamable HTTP endpoint in /sse: Anthropic’s docs say a URL ending that way selects the older SSE transport in Claude’s connector form. And leave off the trailing slash unless you mean it; of the 23 addresses that answered 401, only GitHub’s was written with one.

How do you move an MCP server to a new URL?

Serve both addresses for a while, and make each one complete on its own: its own 401, its own metadata, and tokens for either audience. We moved in four steps, all live within an hour on the evening of October 2, 2026 (UTC):

1. Ship alias support while nothing uses it. One setting lists earlier addresses, each HTTPS and ending in /mcp. A token verifies if its audience is the current address or an alias; any other audience is refused. The host allow-lists (Starlette’s trusted hosts and the MCP SDK’s DNS-rebinding protection) hold every address plus the website. With no alias set, production behaved as before.

2. Add the host, then switch the address and set the alias in one change. The new subdomain got its DNS records, the certificate followed about six minutes later, and the host answered 400 until our server was told to trust it. One configuration change set the new resource URL and listed the old one as an alias, so a single redeploy picked up both. Doing this before step 1 was live would have made the running code refuse the website’s own host.

3. Repoint everything people copy: the setup guide, including the encoded one-click install links for Claude, Cursor and VS Code, the plugin manifests and the docs.

4. Switch the token audience, then retire the old address. A migration made our access-token hook issue the new audience, and CI applied it before the code shipped; while the alias stood, tokens with either audience still worked. Then we removed the alias and redeployed. For the few minutes between that release and the redeploy, the website’s /mcp sent browsers the guide and MCP clients the server. It now serves only the guide, and the guide’s old address, /connect, answers with a 308 to it.

The metadata is the easy part to miss. RFC 9728 requires its resource to be identical to the URL the client connected to, and Anthropic’s docs require it to equal the URL as typed into Claude. So during the overlap each host described itself, and each 401 pointed to its own host’s document:

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"

We didn’t redirect /mcp itself. The transport spec doesn’t describe redirects for the endpoint, and its URL is part of the OAuth handshake as the resource and the token audience, so we served MCP at both addresses instead. For every other path, a 308 rather than a 301 keeps the method, since RFC 9110 doesn’t let a client turn a POST into a GET after a 308. How the audience gets into our tokens is in our notes on MCP OAuth.

We could move that fast because ScoreStarling was still a small invite-only pilot, and nobody relied on the old address yet. Once the alias is gone, a client still configured with scorestarling.com/mcp has to reconnect. Our runbook expects a client already on the new address but holding an old-audience token to get one 401 invalid_token, refresh, and receive the new audience; we haven’t watched a real Claude or ChatGPT client do that. With real users, keep the alias until traffic to the old address stops.

What broke during the move?

Three small things went wrong along the way:

• A check script built the metadata URL with resource.replace('/mcp', '/.well-known/oauth-protected-resource/mcp'). On the old address that worked. On https://mcp.scorestarling.com/mcp, /mcp also matches inside //mcp., and the result was https://.well-known/oauth-protected-resource/mcp.scorestarling.com/.well-known/oauth-protected-resource/mcp. Build the URL from its parsed parts instead: scheme and host, then the well-known segment, then the path.
• The longer address overflowed our guide on a 320-pixel-wide screen until inline code was allowed to wrap.
• Deleting the alias variable with Railway’s command-line tool only staged the change; the old address stayed accepted until we redeployed by hand.

A checklist for choosing an MCP server address

• Give the endpoint a host that serves nothing for people; mcp. plus your domain is the common choice in our sample.
• Pick a path once. /mcp is the most common and a bare host is also valid; avoid a trailing slash and a path ending in /sse.
• Keep the setup page for people on your main site, at an address they can guess, and link it from your navigation.
• Serve RFC 9728 metadata for the exact URL, at /.well-known/oauth-protected-resource plus your path and at the root, with resource equal to the address the client used.
• Make that URL the token audience, and build alias support before you need to move.
• Redirect every other path on the MCP host to your website with a 308, keeping the query string.
• Keep browser challenges and HTML caching away from the MCP host.
• Publish one string everywhere (guide, install links, plugin manifests, docs) and test that every copy matches.
• To move: aliases first, then the new address and the alias in one change, every copy repointed, the audience switched, and the old address retired after its traffic stops.