Wo sollte ein MCP-Server liegen? Wir haben 33 Adressen geprüft

Welche URLs nutzen öffentliche MCP-Server?

Meist eine eigene Subdomain mcp., in der Regel mit /mcp als Pfad. Wir haben uns umgesehen, als wir zwischen mcp.scorestarling.com/mcp und api.scorestarling.com/v1/mcp wählten, der Form, die ElevenLabs verwendet, weil wir wissen wollten, was andere Dienste tatsächlich tun.

Am 2. Oktober 2026 haben wir zwischen 17:40 und 17:42 UTC an jede von 33 Adressen von 27 Diensten ein einziges POST ohne Authentifizierung gesendet, mit {} als Body, einem Header Accept: application/json, text/event-stream und einem Timeout von 8 Sekunden, und nur den Statuscode festgehalten. Ein 401 bedeutet, dass an dieser Adresse etwas antwortete und ein Token will, so beginnt ein geschützter MCP-Server die Anmeldung. Ein 404 bedeutet, dass unter diesem Pfad nichts ausgeliefert wird. Einige Adressen haben die Dienste selbst veröffentlicht; andere waren Varianten und Vermutungen, mit denen wir ausprobiert haben, welche Pfade antworten. Das ist eine Momentaufnahme bekannter Dienste, keine Vollerhebung, und jede dieser Adressen kann sich seither geändert haben.

Die 404er enthalten die praktische Lehre: Eine MCP-URL lässt sich nicht aus einer Domain ableiten. Stripe und Vercel antworten am reinen Host und liefern unter /mcp ein 404; bei Higgsfield ist es umgekehrt; ElevenLabs braucht sein /v1. Ein Client verwendet genau die URL, die er bekommt, und RFC 9728 macht diese URL zur Identität, mit der die Metadaten des Servers übereinstimmen müssen, deshalb muss derselbe String in deiner Dokumentation, in Installationslinks und in Plug-in-Manifesten stehen. Manifeste zeigen noch mehr Vielfalt: Unter den Plug-ins, die wir installiert hatten, waren gitlab.com/api/v4/mcp, ein Pfad auf gitlab.com selbst, und mcp.hubspot.com/anthropic. Diese beiden haben wir nicht angefragt.

Sollte der MCP-Endpunkt einen Host mit deiner Website teilen?

Unserer Meinung nach nicht. Der Endpunkt ist für Software und die Einrichtungsseite für Menschen, und beide wollen die naheliegende Adresse. Bis zum 2. Oktober 2026 war scorestarling.com/mcp unser MCP-Server, die Anleitung musste also woanders liegen; und da das 401 dieser URL der Weg ist, auf dem jeder Client die Anmeldung findet, konnte sie nicht zugleich eine Webseite sein.

Wir haben erwogen, beides unter einer URL zu bedienen, eine Seite für Browser und MCP für Clients, und das als Dauerlösung verworfen: Eine falsche Vermutung über eine Anfrage zerstört die Erkennung der Anmeldung für jeden Client. Die Transport-Spezifikation lässt Clients außerdem ein GET an den Endpunkt senden, um einen Event-Stream zu öffnen, und erwartet als Antwort entweder diesen Stream oder ein 405, keine HTML-Seite.

Ein getrennter Host hält außerdem Änderungen an der Website vom Endpunkt fern: Ein Redesign kann ihn nicht verschieben, und ein CDN-Cache oder eine Browser-Challenge, die zu einer Marketing-Seite passt, steht nie davor. Assistenten rufen den Server von ihrer eigenen Infrastruktur aus auf, nicht aus einem Browser: Die Konnektor-Dokumentation von Anthropic sagt, Claude verbinde sich aus der Cloud von Anthropic, und dass eine Firewall vor dem Identity Provider die Anmeldung stören kann. Zwei Vergleichsdienste, die wir uns ansahen, trennen es genauso (geprüft am 2. und noch einmal am 3. Oktober 2026): Die Anleitung von Higgsfield liegt unter higgsfield.ai/mcp und sein Server unter mcp.higgsfield.ai/mcp; die Anleitung von ElevenLabs liegt unter elevenlabs.io/mcp und sein Server unter api.elevenlabs.io/v1/mcp.

Unser MCP-Host liefert nur /mcp und /.well-known/* aus. Jeder andere Pfad bekommt ein 308 auf denselben Pfad samt Query auf der Website, damit Anmeldung, Zustimmung, Seiten, Download-Links und Cookies auf einem Host bleiben. Das /mcp der Website ist jetzt die Einrichtungsanleitung für Claude, ChatGPT und andere 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, ein reiner Host oder api.example.com/v1/mcp?

Jede funktioniert; wähle danach, was sonst auf dem Host liegt. Die MCP-Autorisierungsspezifikation nennt https://mcp.example.com/mcp und https://mcp.example.com unter den gültigen kanonischen Server-URIs und bittet um die Form ohne abschließenden Schrägstrich, sofern der Schrägstrich nicht wichtig ist. Die Transport-Spezifikation verlangt nur einen Endpunktpfad, der POST und GET annimmt, mit https://example.com/mcp als Beispiel, und die Konnektor-Dokumentation von Anthropic verwendet https://mcp.example.com/mcp.

Zwei kleinere Regeln. Beende einen Streamable-HTTP-Endpunkt nicht auf /sse: Laut Anthropic wählt eine URL, die so endet, im Konnektor-Formular von Claude den älteren SSE-Transport. Und lass den abschließenden Schrägstrich weg, wenn du ihn nicht brauchst; von den 23 Adressen, die mit 401 antworteten, war nur die von GitHub mit einem abschließenden Schrägstrich geschrieben.

Wie zieht man einen MCP-Server auf eine neue URL um?

Betreibe beide Adressen eine Zeit lang und mach jede für sich vollständig: mit eigenem 401, eigenen Metadaten und Tokens für beide Audiences. Wir sind in vier Schritten umgezogen, alle am Abend des 2. Oktober 2026 (UTC) innerhalb einer Stunde live:

1. Alias-Unterstützung ausliefern, solange sie noch niemand nutzt. Eine Einstellung listet frühere Adressen auf, jede HTTPS und auf /mcp endend. Ein Token wird akzeptiert, wenn seine Audience die aktuelle Adresse oder ein Alias ist; jede andere Audience wird abgelehnt. Die Host-Allowlists (die Trusted Hosts von Starlette und der DNS-Rebinding-Schutz des MCP-SDK) enthalten jede Adresse plus die Website. Ohne gesetztes Alias verhielt sich die Produktion wie zuvor.

2. Den Host hinzufügen, dann die Adresse umstellen und das Alias in einer Änderung setzen. Die neue Subdomain bekam ihre DNS-Einträge, das Zertifikat folgte etwa sechs Minuten später, und der Host antwortete mit 400, bis unser Server angewiesen wurde, ihm zu vertrauen. Eine Konfigurationsänderung setzte die neue Ressourcen-URL und führte die alte als Alias auf, sodass ein einziges Redeploy beides übernahm. Hätten wir das getan, bevor Schritt 1 live war, hätte der laufende Code den eigenen Host der Website abgelehnt.

3. Alles umstellen, was Menschen kopieren: die Einrichtungsanleitung, einschließlich der kodierten One-Click-Installationslinks für Claude, Cursor und VS Code, die Plug-in-Manifeste und die Dokumentation.

4. Die Token-Audience umstellen, dann die alte Adresse abschalten. Eine Migration ließ unseren Access-Token-Hook die neue Audience ausstellen, und die CI wendete sie an, bevor der Code ausgeliefert wurde; solange das Alias bestand, funktionierten Tokens mit beiden Audiences. Dann haben wir das Alias entfernt und neu deployt. In den wenigen Minuten zwischen diesem Release und dem Redeploy schickte das /mcp der Website Browsern die Anleitung und MCP-Clients den Server. Jetzt liefert es nur noch die Anleitung, und die alte Adresse der Anleitung, /connect, antwortet mit einem 308 darauf.

Die Metadaten übersieht man leicht. RFC 9728 verlangt, dass seine resource mit der URL identisch ist, mit der sich der Client verbunden hat, und die Dokumentation von Anthropic verlangt, dass sie der in Claude eingetippten URL entspricht. Während der Überlappung beschrieb sich also jeder Host selbst, und jedes 401 verwies auf das Dokument des eigenen Hosts:

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"

Wir haben /mcp selbst nicht umgeleitet. Die Transport-Spezifikation beschreibt keine Weiterleitungen für den Endpunkt, und seine URL ist als Ressource und Token-Audience Teil des OAuth-Handshakes, also haben wir MCP stattdessen unter beiden Adressen bedient. Für jeden anderen Pfad behält ein 308 statt eines 301 die Methode, denn RFC 9110 erlaubt einem Client nicht, nach einem 308 aus einem POST ein GET zu machen. Wie die Audience in unsere Tokens kommt, steht in unseren Notizen zu OAuth bei Remote-MCP-Servern.

Wir konnten so schnell umziehen, weil ScoreStarling noch ein kleiner Pilot nur mit Einladung war und sich noch niemand auf die alte Adresse verließ. Sobald das Alias weg ist, muss ein Client, der noch auf scorestarling.com/mcp konfiguriert ist, sich neu verbinden. Unser Runbook erwartet, dass ein Client, der schon auf der neuen Adresse ist, aber ein Token mit alter Audience hält, ein einziges 401 invalid_token bekommt, das Token erneuert und die neue Audience erhält; gesehen, wie ein echter Claude- oder ChatGPT-Client das tut, haben wir es nicht. Mit echten Nutzern behalte das Alias, bis der Traffic zur alten Adresse aufhört.

Was ging beim Umzug schief?

Drei Kleinigkeiten gingen unterwegs schief:

• Ein Prüfskript baute die Metadaten-URL mit resource.replace('/mcp', '/.well-known/oauth-protected-resource/mcp'). Bei der alten Adresse funktionierte das. Bei https://mcp.scorestarling.com/mcp passt /mcp auch innerhalb von //mcp., und das Ergebnis war https://.well-known/oauth-protected-resource/mcp.scorestarling.com/.well-known/oauth-protected-resource/mcp. Baue die URL stattdessen aus ihren geparsten Teilen: Schema und Host, dann das Well-known-Segment, dann den Pfad.
• Die längere Adresse lief in unserer Anleitung auf einem 320 Pixel breiten Bildschirm über, bis Inline-Code umbrechen durfte.
• Das Löschen der Alias-Variable mit dem Kommandozeilenwerkzeug von Railway hat die Änderung nur vorgemerkt; die alte Adresse wurde weiter akzeptiert, bis wir von Hand neu deployt haben.

Eine Checkliste für die Wahl der Adresse eines MCP-Servers

• Gib dem Endpunkt einen Host, der nichts für Menschen ausliefert; mcp. plus deine Domain ist in unserer Stichprobe die übliche Wahl.
• Wähle den Pfad einmal. /mcp ist am häufigsten, und ein reiner Host ist auch gültig; vermeide einen abschließenden Schrägstrich und einen Pfad, der auf /sse endet.
• Halte die Einrichtungsseite für Menschen auf deiner Hauptseite, unter einer Adresse, die sie erraten können, und verlinke sie in deiner Navigation.
• Liefere RFC-9728-Metadaten für die genaue URL aus, unter /.well-known/oauth-protected-resource plus deinem Pfad und an der Wurzel, mit resource gleich der Adresse, die der Client benutzt hat.
• Mach diese URL zur Token-Audience und baue Alias-Unterstützung, bevor du umziehen musst.
• Leite jeden anderen Pfad auf dem MCP-Host mit einem 308 auf deine Website um und behalte dabei die Query-Zeichenkette.
• Halte Browser-Challenges und HTML-Caching vom MCP-Host fern.
• Veröffentliche überall denselben String (Anleitung, Installationslinks, Plug-in-Manifeste, Dokumentation) und teste, dass jede Kopie übereinstimmt.
• Zum Umziehen: erst Aliase, dann die neue Adresse und das Alias in einer Änderung, jede Kopie umgestellt, die Audience gewechselt und die alte Adresse abgeschaltet, wenn ihr Traffic aufhört.