¿Dónde debe vivir un servidor MCP? Revisamos 33 direcciones

¿Qué URL usan los servidores MCP públicos?

Sobre todo un subdominio mcp. dedicado, normalmente con /mcp como ruta. Nos pusimos a mirar mientras elegíamos entre mcp.scorestarling.com/mcp y api.scorestarling.com/v1/mcp, la forma que usa ElevenLabs, porque queríamos saber qué hacen de verdad los demás servicios.

El 2 de octubre de 2026, entre las 17:40 y las 17:42 UTC, enviamos un POST sin autenticar a cada una de 33 direcciones de 27 servicios, con {} como cuerpo, una cabecera Accept: application/json, text/event-stream y un tiempo de espera de 8 segundos, y registramos solo el código de estado. Un 401 significa que algo en esa dirección respondió y quiere un token, que es como un servidor MCP protegido da pie al inicio de sesión. Un 404 significa que no se sirve nada en esa ruta. Algunas direcciones las publicaban los servicios; otras eran variantes y suposiciones que probamos para ver qué rutas responden. Es una instantánea de servicios conocidos, no un censo, y cualquiera de ellos puede haber cambiado desde entonces.

Los 404 encierran la lección práctica: una URL MCP no se puede deducir de un dominio. Stripe y Vercel responden en el host sin ruta y devuelven 404 en /mcp; Higgsfield es al revés; ElevenLabs necesita su /v1. Un cliente usa exactamente la URL que se le da, y la RFC 9728 hace de esa URL la identidad con la que deben coincidir los metadatos del servidor, así que la misma cadena tiene que aparecer en tu documentación, en los enlaces de instalación y en los manifiestos de los plugins. Los manifiestos muestran aún más variedad: entre los plugins que teníamos instalados había gitlab.com/api/v4/mcp, una ruta en el propio gitlab.com, y mcp.hubspot.com/anthropic. Esos dos no los sondeamos.

¿Debe el endpoint MCP compartir host con tu sitio web?

Creemos que no. El endpoint es para el software y la guía de conexión es para las personas, y los dos quieren la dirección obvia. Hasta el 2 de octubre de 2026, scorestarling.com/mcp era nuestro servidor MCP, así que la guía tenía que estar en otro sitio; y como el 401 de esa URL es la forma en que todos los clientes descubren el inicio de sesión, tampoco podía ser una página web.

Pensamos en servir las dos cosas en una misma URL, una página para los navegadores y MCP para los clientes, y lo descartamos como configuración permanente: una suposición equivocada sobre una petición rompe el descubrimiento del inicio de sesión de todos los clientes. La especificación del transporte también permite que los clientes envíen un GET al endpoint para abrir un flujo de eventos, y espera como respuesta ese flujo o un 405, no una página HTML.

Un host aparte también mantiene los cambios del sitio web lejos del endpoint: un rediseño no puede moverlo, y una caché de CDN o una verificación del navegador que convienen a un sitio de marketing nunca se interponen delante. Los asistentes llaman al servidor desde su propia infraestructura, no desde un navegador: la documentación de conectores de Anthropic dice que Claude se conecta desde la nube de Anthropic, y que un firewall delante del proveedor de identidad puede romper el inicio de sesión. Dos servicios similares que miramos lo separan igual (comprobado el 2 de octubre y de nuevo el 3 de octubre de 2026): la guía de Higgsfield está en higgsfield.ai/mcp y su servidor en mcp.higgsfield.ai/mcp; la guía de ElevenLabs está en elevenlabs.io/mcp y su servidor en api.elevenlabs.io/v1/mcp.

Nuestro host MCP sirve solo /mcp y /.well-known/*. Cualquier otra ruta recibe un 308 a la misma ruta y los mismos parámetros en el sitio web, de modo que el inicio de sesión, el consentimiento, las páginas, los enlaces de descarga y las cookies se quedan en un solo host. El /mcp del sitio web es ahora la guía de conexión para Claude, ChatGPT y otros clientes.

$ 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 host sin ruta o api.example.com/v1/mcp?

Cualquiera de ellas sirve; elige según qué más haya en el host. La especificación de autorización de MCP enumera https://mcp.example.com/mcp y https://mcp.example.com entre las URI canónicas de servidor válidas y pide la forma sin barra final salvo que la barra importe. La especificación del transporte solo exige una ruta de endpoint que acepte POST y GET, con https://example.com/mcp como ejemplo, y la documentación de conectores de Anthropic usa https://mcp.example.com/mcp.

Dos reglas menores. No acabes un endpoint de Streamable HTTP en /sse: la documentación de Anthropic dice que una URL que acaba así selecciona el transporte SSE antiguo en el formulario de conectores de Claude. Y deja fuera la barra final salvo que la quieras; de las 23 direcciones que respondieron 401, solo la de GitHub se escribía con ella.

¿Cómo se traslada un servidor MCP a una URL nueva?

Sirve las dos direcciones durante un tiempo y haz que cada una sea completa por sí sola: su propio 401, sus propios metadatos y tokens para cualquiera de las dos audiencias. Lo hicimos en cuatro pasos, todos en producción en menos de una hora la tarde del 2 de octubre de 2026 (UTC):

1. Publica el soporte de alias mientras nada lo usa. Un ajuste enumera las direcciones anteriores, cada una en HTTPS y terminada en /mcp. Un token se verifica si su audiencia es la dirección actual o un alias; cualquier otra audiencia se rechaza. Las listas de hosts permitidos (los hosts de confianza de Starlette y la protección contra DNS rebinding del SDK de MCP) incluyen todas las direcciones más el sitio web. Sin ningún alias configurado, producción se comportaba como antes.

2. Añade el host y después cambia la dirección y define el alias en un solo cambio. El subdominio nuevo recibió sus registros DNS, el certificado llegó unos seis minutos después y el host respondió 400 hasta que le dijimos a nuestro servidor que confiara en él. Un solo cambio de configuración fijó la URL de recurso nueva y enumeró la antigua como alias, así que un único redespliegue recogió ambas cosas. Hacerlo antes de que el paso 1 estuviera en producción habría hecho que el código en ejecución rechazara el propio host del sitio web.

3. Reapunta todo lo que la gente copia: la guía de conexión, incluidos los enlaces de instalación con un clic codificados para Claude, Cursor y VS Code, los manifiestos de los plugins y la documentación.

4. Cambia la audiencia del token y después retira la dirección antigua. Una migración hizo que nuestro hook de tokens de acceso emitiera la audiencia nueva, y CI la aplicó antes de que se publicara el código; mientras el alias seguía en pie, los tokens con cualquiera de las dos audiencias seguían funcionando. Después quitamos el alias y volvimos a desplegar. Durante los pocos minutos entre esa versión y el redespliegue, el /mcp del sitio web enviaba a los navegadores la guía y a los clientes MCP el servidor. Ahora sirve solo la guía, y la dirección antigua de la guía, /connect, responde con un 308 hacia ella.

Los metadatos son lo más fácil de pasar por alto. La RFC 9728 exige que su resource sea idéntico a la URL a la que se conectó el cliente, y la documentación de Anthropic exige que sea igual a la URL tal como se escribió en Claude. Así que durante el solapamiento cada host se describía a sí mismo, y cada 401 apuntaba al documento de su propio host:

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"

No redirigimos /mcp en sí. La especificación del transporte no describe redirecciones para el endpoint, y su URL forma parte del handshake de OAuth como recurso y como audiencia del token, así que servimos MCP en ambas direcciones. Para cualquier otra ruta, un 308 en lugar de un 301 mantiene el método, ya que la RFC 9110 no permite que un cliente convierta un POST en un GET tras un 308. Cómo llega la audiencia a nuestros tokens se explica en nuestras notas sobre OAuth en MCP.

Pudimos movernos tan rápido porque ScoreStarling aún era un piloto pequeño solo con invitación y nadie dependía todavía de la dirección antigua. Una vez eliminado el alias, un cliente que siga configurado con scorestarling.com/mcp tiene que reconectarse. Nuestro runbook prevé que un cliente que ya esté en la dirección nueva pero conserve un token con la audiencia antigua reciba un 401 invalid_token, se actualice y reciba la audiencia nueva; no hemos visto que un cliente real de Claude o ChatGPT lo haga. Con usuarios reales, conserva el alias hasta que cese el tráfico a la dirección antigua.

¿Qué falló durante la migración?

Tres cosas pequeñas salieron mal por el camino:

• Un script de comprobación construía la URL de metadatos con resource.replace('/mcp', '/.well-known/oauth-protected-resource/mcp'). Con la dirección antigua funcionaba. Con https://mcp.scorestarling.com/mcp, /mcp también coincide dentro de //mcp., y el resultado fue https://.well-known/oauth-protected-resource/mcp.scorestarling.com/.well-known/oauth-protected-resource/mcp. Construye la URL a partir de sus partes ya analizadas: esquema y host, luego el segmento well-known y luego la ruta.
• La dirección más larga desbordaba nuestra guía en una pantalla de 320 píxeles de ancho hasta que permitimos que el código en línea se partiera en varias líneas.
• Borrar la variable del alias con la herramienta de línea de comandos de Railway solo dejó el cambio preparado (staged); la dirección antigua siguió aceptándose hasta que volvimos a desplegar a mano.

Una lista de comprobación para elegir la dirección de un servidor MCP

• Dale al endpoint un host que no sirva nada para las personas; mcp. más tu dominio es la opción más común de nuestra muestra.
• Elige una ruta una sola vez. /mcp es la más común y un host sin ruta también es válido; evita la barra final y una ruta que acabe en /sse.
• Mantén la guía de conexión para las personas en tu sitio principal, en una dirección que puedan adivinar, y enlázala desde tu navegación.
• Sirve los metadatos de la RFC 9728 para la URL exacta, en /.well-known/oauth-protected-resource más tu ruta y en la raíz, con resource igual a la dirección que usó el cliente.
• Haz de esa URL la audiencia del token, y prepara el soporte de alias antes de necesitar la migración.
• Redirige con un 308 cualquier otra ruta del host MCP a tu sitio web, conservando los parámetros.
• Mantén las verificaciones del navegador y la caché de HTML lejos del host MCP.
• Publica una sola cadena en todas partes (guía, enlaces de instalación, manifiestos de plugins, documentación) y comprueba que todas las copias coinciden.
• Para migrar: primero los alias, luego la dirección nueva y el alias en un solo cambio, todas las copias reapuntadas, la audiencia cambiada y la dirección antigua retirada cuando cese su tráfico.