MCP Registry: cómo publicar y descubrir servidores MCP sin confiar a ciegas

El MCP Registry mejora el descubrimiento de servidores, no certifica que sean seguros. Aprende a publicar metadata reproducible y a construir una allowlist interna que trate cada servidor como una dependencia con privilegios.

Un MCP Registry es un catálogo con una API estándar para describir y descubrir servidores MCP. El registro oficial publica metadata —nombre, versión, repositorio, paquete o endpoint remoto—; no hospeda tu binario ni convierte un servidor listado en seguro o adecuado para tu empresa.

Eso separa tres cosas que se confunden con facilidad: descubrimiento (encontrar una ficha), procedencia (saber quién puede publicar un namespace) y confianza operativa (decidir si esta versión recibe permisos en tu entorno). El registro ayuda mucho con las dos primeras; la tercera es una política tuya.

Namespace y procedencia: quién puede afirmar ese nombre

El registro oficial asocia la publicación a un namespace. Para `io.github.*` usa identidad de GitHub; para dominios propios puede verificar DNS o HTTP. Esa verificación evita que cualquiera publique bajo `com.tuempresa.*`, pero no demuestra que todo el código de un repositorio o paquete sea seguro.

Versionado inmutable: publica un release, no una corrección silenciosa

Cada publicación de un servidor necesita una versión única. Una vez publicada, la metadata de esa versión es inmutable; si debes corregir descripción, repositorio, paquete o endpoint, publica otra versión. El registro intenta ordenar SemVer y marca la versión apropiada como `latest`, por lo que usar `1.4.0` de forma consistente simplifica a clientes y humanos.

No uses `latest` como versión de paquete en una allowlist. Fija la versión del artefacto y conserva su integridad en un lockfile, digest OCI o checksum cuando aplique. `latest` del registry es una conveniencia de discovery, no una orden para actualizar procesos de desarrollo sin revisar qué cambió.

Cuando solo ajustes metadata, una prerelease de registry puede ser preferible a fingir que el binario cambió. Pero no ocultes una modificación real de tools o permisos detrás de un parche menor: para el consumidor, añadir `delete_repository` es un cambio de riesgo aunque tu API siga siendo compatible.

Guarda la versión y la respuesta original que revisaste. Si el upstream se actualiza, compara el nombre del paquete, transporte, comando, URL, variables, tools observadas y permisos. Un cambio en cualquiera de ellos requiere reevaluación; no basta con que `version=latest` avance.

Sub-registro privado: la capa que una empresa realmente necesita

El registro oficial es para servidores públicamente accesibles; para un servicio interno o una dependencia aprobada solo para tu organización, crea un sub-registro privado o un catálogo compatible. GitHub documenta que una implementación v0.1 necesita endpoints de listado y detalle, además de CORS si un cliente lo consume desde navegador o IDE.

El sub-registro no tiene que duplicar toda la funcionalidad del público. Empieza con una allowlist inmutable y explícita: ID interno, server name upstream, versión exacta, fuente, owner, clasificación de datos, scopes permitidos, transporte, fecha de revisión y fecha de caducidad. Si falta owner o fecha, el ítem caduca en vez de quedarse como excepción eterna.

Puedes sincronizar fichas públicas como candidatos, pero no copies automáticamente todas. La ganancia real es cambiar la experiencia por defecto: el developer descubre únicamente servidores aprobados, y el host impide conexiones fuera de política cuando la plataforma lo permita.

Observabilidad y renovación de confianza

Registra server name, versión, digest o lockfile, host, usuario o service account, tool, argumentos redactados, resultado, latencia y decisión de aprobación. Sin esa relación no podrás responder qué servidor consultó un dato o cambió un recurso cuando una alerta llegue semanas después.

Checklist de publicación y consumo

• El nombre MCP pertenece a un namespace que controlas y la identidad de CI puede probarlo.
• Paquete o endpoint existen antes que la ficha y su versión coincide exactamente con `server.json`.
• El schema se valida en CI y el proceso se arranca en una prueba de integración sin secretos reales.
• Cada publicación usa una versión única; una corrección se publica como release nuevo, no se reescribe.
• La ficha no incluye secretos ni se confunde con el archivo de configuración runtime del host.
• El registro público entra en el flujo como fuente de discovery, nunca como allowlist automática.
• La allowlist interna fija versión, fuente, owner, datos, scopes, transporte, fecha de revisión y expiración.
• Los paquetes locales se fijan, escanean y ejecutan con sandbox, red, filesystem y credenciales mínimos.
• Las definiciones de tools se inspeccionan y se vuelven a aprobar si cambian.
• Las acciones sensibles muestran parámetros completos y requieren consentimiento o aprobación humana.