MCP Server Cards: auditoría de la nueva capa de discovery

MCP por fin tiene una historia de discovery pre-conexión. Esta semana el texto de SEP-2127 — MCP Server Cards — fue marcado como Final en la rama de su pull request, y el diseño no se parece en nada al draft de enero. El juego de adivinar paths .well-known para las cards quedó fuera. Entra un AI Catalog agnóstico de protocolo.

El Model Context Protocol ha tenido un punto ciego extraño desde su lanzamiento: un cliente no puede aprender nada sobre un servidor remoto sin conectarse a él. Nombre, versión, transports soportados, headers requeridos — todo eso vive detrás de un handshake de inicialización completo. SEP-1649, abierto en octubre de 2025, planteó el problema con precisión: para obtener siquiera metadata básica, los clientes deben completar el handshake entero, lo que bloquea el crawling de registries, la indexación a nivel de dominio y la autoconfiguración en IDEs.

Su sucesor, SEP-2127, lleva en revisión desde el 21 de enero de 2026. El 8 de septiembre un lead del working group preguntó si estaba listo para merge, y el texto del SEP en la rama del PR ya dice Status: Final, Type: Extensions Track. Al momento de publicar esto, el PR sigue abierto — pero la forma del discovery de MCP está lo bastante asentada como para auditarla. Este post recorre el diseño final, qué cambió durante ocho meses de revisión, y qué resuelve y qué no para los agentes autónomos.

El hueco: no puedes preguntarle nada a un servidor hasta conectarte

MCP ya tiene dos respuestas parciales a "cómo encuentro un servidor". El MCP Registry resuelve la publicación: un índice centralizado con un schema server.json que cubre endpoints remotos y paquetes instalables localmente. Y el RPC server/discover, agregado al draft de la spec, resuelve la introspección en vivo — pero solo después de que ya sabes dónde conectarte y puedes alcanzar el endpoint.

Ninguna responde la pregunta a nivel de dominio: dado example.com, ¿qué servidores MCP opera, dónde viven y qué necesito para conectarme? Esa es la pregunta que hace un agente de compras antes de gastar dinero, la que hace un IDE cuando un usuario pega un dominio, y la que hace un crawler al construir un índice del ecosistema. Los Server Cards existen para responderla out-of-band: metadata pública, cacheable e indexable que no requiere ningún intercambio de protocolo.

El giro de diseño: de cards en well-known a catálogo primero

El draft de enero era lo esperable: servir una card en /.well-known/mcp-server-card, con una variante por servidor para orígenes que hospedan varios. Schema rico, reglas CORS, registro IANA del sufijo de URI. Convencional y autocontenido.

El diseño final tiró la mayor parte de eso. En el texto candidato a merge, un Server Card puede hospedarse en cualquier URI no reservada — MCP reserva solo una ubicación recomendada, GET <streamable-http-url>/server-card, adyacente al propio endpoint de transporte. El discovery a nivel de dominio se mueve a un documento separado y agnóstico de protocolo: el AI Catalog, publicado en /.well-known/ai-catalog.json, que enlaza o embebe las cards. Dos media types hacen explícitas las capas: application/ai-catalog+json para el catálogo, application/mcp-server-card+json para la card.

La razón es una realidad de hosting que el primer draft ignoraba. El ejemplo del propio SEP: un restaurante usa una plataforma SaaS para reservas vía MCP y otra para ofertas de empleo vía MCP. Ninguno de los dos servidores corre en el dominio del restaurante, y el restaurante no puede publicar archivos bajo el path .well-known de ningún vendor. Con el modelo de catálogo, restaurant-a.com anuncia ambas cards en su propio catálogo, y cada plataforma SaaS hospeda las cards de cada tenant que sirve. Cards en cualquier dominio, discovery anclado al dominio de identidad.

El working group también documentó lo que rechazó. Los registros DNS TXT — el enfoque que auditamos para el discovery de x402 — se descartaron porque solo funcionan a granularidad de dominio, no para servidores por path o por puerto. El discovery vía headers tipo Link se descartó porque requiere una petición HTTP al endpoint primero, lo que anula el propósito del discovery pre-conexión.

Qué contiene realmente un Server Card

La spec normativa ya no vive en el SEP. Siguiendo el precedente de MCP Apps, SEP-2127 es un documento fundacional; el wire format vive en el repositorio experimental-ext-server-card, donde un archivo TypeScript, schema.ts, es la fuente única de verdad y el JSON Schema se genera desde él. El identificador de la extensión es io.modelcontextprotocol/server-card.

Una card describe exactamente tres cosas: identidad, transporte y versiones de protocolo. Una card mínima pero realista:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/v1/server-card.schema.json",
  "name": "com.example/weather",
  "version": "1.4.0",
  "description": "Forecasts and historical weather data",
  "title": "Example Weather",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://example.com/mcp",
      "supportedProtocolVersions": ["2026-07-28"],
      "headers": [
        { "name": "X-API-Key", "isRequired": true, "isSecret": true }
      ]
    }
  ]
}

Los detalles del schema premian la lectura atenta. name es reverse-DNS con exactamente una barra separando namespace de nombre de servidor — la misma convención de identidad que el Registry. version debería ser semver y rechaza rangos explícitamente (^1.2.3, 1.x). $schema debe apuntar a la URL de schema /v1/; las revisiones breaking publican una nueva familia vN en lugar de schemas versionados por fecha. Las URLs de remotes soportan variables de plantilla en {llaves}, y tanto las variables de URL como los headers se describen como inputs tipados — con description, isRequired, isSecret, format, default y choices — de modo que un cliente puede pedirle al usuario una API key o una región sin UI de configuración específica del vendor.

Un campo pequeño concentra mucho pensamiento de seguridad: el opcional repository.id, el identificador estable del repo según el servicio de hosting. Como un repositorio borrado y recreado recibe un ID nuevo, los registries pueden usarlo para detectar ataques de resurrección de repositorio — alguien re-registrando un nombre abandonado para distribuir un servidor malicioso bajo una identidad establecida.

El flujo del catálogo

El discovery empieza en el dominio. Un cliente hace fetch de https://{dominio}/.well-known/ai-catalog.json, filtra las entradas por el media type de Server Card, y luego sigue la url de cada entrada o lee la card inline desde data:

{
  "specVersion": "1.0",
  "entries": [
    {
      "identifier": "urn:air:example.com:mcp:weather",
      "type": "application/mcp-server-card+json",
      "url": "https://example.com/mcp/server-card"
    }
  ]
}

Los identificadores del catálogo usan un formato URN anclado a dominio, urn:air:{publisher}:{namespace}:{name}. Las entradas deliberadamente no repiten los campos legibles de la card — title, description y version viven solo en la card, así los dos documentos no pueden divergir.

El AI Catalog en sí no es un artefacto de MCP. Es un contenedor tipado y anidable para metadata heterogénea de IA, desarrollado en un repositorio de trabajo mantenido actualmente bajo la Linux Foundation, con contribuidores de varias comunidades de protocolos. El plan declarado es que los steering committees de A2A y MCP voten la adopción como estándar compartido. Si eso ocurre, el mismo documento .well-known que anuncia los servidores MCP de un dominio anunciará sus Agent Cards de A2A — una sola raíz de discovery para toda la superficie agéntica de un dominio.

Qué dejan fuera las cards a propósito

La decisión de diseño más consecuente es negativa: los Server Cards no enumeran tools, resources ni prompts. El razonamiento es que los servidores MCP son dinámicos — los primitives que un servidor expone varían según el usuario autenticado, la sesión, la configuración y los feature flags. Un manifiesto estático no puede representar esa superficie con honestidad, y una card que lista tools invita a los clientes a tomar decisiones de confianza sobre datos obsoletos o falsificados. El listado en runtime vía tools/list con la identidad autenticada sigue siendo la única fuente de verdad. Las capabilities y el soporte de extensiones negociado se excluyen por la misma razón, y la spec es explícita en que _meta no puede usarse para colarlos.

Esta contención es la decisión correcta, y vale la pena notar cómo interactúa con la release de spec 2026-07-28. Esa release formalizó el framework de extensiones (SEP-2133) que hace posible distribuir los Server Cards como extensión opcional con versionado independiente — sin cambios al protocolo core, con compatibilidad total hacia atrás, y con maintainers que pueden iterar sin esperar al tren de releases de la spec.

Estado, gobernanza, implementaciones

El Server Card Working Group se constituyó el 26 de marzo de 2026, liderado por David Soria Parra (Anthropic) y Sam Morrow Drums (GitHub), con Tadas Antanavicius como miembro. Su charter traza límites limpios: el Registry WG es dueño de server.json y del problema de catálogo/registry; el formato de Server Card cubre solo conectividad remota y debe mantenerse compatible con la metadata del Registry donde los conceptos se solapan. La actualización del roadmap de MCP publicada el 22 de agosto de 2026 lista el trabajo del grupo sobre convenciones .well-known como una línea activa hacia la próxima release de la spec.

Ya existen implementaciones de referencia: una experimental en el SDK de Python que cubre construcción y servido de cards del lado servidor, fetch y validación del lado cliente, y modelos Pydantic; una implementación server-side en el SDK de Go; y una demostración de discovery e instalación guiada por cards en el cliente Goose. Eso es exactamente el criterio de éxito declarado por el working group — disponibilidad en SDKs más clientes y servidores reales con alcance — ensamblándose antes del merge y no después.

Notas de auditoría: dónde el diseño queda corto

Cuatro cosas destacan tras leer el schema, la spec de discovery y el hilo de revisión.

Qué significa para LLM4Agents

El discovery es la capa justo encima de los pagos en nuestro stack, y esta propuesta toca ambos lados de lo que operamos.

Como operador, exponemos tools MCP para el gateway — listado de modelos, consulta de balance, reporte de uso. Hoy un agente encuentra esos tools porque los documentamos. Bajo este diseño, publicar un Server Card en la ubicación reservada <endpoint>/server-card más un ai-catalog.json en la raíz de nuestro dominio hace esa misma superficie descubrible por máquinas: un IDE apuntado a nuestro dominio puede autoconfigurar la conexión MCP del gateway, headers y versiones de protocolo incluidos. Los inputs tipados de headers mapean limpio al aprovisionamiento de API keys. Es barato, aditivo e indexable por todo crawler de registries que adopte el flujo.

Como infraestructura para agentes que pagan, el cálculo es más filoso. Un agente que descubre un servicio pre-conexión y luego le paga por llamada vía x402 está tomando una decisión de gasto en parte sobre metadata de discovery — exactamente los datos que esta spec declara advisory y deja sin firmar. Aplica la misma lección que sacamos de la auditoría del discovery well-known de x402: las capas de discovery te dicen dónde mirar, y nunca deben poder decirte en quién confiar. Nuestra posición en medio del flujo de pago es el lugar natural para imponer esa separación — pinning de endpoints verificados para tools que mueven pagos, claims de la card contrastados contra el serverInfo en vivo antes de mover fondos.

Estratégicamente, el AI Catalog es la pieza a vigilar. Si MCP y A2A convergen en una sola raíz de discovery .well-known, el paisaje fragmentado — MCP Registry, cards de A2A, discovery de x402, directorios de vendors — gana un ancla compartida. Una plataforma que ya habla la capa de pagos y la de tools debería estar presente en ese documento desde el día uno.

Cómo mantenerse en la frontera

Pasos concretos, en orden:

1. Publicar ya. Servir un Server Card v1 en la ubicación reservada de nuestro endpoint MCP y un /.well-known/ai-catalog.json que lo referencie, validado contra el schema.json generado del repo de la extensión. El formato está Final en todo salvo el merge; publicar temprano no cuesta nada y nos indexa primero.
2. Implementar discovery verificado en el SDK para agentes. Fetch de la card, conexión, comparación de name/version/transporte contra los valores de runtime, y fallo duro del path de pago ante cualquier discrepancia. Convertir la regla advisory en regla exigida donde el dinero sigue al discovery.
3. Seguir el merge y el tren de SDKs Tier-1. Cuando las implementaciones de los SDKs de Python y Go lleguen a releases, reemplazar cualquier manejo artesanal de cards por los tipos oficiales.
4. Vigilar los votos de adopción del AI Catalog. Si los identificadores urn:air se vuelven la convención cross-protocolo, alinear nuestros identificadores de agentes y servicios con ese esquema anclado a dominio en lugar de inventar otro namespace.
5. Empujar por firmas. El hueco de metadata sin firmar es la entrada para la capa de identidad que ya seguimos — cards firmadas, o entradas de catálogo vinculadas a identidad onchain de agentes, cerrarían el agujero de phishing en discovery. Ese argumento va en el hilo del working group ahora, no después del primer incidente.