Quelle adresse pour un serveur MCP ? Nous en avons vérifié 33

Quelles URL utilisent les serveurs MCP publics ?

Surtout un sous-domaine mcp. dédié, le plus souvent avec /mcp comme chemin. Nous sommes allés voir ce qui se fait en hésitant entre mcp.scorestarling.com/mcp et api.scorestarling.com/v1/mcp, la forme qu’utilise ElevenLabs, parce que nous voulions savoir ce que font vraiment les autres services.

Le 2 octobre 2026, entre 17 h 40 et 17 h 42 UTC, nous avons envoyé un POST non authentifié à chacune de 33 adresses de 27 services, avec {} comme corps, un en-tête Accept : application/json, text/event-stream et un délai d’attente de 8 secondes, et nous n’avons noté que le code d’état. Un 401 signifie que quelque chose à cette adresse a répondu et veut un jeton, ce qui est la façon dont un serveur MCP protégé lance la connexion. Un 404 signifie que rien n’est servi à ce chemin. Certaines adresses étaient publiées par les services ; d’autres étaient des variantes et des suppositions que nous avons essayées pour voir quels chemins répondent. C’est un instantané de services connus, pas un recensement, et chacun peut avoir changé depuis.

Les 404 portent la leçon pratique : on ne peut pas déduire une URL MCP d’un domaine. Stripe et Vercel répondent sur l’hôte seul et renvoient un 404 à /mcp ; chez Higgsfield, c’est l’inverse ; ElevenLabs a besoin de son /v1. Un client utilise exactement l’URL qu’on lui donne, et la RFC 9728 fait de cette URL l’identité à laquelle les métadonnées du serveur doivent correspondre : la même chaîne doit donc figurer dans votre documentation, vos liens d’installation et vos manifestes de plug-in. Les manifestes montrent une variété plus grande encore : parmi les plug-ins que nous avions installés, il y avait gitlab.com/api/v4/mcp, un chemin sur gitlab.com même, et mcp.hubspot.com/anthropic. Nous n’avons pas sondé ces deux-là.

Le point d’accès MCP doit-il partager un hôte avec votre site web ?

Nous ne le pensons pas. Le point d’accès s’adresse aux logiciels et le guide de connexion aux personnes, et les deux veulent l’adresse évidente. Jusqu’au 2 octobre 2026, scorestarling.com/mcp était notre serveur MCP : le guide devait donc se trouver ailleurs ; et comme le 401 de cette URL est la façon dont chaque client découvre la connexion, elle ne pouvait pas être aussi une page web.

Nous avons envisagé de servir les deux à une même URL, une page aux navigateurs et MCP aux clients, et l’avons rejeté comme configuration permanente : une seule erreur d’appréciation sur une requête casse la découverte de la connexion pour tous les clients. La spécification du transport permet aussi aux clients d’envoyer un GET au point d’accès pour ouvrir un flux d’événements, et attend en retour ce flux ou un 405, pas une page HTML.

Un hôte séparé protège aussi le point d’accès des changements du site : une refonte ne peut pas le déplacer, et un cache CDN ou une vérification du navigateur adaptés à un site marketing ne se trouvent jamais devant lui. Les assistants appellent le serveur depuis leur propre infrastructure, pas depuis un navigateur : la documentation des connecteurs d’Anthropic indique que Claude se connecte depuis le cloud d’Anthropic, et qu’un pare-feu placé devant le fournisseur d’identité peut casser la connexion. Deux services comparables que nous avons examinés séparent de la même façon (vérifié le 2 octobre, puis de nouveau le 3 octobre 2026) : le guide de Higgsfield est à higgsfield.ai/mcp et son serveur à mcp.higgsfield.ai/mcp ; le guide d’ElevenLabs est à elevenlabs.io/mcp et son serveur à api.elevenlabs.io/v1/mcp.

Notre hôte MCP ne sert que /mcp et /.well-known/*. Tout autre chemin reçoit un 308 vers le même chemin et la même chaîne de requête sur le site, si bien que la connexion, le consentement, les pages, les liens de téléchargement et les cookies restent sur un seul hôte. Le /mcp du site est désormais le guide de connexion pour Claude, ChatGPT et d’autres clients.

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

mcp.example.com/mcp, un hôte seul ou api.example.com/v1/mcp ?

Toutes fonctionnent ; choisissez selon ce qui vit d’autre sur l’hôte. La spécification d’autorisation de MCP cite https://mcp.example.com/mcp et https://mcp.example.com parmi les URI canoniques de serveur valides et demande la forme sans barre oblique finale, sauf si cette barre compte. La spécification du transport exige seulement un chemin de point d’accès qui accepte POST et GET, avec https://example.com/mcp pour exemple, et la documentation des connecteurs d’Anthropic utilise https://mcp.example.com/mcp.

Deux règles plus modestes. Ne terminez pas un point d’accès Streamable HTTP par /sse : la documentation d’Anthropic dit qu’une URL qui se termine ainsi sélectionne l’ancien transport SSE dans le formulaire de connecteur de Claude. Et laissez de côté la barre oblique finale, sauf si vous la voulez vraiment ; sur les 23 adresses qui ont répondu 401, seule celle de GitHub en avait une.

Comment déplacer un serveur MCP vers une nouvelle URL ?

Servez les deux adresses un temps, et rendez chacune complète par elle-même : son propre 401, ses propres métadonnées, et des jetons pour l’une ou l’autre audience. Nous avons procédé en quatre étapes, toutes en ligne en moins d’une heure, le soir du 2 octobre 2026 (UTC) :

1. Livrez la prise en charge des alias tant que rien ne s’en sert. Un réglage liste les anciennes adresses, toutes en HTTPS et se terminant par /mcp. Un jeton est valide si son audience est l’adresse actuelle ou un alias ; toute autre audience est refusée. Les listes d’hôtes autorisés (les hôtes de confiance de Starlette et la protection contre le DNS rebinding du SDK MCP) contiennent chaque adresse plus le site. Sans alias défini, la production se comportait comme avant.

2. Ajoutez l’hôte, puis changez l’adresse et définissez l’alias en une seule modification. Le nouveau sous-domaine a reçu ses enregistrements DNS, le certificat a suivi environ six minutes plus tard, et l’hôte a répondu 400 tant que notre serveur n’a pas été configuré pour lui faire confiance. Une seule modification de configuration a défini la nouvelle URL de ressource et listé l’ancienne comme alias, de sorte qu’un seul redéploiement a pris en compte les deux. Si nous l’avions fait avant que l’étape 1 soit en ligne, le code en cours d’exécution aurait refusé l’hôte même du site.

3. Repointez tout ce que les gens copient : le guide de connexion, y compris les liens d’installation en un clic encodés pour Claude, Cursor et VS Code, les manifestes de plug-in et la documentation.

4. Changez l’audience des jetons, puis retirez l’ancienne adresse. Une migration a fait émettre la nouvelle audience par notre hook de jeton d’accès, et l’intégration continue l’a appliquée avant la livraison du code ; tant que l’alias était en place, les jetons des deux audiences fonctionnaient. Ensuite nous avons retiré l’alias et redéployé. Pendant les quelques minutes entre cette version et le redéploiement, le /mcp du site envoyait le guide aux navigateurs et le serveur aux clients MCP. Il ne sert plus que le guide, et l’ancienne adresse du guide, /connect, répond par un 308 vers lui.

Les métadonnées sont la partie facile à oublier. La RFC 9728 exige que son champ resource soit identique à l’URL à laquelle le client s’est connecté, et la documentation d’Anthropic exige qu’il soit égal à l’URL saisie dans Claude. Pendant la période de recouvrement, chaque hôte se décrivait donc lui-même, et chaque 401 pointait vers le document de son propre hôte :

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"

Nous n’avons pas redirigé /mcp lui-même. La spécification du transport ne décrit pas de redirections pour le point d’accès, et son URL fait partie de l’échange OAuth comme ressource et comme audience du jeton ; nous avons donc servi MCP aux deux adresses. Pour tous les autres chemins, un 308 plutôt qu’un 301 conserve la méthode, puisque la RFC 9110 ne permet pas à un client de transformer un POST en GET après un 308. La façon dont l’audience entre dans nos jetons est décrite dans nos notes sur l’OAuth d’un serveur MCP distant.

Nous avons pu aller aussi vite parce que ScoreStarling n’était encore qu’un petit pilote sur invitation et que personne ne dépendait encore de l’ancienne adresse. Une fois l’alias supprimé, un client encore configuré avec scorestarling.com/mcp doit se reconnecter. Notre procédure d’exploitation prévoit qu’un client déjà sur la nouvelle adresse mais détenant un jeton de l’ancienne audience reçoive un 401 invalid_token, renouvelle son jeton et obtienne la nouvelle audience ; nous n’avons pas vu un vrai client Claude ou ChatGPT le faire. Avec de vrais utilisateurs, gardez l’alias jusqu’à ce que le trafic vers l’ancienne adresse s’arrête.

Qu’est-ce qui a cassé pendant la migration ?

Trois petites choses ont mal tourné en chemin :

• Un script de vérification construisait l’URL des métadonnées avec resource.replace('/mcp', '/.well-known/oauth-protected-resource/mcp'). Avec l’ancienne adresse, cela marchait. Avec https://mcp.scorestarling.com/mcp, /mcp correspond aussi à l’intérieur de //mcp., et le résultat était https://.well-known/oauth-protected-resource/mcp.scorestarling.com/.well-known/oauth-protected-resource/mcp. Construisez plutôt l’URL à partir de ses parties analysées : schéma et hôte, puis le segment well-known, puis le chemin.
• L’adresse plus longue débordait de notre guide sur un écran de 320 pixels de large, jusqu’à ce que le code en ligne puisse passer à la ligne.
• Supprimer la variable d’alias avec l’outil en ligne de commande de Railway n’a fait que mettre la modification en attente ; l’ancienne adresse est restée acceptée jusqu’à ce que nous redéployions à la main.

Une liste de contrôle pour choisir l’adresse d’un serveur MCP

• Donnez au point d’accès un hôte qui ne sert rien aux personnes ; mcp. plus votre domaine est le choix courant dans notre échantillon.
• Choisissez un chemin une fois pour toutes. /mcp est le plus courant et un hôte seul est aussi valide ; évitez la barre oblique finale et un chemin se terminant par /sse.
• Gardez le guide de connexion destiné aux personnes sur votre site principal, à une adresse qu’elles peuvent deviner, avec un lien dans votre navigation.
• Servez les métadonnées de la RFC 9728 pour l’URL exacte, à /.well-known/oauth-protected-resource suivi de votre chemin et à la racine, avec resource égal à l’adresse utilisée par le client.
• Faites de cette URL l’audience des jetons, et construisez la prise en charge des alias avant d’avoir besoin de migrer.
• Redirigez tous les autres chemins de l’hôte MCP vers votre site avec un 308, en conservant la chaîne de requête.
• Tenez les vérifications du navigateur et la mise en cache HTML à l’écart de l’hôte MCP.
• Publiez la même chaîne partout (guide, liens d’installation, manifestes de plug-in, documentation) et vérifiez par un test que toutes les copies correspondent.
• Pour migrer : d’abord les alias, puis la nouvelle adresse et l’alias en une seule modification, chaque copie repointée, l’audience changée, et l’ancienne adresse retirée quand son trafic s’arrête.