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.

TL;DR

La keyword principal es MCP Registry. La intención es técnica y práctica: un maintainer quiere publicar un servidor reproducible, y un equipo quiere descubrirlo sin transformar una búsqueda de herramientas en una puerta de entrada a paquetes y credenciales no revisados.

Mi postura: usa el registro público como inventario y canal de distribución de metadata, no como una lista de confianza. La unidad de confianza sigue siendo una versión concreta de un artefacto, su código, sus tools, su identidad de ejecución y los permisos que le concedes.

Qué es MCP Registry y qué problema resuelve

MCP Registry es la especificación y el ecosistema de registros para servidores Model Context Protocol. El Official MCP Registry, en registry.modelcontextprotocol.io, es un catálogo público de metadata y una API REST sobre la que pueden construirse marketplaces o sub-registros. Su valor es que un cliente no tenga que adivinar cómo encontrar, instalar o actualizar cada integración.

La frase importante es metadata. Un server.json puede apuntar a un paquete npm, PyPI, una imagen OCI o un endpoint remoto, junto a los transportes y la configuración de arranque. El registro no ejecuta ese servidor por ti ni inspecciona exhaustivamente lo que hará cuando tenga acceso a tu filesystem, red, OAuth o secretos.

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.

Un registro público resuelve discovery; la allowlist y los controles de ejecución resuelven el riesgo de introducir una nueva dependencia con capacidades de agente.

El modelo mental correcto: catálogo, no sello de seguridad

Que un servidor aparezca en un registro oficial no significa que sus dependencias sean benignas, que el maintainer siga controlando el paquete, que sus tool descriptions no hayan cambiado o que encaje con tus datos. La propia documentación lo presenta como un repositorio de información autodeclarada y, mientras siga en preview, avisa de posibles cambios incompatibles o resets de datos.

Trátalo como tratarías npm: una ficha reduce fricción de discovery y aporta campos comparables; no sustituye revisión de código, lockfile, análisis de dependencias, firma, sandbox o permisos mínimos. En MCP el impacto puede ser mayor que en una librería de UI porque el proceso puede recibir secretos y ejecutar operaciones en nombre de un usuario.

Una política sana empieza con esta pregunta: ¿qué puede leer, escribir, ejecutar o enviar este servidor después de instalarse? Si no puedes responderla para una versión fijada, no está listo para la allowlist, aunque tenga un nombre bonito, muchos installs o una referencia en un marketplace.

server.json: el contrato que publicas

server.json es la ficha versionada del servidor. Como mínimo declara un nombre único, descripción, versión, repositorio y una o más formas de distribución: packages para artefactos instalables o remotes para endpoints. Para un paquete también declara su registryType, identificador, versión y transporte; para un remoto, URL y transporte compatible.

No copies un ejemplo antiguo sin comprobar el schema que genera tu versión de mcp-publisher. El formato evoluciona durante preview. La forma menos frágil de empezar es mcp-publisher init, revisar el JSON resultante y validarlo en CI contra el schema actual antes de publicar. El contrato de registry no es el archivo de configuración con secretos que ejecuta el host.

Un ejemplo deliberadamente mínimo para un paquete npm por STDIO sería este. Sustituye los nombres, controla la versión desde tu release y no incluyas valores de secretos: la ficha solo puede describir variables requeridas, no contenerlas.

server.json

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.acme/release-notes",
  "description": "MCP server for approved release-note data.",
  "version": "1.4.0",
  "repository": {"url": "https://github.com/acme/release-notes-mcp", "source": "github"},
  "packages": [{
    "registryType": "npm",
    "identifier": "@acme/release-notes-mcp",
    "version": "1.4.0",
    "transport": {"type": "stdio"}
  }]
}

Mantén la descripción factual y breve. También es entrada para hosts y modelos: una descripción ambigua, promocional o con instrucciones operativas largas aumenta el riesgo de que un agente elija una capability que no debería tener.

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.

Lo que conviene comprobar

Elige un namespace que sobreviva a cambios de equipo. Si tu servidor es producto de una organización, un namespace de dominio verificado suele expresar mejor la propiedad que una cuenta personal. Documenta qué repositorio, pipeline y equipo pueden publicar y elimina permisos cuando alguien deja el proyecto.

En CI, separa el token que publica el artefacto del mecanismo que publica la metadata. El quickstart del registro ofrece autenticación GitHub/OIDC; úsala para que el pipeline pueda probar origen sin guardar una sesión humana de larga duración. Protege la rama y exige revisión del cambio de server.json, igual que harías con un workflow de release.

¿Te está sirviendo? Hay una dosis cada semana

Te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis

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.

Publicar paso a paso desde CI

El orden seguro es: compilar, probar y publicar el artefacto; verificar que es recuperable por su identificador y versión; generar o actualizar server.json; validar schema y coherencia; autenticar el publisher con identidad de CI; publicar la metadata; y consultar la API para confirmar que la versión concreta aparece. Si publicas la ficha antes que el paquete, invitas a instalaciones rotas.

Para npm, el registro pide que el paquete se vincule a su nombre MCP mediante mcpName. Esa comprobación reduce la distancia entre metadata y paquete. Añade además tests que arranquen el paquete exactamente como lo describe el server.json: comando, transporte, variables declaradas y un initialize de prueba sin tocar datos reales.

Un esqueleto de workflow puede ser tan simple como el siguiente. No es una receta para copiar secretos: el token OIDC y los permisos exactos dependen de tu proveedor y del namespace. La parte importante es que publicación sea una consecuencia de artefacto probado, no un comando manual desde un portátil.

release.sh (esquema)

npm ci
npm run build && npm test
npm publish --access public

node scripts/assert-server-json.mjs server.json
mcp-publisher login github-oidc
mcp-publisher publish server.json

curl --fail --silent   "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.acme/release-notes"

Haz que assert-server-json compare name, versión, repositorio y paquete contra package.json y la etiqueta Git. Es una comprobación pequeña que evita el fallo más tonto del ecosistema: publicar metadata de 1.4.0 que instala sin querer 1.3.2.

Consumir la API sin mezclar discovery y ejecución

La API v0.1 expone una lista de servidores y el detalle de una versión. Permite filtrar por search, pedir solo latest o sincronizar incrementalmente con updated_since. Esto es suficiente para construir una vista de catálogo o un job que detecte cambios; no lo conviertas en un instalador automático para cada resultado nuevo.

El patrón adecuado es ingestión → normalización → evaluación de política → aprobación → distribución. Tu job puede traer nuevas fichas a una base interna y marcar qué cambió, pero un servidor no pasa a ser ejecutable por un developer hasta que una persona o una regla verificable aprueba su versión, identidad, permisos y distribución.

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.

Supply chain MCP: controles antes de dar una tool al modelo

Antes de instalar un paquete local, verifica el publisher, repositorio y artefacto; fija versión y lockfile; analiza dependencias; ejecuta el proceso con filesystem, red y variables mínimas; y revisa el comando que el host va a lanzar completo. La recomendación de OWASP es clara: un servidor MCP local puede convertirse en una vía de sandbox escape, exfiltración o ejecución arbitraria si recibe acceso total por comodidad.

Después de instalar, inspecciona también las tools: nombre, descripción, argumentos, outputs y destino. Las descripciones y schemas son superficie de prompt injection. Conserva un hash de la definición de tools que aprobaste y alerta si cambia; un servidor que hoy solo lee puede sufrir un rug pull mañana sin que cambie el nombre del paquete.

Para servidores remotos, añade otra capa: validación TLS, URL exacta, OAuth con audiencia y scopes estrechos, egress controlado y rate limits. Una ficha de registry puede hacer visible un endpoint; no concede a ese endpoint derecho a recibir tokens de tu usuario. Para el flujo OAuth completo, consulta nuestra guía de OAuth 2.1 para MCP.

De la ficha al host: consentimiento y aislamiento

El host debe enseñar qué se instala o conecta, qué comando se ejecutará en local, qué variables necesita y qué acciones expone. La aprobación del usuario no puede ser una tarjeta truncada con un botón «Conectar». Si el host no revela el comando completo, los permisos o la procedencia, el equipo pierde la evidencia necesaria para aprobarlo.

Aísla servidores como dominios de seguridad independientes. Un servidor de documentación no necesita el token de un servidor de deploy ni acceso a todos los archivos del repositorio. Da una credencial por servidor y entorno, monta solo los directorios imprescindibles y bloquea red saliente salvo destinos que puedas justificar.

Las mutaciones de impacto —escribir código, emitir una orden, cambiar un permiso, enviar datos fuera— deben seguir requiriendo aprobación con parámetros completos. Un registro resuelve cómo encontrar una tool; no decide cuándo un agente puede ejecutar una acción con consecuencias.

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.

Lo que conviene comprobar

Configura dos bucles de revisión. El primero es de cambios: nueva versión, nuevo paquete, endpoint, comando, tool o scope reabre la evaluación. El segundo es temporal: cada entrada aprobada expira en 90 o 180 días y necesita un owner que confirme que sigue mantenida y con el mismo riesgo aceptable.

Mide también fricción útil: solicitudes de alta, tiempo hasta revisión, instalaciones rechazadas, permisos denegados, tools poco usadas y cambios detectados. Si tu catálogo tarda semanas para un servidor de lectura de bajo riesgo, acabará apareciendo un bypass; si aprueba todo en cinco minutos, solo has creado una lista decorativa.

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.

Conclusión

MCP Registry es una pieza necesaria para que el ecosistema deje de repartir fragmentos de configuración por README y capturas. Estandariza discovery y metadata, y permite que clientes y empresas hablen el mismo idioma de catálogo. Eso es valioso, pero no es una auditoría de seguridad.

Publica como maintainer con releases reproducibles, versiones inmutables y CI; consume como equipo con una allowlist, artefactos fijados, sandbox y reevaluación por cambios. Si conviertes un registry en «instalar lo que aparezca», acabas de automatizar la parte peligrosa de tu supply chain. Si lo usas para hacer explícitas procedencia y políticas, reduces fricción sin regalar privilegios.

Preguntas frecuentes

¿Qué es MCP Registry?

Es un estándar y catálogo de metadata para descubrir servidores Model Context Protocol. El Official MCP Registry ofrece una API pública para que clientes y sub-registros consulten fichas de servidores.

¿El MCP Registry oficial certifica que un servidor sea seguro?

No. Ayuda a descubrir metadata y comprobar propiedad de namespaces, pero no sustituye revisión de código, integridad del artefacto, permisos mínimos, sandbox ni controles de ejecución.

¿Qué contiene server.json?

Describe el nombre, versión, repositorio y cómo obtener o conectar el servidor, por ejemplo un paquete con transporte STDIO o un endpoint remoto. No debe almacenar secretos runtime.

¿Puedo cambiar un servidor ya publicado?

No se reescribe esa versión. Publica una versión nueva de server.json; las versiones publicadas son inmutables y deben ser únicas.

¿Necesito un registro privado para mi empresa?

Si quieres publicar servicios internos o aplicar una allowlist de servidores aprobados, sí. Puedes usar una implementación compatible v0.1 o un catálogo interno que fije versiones, owners, permisos y caducidad.

¿Debo instalar automáticamente los resultados del registry?

No. Úsalo para discovery y somete cada versión a política: publisher, paquete o endpoint, dependencias, tools, scopes, sandbox y aprobación antes de habilitarla.

Cómo publicar y gobernar un servidor con MCP Registry

1. Definir el límite. Enumera tools, datos, efectos y permisos; elimina capacidades que no pertenecen al primer release.
2. Publicar el artefacto. Compila, prueba y publica el paquete o endpoint antes de crear la ficha de registry.
3. Vincular la procedencia. Elige namespace, configura verificación GitHub, DNS o HTTP y limita quién puede publicar desde CI.
4. Generar server.json. Usa mcp-publisher init, declara versión exacta, repositorio y transporte sin incluir secretos runtime.
5. Validar en CI. Comprueba schema, coherencia con package metadata y un arranque real que complete initialize en sandbox.
6. Publicar una versión. Autentica el publisher con identidad de CI y registra la versión única; no reescribas releases publicados.
7. Verificar discovery. Consulta el detalle de esa versión en la API y guarda la respuesta revisada como evidencia de release.
8. Crear allowlist. Fija versión, fuente, owner, clasificación de datos, scopes, transporte, revisión y fecha de expiración.
9. Aislar ejecución. Usa credenciales por servidor, filesystem y red mínimos, y aprobación humana para acciones sensibles.
10. Reevaluar cambios. Altera paquete, endpoint, tool, schema o scope y obliga una revisión antes de avanzar a la nueva versión.

Fuentes y referencias

• MCP Registry: about
• MCP Registry: quickstart para publicar un servidor
• MCP Registry: versionado de servidores publicados
• MCP Registry: FAQ
• Official MCP Registry API
• Model Context Protocol: Security Best Practices
• GitHub Docs: configurar un MCP registry empresarial
• OWASP MCP Security Cheat Sheet

También te puede interesar

• MCP en producción: seguridad, permisos y supply chain
• OAuth 2.1 para servidores MCP
• MCP Apps: UI interactiva para tools MCP
• Prompt injection en agentes de IA
• Docker MCP Toolkit: agentes locales y seguridad

Recibe una lectura semanal de herramientas IA para devs

Cada semana te resumo herramientas de IA para devs, agentes, MCP, seguridad y workflows en un email de 5 minutos. En español y sin ruido.

Suscribirme gratis