MCP registry: descubrir, autorizar y versionar herramientas

Un catálogo de herramientas de agente no es una hoja de cálculo que alguien mantiene actualizada. Es infraestructura. El MCP registry es la capa que cataloga cada servidor MCP publicado, registra quién puede verlo y especifica qué versión está activa; y decide lo que existe antes de que cualquier gateway decida lo que pasa.

El blog ya ha cubierto las dos capas vecinas. El protocolo MCP define cómo viaja el mensaje entre el modelo y la herramienta. El gateway MCP define qué pasa, con qué política, a qué costo y con qué auditoría. Ninguna de las dos responde a la pregunta que surge antes que todas ellas: qué herramientas existen, quién puede verlas y qué versión está sirviendo a quién.

Esa pregunta es fácil de responder con 8 servidores MCP. Con 80, se convierte en un problema de catálogo, y el catálogo tiene metadatos, política y ciclo de vida. El cuello de botella dejó de ser la latencia y pasó a ser saber qué existe.

¿Qué es un MCP registry?

Un MCP registry es un catálogo de metadatos de servidores MCP: nombre, propietario verificado, dónde está alojado el paquete, cómo ejecutarlo y qué herramientas publica cada servidor. No aloja código ni tráfico. Aloja la información que permite a un cliente descubrir y conectar un servidor sin que un humano pegue una URL en un archivo de configuración.

El registry oficial del Model Context Protocol entró en vista previa el 8 de septiembre de 2025, anunciado en el blog del propio protocolo con la firma de sus mantenedores y de Theodora Chu, gerente de producto del MCP en Anthropic. El texto de lanzamiento es directo sobre la intención: ser la fuente única de verdad para servidores MCP públicos, con el registry y la especificación OpenAPI que lo describe publicados como código abierto.

Dos decisiones de este anuncio importan más que el lanzamiento en sí.

La primera es la separación entre metadato y paquete. npm, PyPI y Docker Hub continúan alojando código y binarios. El registry aloja el puntero. Un paquete weather-mcp reside en npm; el registry guarda que ese servidor, en esa versión, corresponde a ese paquete. Cuando alguien pregunta por qué falló la instalación, la respuesta puede estar en cualquiera de los dos, y son dos propietarios diferentes.

La segunda es que el registry oficial no está destinado a ser consumido directamente por aplicaciones cliente. La documentación es explícita: está diseñado para agregadores descendentes, como marketplaces de servidores MCP, que extraen los metadatos a través de una API REST a intervalos regulares (el ejemplo que la propia documentación cita es una vez por hora) y los curan a partir de eso. Las aplicaciones cliente consumen estos otros registries, que implementan la misma especificación OpenAPI.

Aquí está la consecuencia que casi nadie planifica. El registry público resuelve el descubrimiento de lo que es público. No resuelve el descubrimiento de lo que es propio.

Por qué el registry público no resuelve el problema de su equipo

El registry oficial no acepta servidores privados. La documentación aborda el caso sin rodeos: los servidores accesibles solo a un conjunto restringido de usuarios, publicados en una red interna o en un registry de paquetes privado, no se incluyen. La recomendación para este contexto es alojar un registry privado propio y colocar los servidores allí.

Esto no es una limitación que se pueda sortear con una configuración creativa. Es un diseño. El registry público es un mecanismo de namespace y procedencia para lo que es abierto; su catálogo interno es otra cosa, con otro propietario, otra política y otro ciclo de vida.

A partir de ahí, el recuento de integraciones de una empresa se convierte en el problema real. Un equipo de plataforma que ejecuta agentes en producción acumula servidores MCP de tres orígenes distintos, y cada origen tiene un régimen de confianza diferente:

• Servidores públicos, instalados a partir de un paquete en npm, PyPI o Docker Hub, con procedencia verificable por el registry oficial.
• Servidores internos, escritos por el propio equipo, que exponen sistemas de la empresa y no tienen cabida en el catálogo público.
• Servidores de terceros contratados, que se ejecutan de forma remota, exigen OAuth y traen su propio ciclo de revisión.

Sin un catálogo, el descubrimiento ocurre a ciegas. El agente descubre la herramienta que el desarrollador pegó en su archivo de configuración. No existe inventario, no existe propietario declarado, no existe política de alcance. Y ahí aparece la pregunta que bloquea la reunión de arquitectura: ¿puede este agente llamar al servidor que emite facturas?

Alcance de descubrimiento: el mismo servidor, tres respuestas

Aquí está el punto que separa un catálogo de una lista. Un catálogo responde lo que existe en el repositorio general. Un registry responde lo que existe para usted, aplicando una política de visibilidad segregada por equipo, agente y entorno operativo para proteger herramientas críticas de accesos indebidos.

El metadato de un servidor MCP publicado es único. Su visibilidad no lo es. El mismo servidor de lectura de base de datos aparece para el agente de análisis financiero y desaparece para el agente de soporte al cliente, y la diferencia reside en la política de alcance, no en el registro.

El permiso de la herramienta no es el permiso del agente, y esta confusión es costosa. Quien resolvió la identidad y la trazabilidad del agente cubrió la mitad del problema; la otra mitad es el alcance de publicación y descubrimiento a nivel del servidor MCP y de la herramienta que expone. Las permisos de acceso y trazabilidad en agentes de IA responden quién es el agente y qué hizo. El registry responde lo que puede encontrar.

La autorización de un servidor MCP remoto

Autorizar un servidor MCP remoto es un flujo OAuth 2.1, y el protocolo no deja esto en el aire. Cuando el transporte es HTTP, el servidor protegido actúa como servidor de recursos OAuth y el cliente descubre los metadatos del servidor de autorización antes de cualquier llamada. El transporte local por stdio sigue el camino opuesto: las credenciales provienen del entorno, y la especificación recomienda que este camino no siga el flujo OAuth.

Vale la pena señalar lo que es opcional y lo que no lo es, porque una lectura perezosa trata a ambos como iguales.

El subconjunto es la parte interesante. La especificación dice, en texto, que implementa una selección de características de estas normas para preservar la seguridad y la interoperabilidad sin añadir complejidad innecesaria. Traduciendo a la operación: no existe un servidor MCP "con OAuth completo" y otro "sin OAuth". Existe un conjunto específico de capacidades acordadas, y es contra él que su catálogo necesita registrar lo que cada servidor exige.

El ciclo de vida de publicación de una herramienta

Publicar una herramienta en un catálogo es un procedimiento con etapas, y cada etapa deja un registro que alguien consultará después. El ciclo a continuación sigue lo que la documentación del registry oficial exige de un publicador.

1. Verificar el namespace. El nombre del servidor sigue el formato de DNS inverso y vincula el origen a una cuenta verificada. Con autenticación por GitHub, el nombre asume la forma io.github.usuario/*; con autenticación por dominio, la forma com.ejemplo.*/* y la prueba proviene de un registro TXT publicado en el DNS de ese dominio.
2. Declarar el metadato. El server.json contiene el nombre único, la versión, dónde está alojado el servidor, las instrucciones de ejecución y los datos de descubrimiento. Es este archivo el que leerá un agregador.
3. Publicar la versión. La versión es obligatoria, debe ser única por publicación y, una vez publicada, la versión y el metadato no pueden ser modificados. Corregir significa publicar de nuevo.
4. Aplicar el alcance. El catálogo interno recibe la entrada con propietario, equipo, entorno y las herramientas expuestas, y es aquí donde la visibilidad deja de ser uniforme.
5. Registrar la política de autorización. Lo que ese servidor exige para ser llamado, y qué identidad de agente puede listarlo.
6. Consumir y versionar. Clientes y agregadores extraen el metadato, y cada consumidor pasa a depender de una versión específica. La deuda comienza exactamente aquí.

El paso 3 es donde la mayoría de las arquitecturas pierde el control, y la documentación explica por qué. El registry recomienda el versionado semántico, pero acepta cualquier formato de cadena. Cuando la versión publicada no se analiza como semántica, se marca como "latest" de todos modos. Y existe una prohibición explícita: las cadenas que parecen rangos de versión, como ^1.2.3, ~1.2.3, 1.x o 1.2.*, son rechazadas.

Observe lo que esto significa para su catálogo interno. Puede registrar 2025.11.25 y 2025.6.18 como versiones válidas, y la comparación entre ellas deja de ser aritmética. Si una de las dos no se analiza, el criterio de desempate pasa a ser la marca de tiempo de publicación. Un catálogo que ordena la versión por cadena coloca 1.10.0 antes de 1.9.0.

Cómo versionar sin romper lo que ya se consume

La regla del registry es dura y vale la pena internalizarla: la versión publicada no cambia. El metadato publicado no cambia. Si un servidor necesita corregir lo que declaró, publica una nueva versión, y la anterior sigue existiendo en el historial.

Esto protege la integridad del catálogo y transfiere el problema al consumidor. Cuarenta consumidores escritos contra la v1 de un servidor no migran porque la v2 esté disponible. Migran cuando alguien decide que migren. Y esa decisión necesita un lugar donde residir.

El protocolo tiene una pieza que ayuda, y es lo suficientemente reciente como para pasar desapercibida. En la revisión en vigor, la actual 2026-07-28, cada solicitud declara la versión del protocolo que utiliza, y el servidor acepta o rechaza la solicitud por solicitud. Si el servidor no soporta la versión solicitada, responde con un error que lista las versiones que soporta, y el cliente puede intentar de nuevo con una versión mutua. La negociación es por llamada, no por sesión.

Junto con esto, un cliente que quiere elegir la versión antes que nada puede llamar a una RPC obligatoria que devuelve, en una única solicitud, las versiones soportadas, las capacidades y la identidad del servidor. Llamar es opcional. Saber que existe no lo es.

El detalle que cierra el argumento es este: un servidor MCP declara si emitirá una notificación cuando la lista de herramientas disponibles cambie. Es decir, el descubrimiento de herramientas en MCP es dinámico por contrato, no por convención. Un agente conectado a un servidor puede ver el conjunto de herramientas crecer o encogerse durante la operación.

Y es exactamente por eso que un archivo de configuración estático no es un catálogo. Es una fotografía. Si el servidor cambia el conjunto de herramientas y su política de descubrimiento no lo acompaña, el agente pasa a operar contra un inventario que ya no corresponde a lo que existe.

¿Convención interna o catálogo gestionado?

La decisión real no es entre comprar una herramienta y no comprar nada. Es entre mantener una convención que solo funciona mientras el equipo es pequeño, y operar un catálogo con metadatos, alcance y ciclo de versión. Ambas opciones son legítimas en diferentes rangos de escala. La escala decide.

La lectura honesta de la tabla es que la columna de la izquierda es correcta hasta el momento en que deja de serlo, y nadie marca la fecha. La señal de que la fecha ha llegado tiene un nombre: cuando existe una integración que nadie puede explicar de dónde vino, y un agente en producción que la llama.

Dónde esta capa se conecta con el modelo económico

La conexión entre catálogo y costo no es obvia, y vale la pena detallarla. Cada herramienta publicada es una llamada que puede repetirse, y cada llamada repetida es un token. Sin un registro de quién consume qué, la factura de inferencia de un mes no es atribuible a ningún equipo, y la discusión sobre enrutamiento de costos queda sin base de prorrateo.

Lo mismo ocurre con la capacidad. Un catálogo que registra cuántas herramientas expone cada servidor y cuántos consumidores las llaman permite comparar el volumen de invocación entre proveedores y ajustar el costo por tarea con datos, no con estimaciones. La capa de registro es anterior al enrutamiento, pero es ella la que produce el inventario sobre el cual operará el enrutamiento.

Errores que aparecen después del primer trimestre

Tres patrones aparecen en prácticamente toda operación que pasa de un equipo piloto a varios, y ninguno de ellos es un error de herramienta. Son errores de proceso que la herramienta solo revela.

El primero es tratar el registry público como inventario interno. No acepta servidores privados, y forzarlo a aceptarlos significa publicar metadatos de sistemas internos en un catálogo abierto. La solución correcta es operar un registry privado que implemente la misma especificación OpenAPI, lo que también preserva el soporte de las aplicaciones cliente.

El segundo es publicar sin propietario. Un metadato sin responsable declarado es un metadato que nadie actualiza, y la depreciación de una herramienta sin propietario ocurre por abandono, no por decisión. Cuando el servidor muere, el agente que lo llamaba lo descubre en producción.

El tercero es confundir la versión del servidor con la versión de la API remota. Para un servidor local, la recomendación es alinear la versión del servidor con la versión del paquete. Para un servidor remoto con API versionada, la recomendación es alinear con la versión de la API. Mezclar ambos regímenes produce un catálogo en el que la misma cadena de versión significa dos cosas.

En la revisión actual, el protocolo también marca las características como depreciadas sin eliminarlas de inmediato: una característica depreciada documenta el camino de migración y permanece en la especificación durante al menos doce meses antes de ser elegible para su eliminación. Quien opera un catálogo interno necesita el mismo mecanismo, con un plazo declarado. Sin plazo, la depreciación es una intención.

Preguntas frecuentes

¿Qué es un MCP registry? Es un catálogo de metadatos de servidores MCP. Guarda el nombre, la versión, el propietario verificado, dónde está alojado el paquete y cómo ejecutarlo. No aloja código ni tráfico, y existe para que un cliente descubra y conecte servidores sin configuración manual.

¿El registry oficial acepta servidores privados? No. La documentación recomienda explícitamente que quienes tienen servidores internos, publicados en una red privada o en un registry de paquetes privado, alojen un registry propio. El registry oficial es un mecanismo de procedencia para lo que es público.

¿Qué es la autorización MCP y cuándo se aplica? Es el flujo de autorización del protocolo, basado en OAuth 2.1, y es opcional. Cuando se implementa sobre transporte HTTP, el servidor actúa como servidor de recursos y el cliente descubre los metadatos antes de llamar. En transporte stdio, la recomendación es buscar credenciales del entorno.

¿Qué significa el descubrimiento dinámico de herramientas en MCP? Un servidor puede declarar que notificará a los clientes cuando la lista de herramientas disponibles cambie. El descubrimiento es dinámico por contrato de la especificación, no por convención del proveedor. Un archivo de configuración estático es una fotografía, no un catálogo.

¿Se puede corregir una versión publicada? No. La versión debe ser única por publicación y, una vez publicada, la versión y el metadato no pueden ser modificados. Corregir exige publicar una nueva versión. El registry rechaza cadenas que parecen rangos de versión, como ^1.2.3 y 1.2.*.

¿Se puede operar sin un catálogo gestionado? Sí, y es la elección correcta por debajo de algunas decenas de integraciones. El costo aparece cuando una integración no tiene un origen explicable y un agente en producción la llama. La convención interna no falla por escala, falla por falta de un propietario declarado.

Referencias y Lectura Complementaria

• The MCP Registry, documentación oficial del protocolo, acceso el 17 de septiembre de 2026: fuente única de verdad, formato server.json, namespace por DNS inverso, alcance para agregadores descendentes y la regla que no admite servidor privado.
• Versioning Published MCP Servers, acceso el 17 de septiembre de 2026: inmutabilidad de la versión publicada, recomendación de versionado semántico y la prohibición de cadenas de rango.
• How to Authenticate When Publishing to the Official MCP Registry, acceso el 17 de septiembre de 2026: las formas de nombre io.github.usuario/* y com.ejemplo.*/*, y la autenticación por registro TXT en el DNS.
• Authorization, especificación en la revisión 2026-07-28, acceso el 17 de septiembre de 2026: OAuth 2.1 como base, el carácter opcional de la autorización y las normas del subconjunto implementado.
• Versioning, acceso el 17 de septiembre de 2026: la revisión actual, la negociación por solicitud y la política de depreciación con un plazo mínimo de doce meses.
• Tools, acceso el 17 de septiembre de 2026: la capacidad tools con listChanged, que hace que el descubrimiento sea dinámico por contrato.
• Introducing the MCP Registry, 8 de septiembre de 2025: el anuncio de lanzamiento del registry oficial en vista previa, con sub-registries públicos y privados.

Qué hacer el lunes

El orden importa. Es lo opuesto a la intuición. Antes de elegir un gateway, cuente cuántos servidores MCP tiene la empresa, cuántos propietarios declarados existen para ellos y cuántos consumidores llaman a cada versión. Este levantamiento se puede hacer en una tarde y responde a la pregunta que ninguna decisión de tráfico responde.

Si el número es pequeño, una convención interna con un propietario nombrado por servidor lo resuelve. Si el número superó la decena, la capa de registro dejó de ser documentación y se convirtió en infraestructura, y la diferencia práctica es quién responde cuando un agente llama a una herramienta que nadie sabía que existía.

Es exactamente esta transición la que Nexforce Agents aborda con Nexforce Work: la capa de catálogo, permisos y conectores MCP existe para funcionar cuando la operación pasa de un equipo piloto a varios, con la lista de herramientas disponibles bajo control en lugar de bajo convención. Los agentes de IA B2B que se ejecutan en producción dependen de esto, y Nexforce Code consume los mismos servidores MCP como herramientas externas.

El catálogo es la parte del sistema que nadie mira hasta el día en que es lo único que explica lo que sucedió.