MCP Registry: qué es, en qué estado está y cómo publicar tu servidor

El MCP Registry es el registro oficial de metadatos de servidores MCP públicos: un índice con una API REST que dice dónde está cada servidor (un paquete de npm, PyPI o crates.io, una imagen OCI o una URL remota) y cómo se instala, sin alojar su código. Vive en https://registry.modelcontextprotocol.io, lo mantiene un grupo de trabajo del proyecto MCP y, a 8 de octubre de 2026, sigue en preview.

Hemos reescrito este artículo por completo, porque la versión de 2025 describía un producto que no existe (al final te contamos qué corregimos). Todo lo que sigue sale de la documentación oficial, del repositorio del Registry y de peticiones que hicimos a la API el 8 de octubre de 2026.

¿Qué es el MCP Registry y qué no es?

La documentación lo define como «the official centralized metadata repository for publicly accessible MCP servers». La palabra importante es metadata. npm, PyPI o Docker Hub guardan código y binarios. El Registry guarda una ficha que apunta a ellos. Su propio documento de visión lo llama un metaregistry.

Cada ficha es un server.json con el nombre, la versión, la descripción y la forma de conectarse al servidor. El Registry admite servidores de código abierto y de código cerrado, siempre que el método de instalación sea público o que el servidor remoto sea accesible.

Hay tres cosas que el Registry no hace:

• No admite servidores privados. Para ellos, la documentación recomienda montar un registro privado propio.
• No está pensado para que lo lean los hosts directamente. Lo dice así: «The MCP Registry is not intended to be directly consumed by host applications». Los hosts deberían leer de otros registros, como los marketplaces, que a su vez se alimentan del oficial.
• Su código no está pensado para autoalojarse. Los mantenedores no dan soporte a ese uso.

Tampoco forma parte de la especificación del protocolo, como explicamos en la lección 14 del curso.

Según los términos de servicio, los metadatos que publicas pasan a dominio público con la licencia CC0 1.0.

¿Quién mantiene el MCP Registry?

Lo mantiene el Registry Working Group del proyecto MCP. Su líder es Radoslav Dimitrov, de Stacklok. Tadas Antanavicius, de PulseMCP, dejó de figurar como líder con el PR #1493 («docs: remove Tadas as WG Lead») y sigue como miembro y mantenedor. Según su charter, el grupo es dueño del servicio, del esquema server.json, de la especificación de la API y del ecosistema de subregistros.

El proyecto empezó en febrero de 2025, cuando los creadores de MCP, David Soria Parra y Justin Spahr-Summers, pidieron ayuda a los equipos de PulseMCP y Goose para construir un registro comunitario.

La documentación dice que lo respaldan Anthropic, GitHub, PulseMCP y Microsoft. Anthropic es uno de ellos, no el dueño del Registry ni quien lo lanzó por su cuenta.

¿En qué estado está el MCP Registry en 2026?

El Registry salió en preview el 8 de septiembre de 2025 y sigue en preview. Todas las páginas de la documentación llevan el mismo aviso: «Breaking changes or data resets may occur before general availability». Es decir, puede haber cambios que rompan tu integración e incluso un borrado de datos.

El 24 de octubre de 2025 la API entró en una congelación, la v0.1. Desde entonces, /v0.1/ solo recibe cambios compatibles hacia atrás. El README dice que ese periodo sirve para validar la API con integraciones reales y preparar la v1 de la disponibilidad general. No hay fecha anunciada para esa disponibilidad general ni para la v1.

Para saber qué versión del servicio está en producción basta con preguntar a GET /v0.1/version. El 8 de octubre de 2026 respondía con la 1.8.1, compilada el 6 de agosto de 2026.

¿Qué ha cambiado desde la preview?

Estos son los cambios que afectan a quien publica o consume datos:

• La API pasó a identificar los servidores por su nombre en lugar de por un ID interno, con rutas como /v0.1/servers/{serverName}/versions/{version}.
• Cada versión tiene ahora un estado: active, deprecated o deleted. El publicador lo cambia con mcp-publisher status.
• La v1.8.0 (13 de julio de 2026) añadió el tipo de paquete Cargo, para crates.io.
• Desde esa misma versión, publicar bajo el namespace de una organización de GitHub exige ser Owner de la organización. Ser miembro ya no basta.
• La v1.8.1 (6 de agosto de 2026) corrigió una toma de namespaces (PR #1506). Quien tuviera permiso de escritura en el repositorio <org>.github.io podía servir una clave desde GitHub Pages y publicar bajo todo io.github.<org>/*. Ahora el Registry rechaza github.io y sus subdominios en la verificación por DNS y por HTTP.
• El esquema de server.json tiene versiones fechadas. La que usan los ejemplos actuales es la 2025-12-11.

¿Cómo se publica un servidor en el MCP Registry?

Se publica con la CLI oficial, mcp-publisher, que se instala como binario desde las releases de GitHub o con brew install mcp-publisher. Sus comandos son init, login, logout, publish, status y validate.

La guía oficial sigue estos pasos para un paquete de npm:

1. Añade el campo mcpName a tu package.json.
2. Publica el paquete en npm. El Registry solo guarda metadatos, así que el paquete tiene que existir antes.
3. Instala mcp-publisher.
4. Ejecuta mcp-publisher init y edita el server.json que genera.
5. Inicia sesión con mcp-publisher login github, que usa el flujo de dispositivo de GitHub.
6. Ejecuta mcp-publisher publish.

Este es el server.json de ejemplo de la guía:

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "io.github.my-username/weather",
  "description": "An MCP server for weather information.",
  "repository": {
    "url": "https://github.com/my-username/mcp-weather-server",
    "source": "github"
  },
  "version": "1.0.1",
  "packages": [
    {
      "registryType": "npm",
      "identifier": "@my-username/mcp-weather-server",
      "version": "1.0.1",
      "transport": {
        "type": "stdio"
      }
    }
  ]
}

Fuente: MCP Registry Quickstart (modelcontextprotocol.io/registry/quickstart), consultada el 8 de octubre de 2026.

El campo description admite 100 caracteres como máximo. La version es obligatoria y única: una vez publicada, ni ella ni el resto de metadatos se pueden cambiar. La documentación de versionado recomienda SemVer y prohíbe los rangos como ^1.2.3. Los tipos de paquete admitidos son npm, pypi, nuget, cargo, oci y mcpb.

Un servidor remoto se declara en remotes, con el tipo streamable-http o sse. La documentación pide publicar sse solo para dar servicio a clientes antiguos, porque ese transporte está deprecado. La URL remota tiene que ser accesible públicamente, y un mismo server.json puede llevar packages y remotes a la vez.

Si publicas desde CI, mcp-publisher login github-oidc se autentica desde GitHub Actions sin guardar un secreto propio en el repositorio. Para comprobar que la ficha ya está publicada, la guía usa esta consulta:

curl "https://registry.modelcontextprotocol.io/v0.1/servers?search=io.github.my-username/weather"

Fuente: MCP Registry Quickstart.

¿Cómo demuestra el Registry que el servidor es tuyo?

El nombre del servidor va en DNS inverso, y el prefijo dice cómo se verifica que eres su dueño. Con GitHub, el nombre empieza por io.github.<usuario>/ o io.github.<org>/, y lo demuestras iniciando sesión con esa cuenta (OAuth) o ejecutando la publicación desde GitHub Actions de ese usuario u organización (OIDC). Con un dominio propio, el nombre empieza por su forma inversa, como com.example/.

Para un dominio hay dos pruebas. Por DNS, publicas un registro TXT en el apex del dominio con tu clave pública, y eso cubre el dominio y sus subdominios. Por HTTP, sirves la clave en https://example.com/.well-known/mcp-registry-auth. El formato del registro TXT es este:

example.com. IN TXT "v=MCPv1; k=ed25519; p=<clave pública>"

Fuente: MCP Registry Authentication.

Además del namespace, el paquete tiene que apuntar de vuelta al nombre del servidor. En npm lo hace el campo mcpName del package.json. En PyPI y NuGet, la cadena mcp-name: <nombre> en el README, que puede ir en un comentario HTML. En Cargo esa cadena tiene que verse, porque crates.io elimina los comentarios HTML. En OCI se usa la etiqueta io.modelcontextprotocol.server.name. Un paquete MCPB lleva su fileSha256 en el server.json; el Registry no valida ese hash, pero los clientes sí lo comprueban antes de instalar.

Hay una cosa que el Registry no verifica: que controles la URL de un servidor remoto. La documentación del repositorio lo aclaró el 6 de octubre de 2026: «It does not verify that you control the remote URL, regardless of authentication method». Lo que sí impide es que dos nombres usen la misma URL.

El namespace es la forma fiable de distinguir un servidor oficial de un imitador. com.stripe/mcp solo lo puede publicar quien controla el dominio de Stripe. Un nombre como io.github.alguien/stripe-mcp puede publicarlo cualquiera.

¿Se puede retirar un servidor del MCP Registry?

Sí, aunque no lo borras del todo. Con mcp-publisher status cambias el estado de una versión, o de todas con --all-versions. Este es el ejemplo de la FAQ del repositorio:

mcp-publisher status --status deleted --message "No longer maintained" io.github.my-username/my-server 1.0.0

Fuente: FAQ del Registry en el repositorio modelcontextprotocol/registry.

La misma FAQ advierte: «Server metadata is never permanently removed from the registry». La ficha deja de salir en los listados por defecto, pero la API la sigue sirviendo con el filtro include_deleted=true.

Importante: la FAQ publicada en modelcontextprotocol.io todavía dice que no se puede despublicar. Esa página va por detrás del repositorio. La versión correcta es la del repositorio, porque los endpoints de estado figuran en la referencia oficial de la API y el comando aparece en mcp-publisher --help.

¿Cómo se consulta la API del Registry?

La lectura es pública y no necesita autenticación. Estas son las rutas principales de la v0.1:

• GET /v0.1/servers lista las fichas con paginación por cursor (limit, cursor y metadata.nextCursor en la respuesta).
• GET /v0.1/servers/{serverName}/versions devuelve todas las versiones de un servidor.
• GET /v0.1/servers/{serverName}/versions/{version} devuelve una versión concreta, y latest sirve como versión especial.

El nombre va codificado en la URL, así que io.modelcontextprotocol/everything se escribe io.modelcontextprotocol%2Feverything. Para buscar hay pocos filtros: search (subcadena del nombre, sin distinguir mayúsculas), updated_since, version=latest e include_deleted. No hay categorías ni etiquetas. El roadmap las descarta «to reduce moderation burden», y la documentación remite a los subregistros para búsquedas más avanzadas.

En cada ficha, el Registry añade su propio bloque _meta con status, publishedAt, updatedAt, statusChangedAt e isLatest. No hay campos de verificación, descargas, estrellas ni categorías.

La documentación interactiva está en https://registry.modelcontextprotocol.io/docs. La ruta /v0/ sigue viva como versión de desarrollo, pero en producción se recomienda /v0.1/.

Si construyes un agregador, la documentación espera que copies los datos de vez en cuando, por ejemplo una vez por hora, y los guardes en tu propio almacén, porque el Registry no garantiza disponibilidad. En nuestra prueba la API respondía despacio.

¿Qué hace el Registry con los servidores maliciosos?

Poco, y lo dice abiertamente: «The MCP Registry is quite permissive! We only remove illegal content, malware, spam, and completely broken servers». Quien consume los datos debe asumir «minimal-to-no moderation».

No retira servidores de baja calidad, con errores o con vulnerabilidades. Tampoco hace análisis de seguridad: lo delega en los registros de paquetes y en los agregadores. Cuando retira un servidor, cambia su estado a deleted.

No existe un sello de «servidor verificado». Lo único que se verifica es el namespace y el vínculo con el paquete. El roadmap descarta los rankings de calidad y la curación.

Si encuentras un servidor malicioso, la FAQ pide dos cosas. Primero, denunciarlo en el registro del paquete (npm, PyPI, Docker Hub). Después, abrir un issue en el repositorio del Registry con un título que empiece por Abuse report: . No hay un comando de denuncia en la CLI.

Aparecer en el Registry no es una recomendación. En los mejores servidores MCP explicamos cómo distinguir el oficial de sus imitadores, y en seguridad en servidores MCP, qué revisar antes de instalar uno.

¿Qué son los subregistros?

La documentación define un subregistro como un agregador que también implementa la especificación OpenAPI del Registry. Así un host puede consumir los metadatos con la misma interfaz, venga de donde venga. Cada subregistro puede añadir sus propios datos dentro de _meta, bajo una clave suya. El ejemplo oficial añade una valoración, un contador de descargas y un análisis de seguridad.

El anuncio de 2025 distingue dos tipos. Los públicos, como los marketplaces asociados a cada cliente, enriquecen los datos que copian del oficial. Los privados viven dentro de empresas con requisitos estrictos de privacidad y seguridad, y usan el oficial como fuente de partida. Los documentos oficiales citan como ejemplos Smithery, PulseMCP y el GitHub MCP Registry.

Un subregistro no se «registra» en el oficial ni se declara con un archivo especial. Es un servicio que implementa la misma API. Es el caso de Nortia Logística, la empresa ficticia del curso: sus cuatro servidores son internos, así que no van al Registry oficial. En la lección 14 proponemos publicarlos en un registro privado que implemente la misma OpenAPI, con el mismo formato de server.json. La lección Patrones enterprise desarrolla ese catálogo privado y su gobierno, y Arquitecturas distribuidas trata el descubrimiento de servidores detrás de una pasarela.

¿Qué relación tiene con las Server Cards?

La SEP-2127, que define las Server Cards, se fusionó el 6 de octubre de 2026 con estado Final, como extensión. Si leíste nuestro artículo sobre Server Cards y AI Catalog, allí aparece todavía en revisión.

La SEP reparte los papeles con claridad. La Server Card describe solo la conexión con un servidor remoto y se descubre a través de AI Catalog, que puede publicarse en /.well-known/ai-catalog.json del dominio del proveedor. El server.json del Registry sigue siendo el dueño de los metadatos de instalación local: paquetes, argumentos, variables de entorno. Una entrada del Registry puede referenciar o incluir la información remota de una card.

El Registry es un índice central al que el publicador sube sus datos. La Server Card la publica cada proveedor en su dominio. El charter del grupo de trabajo dice que el Registry expondrá Server Cards, pero hoy no hay ningún endpoint que las sirva.

Lo que todavía no se sabe

Hay preguntas razonables que las fuentes oficiales no responden a 8 de octubre de 2026:

• Cuántos servidores hay publicados. La API no devuelve un total y no hay cifra oficial. Las que circulan son de terceros.
• Cuándo llega la disponibilidad general o la API v1. El README habla de preparar la v1, sin fecha.
• Si Claude, VS Code o Cursor leen del Registry oficial. Las fuentes del Registry no lo dicen, y su documentación indica que los hosts deberían leer de subregistros.

Qué corregimos de la versión anterior

La versión de 2025 daba como fecha de lanzamiento el 8 de septiembre de 2024 y se lo atribuía solo a Anthropic. La preview salió el 8 de septiembre de 2025. También usaba rutas /api/v1/servers que devuelven 404, filtros por categoría y etiquetas, un archivo mcp.json en lugar de server.json, una CLI mcp-registry en lugar de mcp-publisher, un cliente registry-client, sellos verified y un roadmap de 2024. Nada de eso consta en las fuentes oficiales.

Varios paquetes npm que citaba no existen, otros son servidores archivados y dos enlaces daban 404. Se sostenían la URL, la API REST, la idea de los subregistros y los motivos de denuncia.

Siguientes pasos

• La lección 14 del curso sitúa el Registry junto a las extensiones y los borradores. Es gratuita con una cuenta.
• Para tener algo que publicar, crea un servidor en TypeScript o en Python.
• Si te falta vocabulario (host, cliente, transporte), tienes el glosario de MCP.