Descubrir un servidor MCP sin conectarse: Server Cards y AI Catalog

Una Server Card de MCP es un documento JSON que describe un servidor MCP remoto (qué es y qué ofrece) para que un cliente lo pueda conocer sin conectarse a él. La propuesta que la define, SEP-2127, se fusionó el 6 de octubre de 2026 con estado Final, como extensión. Su cambio de diseño más importante es el sitio donde vive la card. Ya no tiene una URL propia de MCP: queda detrás de un catálogo genérico, el AI Catalog, en /.well-known/ai-catalog.json.

Este artículo cuenta qué está decidido, qué falta y quién lo despliega ya. Lo publicamos el 3 de octubre, cuando la propuesta aún estaba en revisión, y lo actualizamos tras el merge. Lo que hay hoy es una extensión recién aprobada, con dos despliegues reales que se le adelantaron. Si mantienes un servidor remoto, no tienes que hacer nada todavía, pero conviene saber hacia dónde va.

El problema: saber qué ofrece un servidor antes de conectarse

En la especificación vigente, la 2026-07-28, un cliente ya puede preguntar a un servidor qué es y qué soporta. Para eso está server/discover, que es obligatorio en el servidor. Devuelve las versiones soportadas, las capacidades y la identidad del servidor, y su respuesta se puede cachear con ttlMs y cacheScope (especificación de server/discover). El curso lo explica en la lección sobre cómo viaja una petición (temario).

Pero server/discover es una petición MCP. Para hacerla necesitas conocer ya la URL del endpoint y hablar el protocolo con él. Así que no resuelve una pregunta anterior: dado un dominio, saber si tiene un servidor MCP, dónde está y si merece la pena conectarse. Un catálogo, un gateway que agrega servidores o un rastreador quieren saberlo con una petición HTTP normal, sin abrir una conexión MCP con cada candidato.

Para eso existe la Server Card. El Server Card Working Group tiene como misión definir qué es una Server Card, su formato y cómo se descubre. El blog del roadmap del 22 de agosto lo resume así: “The Server Card Working Group continues to work through the .well-known metadata conventions for MCP servers, so a server can be discovered and reasoned over without connecting to it” (The New MCP Roadmap).

Las Server Cards no forman parte de la especificación 2026-07-28. Los únicos .well-known normativos de esa versión son los de OAuth (/.well-known/oauth-protected-resource, /.well-known/oauth-authorization-server y /.well-known/openid-configuration).

SEP-2127 y su estado

Una SEP es una propuesta formal de cambio en MCP. Esta se trabaja como un pull request en el repositorio del protocolo. SEP-2127, “MCP Server Cards – HTTP Server Discovery”, lleva las etiquetas in-review, extension y roadmap/transport. La etiqueta in-review sigue puesta, pero el PR se fusionó el 6 de octubre de 2026. El documento de la SEP dice «Status: Final», es de tipo Extensions Track y su identificador es io.modelcontextprotocol/server-card. Es decir: es una extensión, no un cambio del núcleo, y su etiqueta la sitúa en el área de transporte del roadmap de MCP.

Lo que ha pasado en el PR entre agosto y octubre:

• 8 de septiembre. Un mantenedor de GitHub, SamMorrowDrums, preguntó a los core maintainers si estaba lista para el merge. No hubo merge entonces.
• 10 de septiembre. Un comentario público documenta que GitHub y Buildkite ya sirven /.well-known/ai-catalog.json apuntando a sus Server Cards.
• 12 de septiembre. Se preguntó quién registrará la URI .well-known. La respuesta fue que debe encargarse el grupo de AI Catalog.
• 24 de septiembre. SamMorrowDrums reiteró el diseño: “the MCP Server card is expliclty not at a generic well known URI, and requires an AI Catalog to point to it.” (La errata es del original.)
• 28 de septiembre. Un bot pidió actividad al sponsor de la SEP (@dsp-ant).
• 6 de octubre. dsp-ant fusionó el PR, y la SEP quedó con estado Final.

El 3 de octubre, cuando publicamos este artículo, SEP-2127 seguía en revisión y sin merge. Tres días después, el 6 de octubre, se fusionó con estado Final. Aun así, las Server Cards siguen fuera del núcleo.

En paralelo, el grupo de trabajo publicó el 12 de agosto sus prioridades de roadmap en el repositorio de la extensión (PR #47). El 25 de septiembre se abrió SEP-3392 (Extension Lifecycle), que propone fases de madurez para las extensiones: Experimental, Beta y Stable o la promoción al núcleo. Según su clasificación propuesta, ext-server-card entraría en Beta cuando se aceptara SEP-2127. SEP-3392 sigue siendo un borrador, así que esa fase no está fijada.

El giro hacia /.well-known/ai-catalog.json

Hasta este verano, la pregunta abierta era el mecanismo de descubrimiento. El charter del grupo citaba “well-known URL, resource-based discovery, etc.” sin elegir ninguno. El 20 de julio, el grupo de trabajo decidió que la Server Card no tendría una URI .well-known propia de MCP (PR #42 del repositorio experimental). En su lugar, se descubre a través de un AI Catalog en /.well-known/ai-catalog.json, que apunta a documentos de tipo application/mcp-server-card+json.

El AI Catalog no es de MCP. Es una especificación en borrador del Agent Card Working Group, bajo gobernanza de la Linux Foundation. MCP pasa a ser uno de los tipos de documento a los que un catálogo puede apuntar.

sequenceDiagram
  participant C as Cliente
  participant G as github.com
  participant S as api.githubcopilot.com
  participant M as Servidor MCP
  C->>G: GET /.well-known/ai-catalog.json
  G-->>C: AI Catalog con enlace a la Server Card
  C->>S: GET /mcp/server-card
  S-->>C: Server Card (esquema v1)
  Note over C: decide si le interesa el servidor
  C->>M: primera petición MCP
  Note over C,M: aquí empieza MCP propiamente dicho

La figura muestra la separación de capas. Las dos primeras peticiones son HTTP corriente: no hay JSON-RPC, ni _meta, ni versión de protocolo. MCP solo empieza cuando el cliente ya ha decidido conectarse.

Por qué importa el cambio:

• Un dominio, un punto de entrada. Si el patrón se generaliza, un proveedor que ofrezca un servidor MCP y otros recursos para agentes podrá publicar un único catálogo en vez de una URL .well-known por protocolo.
• La card puede vivir en otro host. El catálogo apunta a la card, así que no hace falta que esté en el mismo dominio. GitHub publica el catálogo en github.com y la card en api.githubcopilot.com.
• Hay una dependencia nueva. El descubrimiento de MCP depende ahora del ritmo de otra especificación en borrador y de otro grupo. Según la respuesta dada en el PR, es ese grupo quien debe registrar la URI ante la IANA.

Despliegues reales: GitHub y Buildkite

Dos empresas no esperaron al merge. El comentario del 10 de septiembre en SEP-2127 lo documentó, y lo comprobamos nosotros haciendo la petición el 3 de octubre de 2026. Es una medición propia de ese día, no una declaración de las empresas:

No reproducimos aquí el contenido de las cards. Solo anotamos a dónde apunta cada catálogo y, en el caso de GitHub, el esquema que declara. Si quieres ver los campos, haz tú mismo la petición. Son endpoints públicos, y es la mejor forma de ver en qué estado está hoy el formato.

Dos detalles de la medición. El primero, que el esquema de GitHub cuelga de static.modelcontextprotocol.io con un v1 en la ruta, aunque la SEP que lo define aún no se había aceptado ese día. El segundo, que ambos despliegues siguen el diseño del AI Catalog y no una URI propia de MCP, así que ya reflejan el giro de julio.

Lo que falta

Con dos despliegues reales y la SEP aprobada, es fácil pensar que esto está hecho. Todavía no lo está:

1. El repositorio definitivo. SEP-2127 ya es Final, pero la especificación detallada sigue en el repositorio experimental-ext-server-card. La SEP prevé que pase a un repositorio ext-server-card tras la aceptación.
2. El registro de la URI en la IANA. La URI .well-known está pendiente de registro, y según la discusión del PR le corresponde al grupo de AI Catalog, no al de MCP.
3. La propia especificación de AI Catalog, que también es un borrador.
4. La fase de la extensión. SEP-3392 propone que ext-server-card entre en Beta al aceptarse SEP-2127, pero SEP-3392 sigue en borrador.

Hay un quinto punto que la investigación no resuelve: qué clientes consumen hoy las Server Cards. Los despliegues están documentados en el lado del servidor; del lado del cliente no hemos encontrado una fuente primaria que diga quién las lee.

Relación con el MCP Registry

El descubrimiento con Server Cards y el MCP Registry resuelven problemas cercanos pero distintos.

El Registry es un índice central, el repositorio oficial de metadatos de servidores MCP públicos. Usa el formato server.json, nombres en DNS inverso (io.github.usuario/servidor) y verificación de namespace. No aloja código: apunta a paquetes o a URLs de servidores remotos. Está pensado para agregadores y marketplaces más que para que los hosts lo consulten directamente.

Su estado a 3 de octubre, según su repositorio:

• Sigue en preview. El README mantiene los avisos de la preview (septiembre de 2025) y de la congelación de la API v0.1 (octubre de 2025). No hubo anuncio de disponibilidad general en el periodo.
• Cambios del periodo. El 6 de agosto pasó a producción la v1.8.1, con caché de lecturas masivas y la corrección de una toma de namespaces. Hasta entonces, un miembro con permiso de escritura en el repositorio <org>.github.io podía publicar bajo io.github.<org>/* (PR #1506). El 22 de septiembre se enlazó el proyecto comunitario “mcpscore” para valorar la calidad de los servidores (PR #1661).
• Número de servidores. No hay cifra oficial publicada. Las que circulan son de terceros y no las damos por buenas.

La Server Card va por el camino contrario: la publica cada proveedor en su propio dominio. Un catálogo construido sobre el Registry sabe qué servidores existen porque alguien los publicó allí; uno construido sobre AI Catalog lo averigua preguntando a cada dominio. El charter del grupo de trabajo pide que el formato de la card se parezca lo más posible a un subconjunto de server.json, de modo que los dos mundos se puedan traducir entre sí.

Las dos vías comparten un riesgo. Un documento de metadatos, sea un server.json o una card, es un punto de confianza. El fallo de namespaces que corrigió el Registry en agosto recuerda que esa capa también es cadena de suministro. Lo tratamos con más detalle en seguridad en servidores MCP.

Qué hacer hoy si mantienes un servidor remoto

• No inventes una URL propia. El diseño actual descarta una URI .well-known específica de MCP. Si publicas algo, que sea un AI Catalog que apunte a la card, como hacen GitHub y Buildkite.
• Trátalo como una extensión nueva. Si quieres adelantarte, sigue el repositorio experimental y el PR de SEP-2127. La SEP ya es Final, pero la extensión aún no tiene una fase de madurez fijada.
• Implementa bien server/discover. Ya es obligatorio en el servidor, y un cliente puede consultarlo una vez conectado (para el cliente es opcional). Una card describe el servidor desde fuera, y server/discover lo describe desde dentro.
• No publiques en la card nada que no publicarías en una página web. Es un documento público pensado para que lo lea cualquiera.

El curso trata el descubrimiento y la agregación de servidores en el nivel Experto (arquitecturas distribuidas, gateways) y el despliegue de un servidor remoto en el nivel Avanzado: ver el temario. Para el contexto general de hacia dónde va el protocolo, sigue con el roadmap de MCP.