El MCP Registry: cómo los agentes encuentran servidores, a fondo

La spec de MCP que se finalizó ayer le dice a los agentes cómo hablar con los servidores. No dice nada sobre cómo encontrarlos. Ese trabajo le pertenece al MCP Registry oficial — una capa de metadata deliberadamente aburrida que se está convirtiendo en silencio en la raíz del discovery de servidores. La diseccionamos, y después crawleamos su API en vivo para medir qué hay adentro realmente.

Este blog ya cubrió dos capas de discovery. x402 Bazaar indexa endpoints pagos y los rankea por actividad real de settlement. ERC-8004 pone la identidad de agentes on-chain — y la primera auditoría empírica encontró que la mayoría de los registros son placeholders apuntando a endpoints muertos. El MCP Registry es la tercera capa, y la menos glamorosa: responde la pregunta "cómo se llama este servidor, y dónde lo consigo". Resulta que responder solo esa pregunta, y negarse a responder cualquier otra, es la decisión de diseño más interesante de todo el sistema.

Una capa de metadata, no un app store

El registry lanzó en preview el 8 de septiembre de 2025 en registry.modelcontextprotocol.io, anunciado como "un catálogo abierto y API para servidores MCP públicamente disponibles". El desarrollo lo lideraron PulseMCP, el equipo de Goose de Block, GitHub y Anthropic, con contribuidores de nueve empresas. En el día a día lo gobierna un working group del registry con miembros de PulseMCP, Stacklok, TeamSpark y Ravenmail. El código es open source — Go y PostgreSQL.

Lo primero que hay que entender es qué no hospeda: código. Los paquetes viven donde siempre vivieron — npm, PyPI, Docker Hub. El registry hospeda metadata que apunta hacia ellos. La documentación oficial usa el ejemplo de un paquete weather-mcp en npm: la entrada del registry mapea "weather v1.2.0" a npm:weather-mcp. El security scanning se delega explícitamente a los package registries subyacentes y a los consumidores downstream. Los servidores privados quedan fuera de alcance por completo — cualquier cosa detrás de una red corporativa o un package registry privado debe vivir en un registry privado.

Lo segundo es su postura de madurez. Diez meses después del lanzamiento, el registry sigue etiquetado como preview, y la documentación advierte que puede haber breaking changes o resets de datos antes de la disponibilidad general. El API, sin embargo, entró en freeze en v0.1 en octubre de 2025 para que los integradores pudieran construir contra él con confianza, con una v1 planificada para GA. Esa combinación — API de lectura congelado, garantías de datos en preview — moldea todo lo que viene downstream, como veremos.

server.json: la unidad de publicación

Cada entrada del registry es un documento server.json, validado contra un schema versionado (actual: 2025-12-11, hospedado en static.modelcontextprotocol.io). El nombre usa DNS inverso más una barra: io.github.username/weather, com.example/server. Más allá de nombre, descripción y versión, el documento tiene dos secciones complementarias: packages para servidores que instalas, y remotes para servidores a los que te conectas.

{
  "$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.",
  "version": "1.0.1",
  "packages": [
    {
      "registryType": "npm",
      "identifier": "@my-username/mcp-weather-server",
      "version": "1.0.1",
      "transport": { "type": "stdio" },
      "environmentVariables": [
        { "name": "YOUR_API_KEY", "isRequired": true, "isSecret": true }
      ]
    }
  ]
}

El array packages soporta seis registry types — npm, pypi, cargo, nuget, oci y mcpb — y cada entrada declara su transport (stdio o streamable-http), un runtimeHint opcional como npx, más runtimeArguments y packageArguments estructurados (posicionales o nombrados, con variables templadas) y variables de entorno marcadas isRequired e isSecret. Esa última parte importa más de lo que parece: un cliente puede renderizar una UI de configuración correcta para cualquier servidor sin leer jamás su README.

El array remotes es la parte que le importa a un operador de gateway: entradas de tipo streamable-http o sse con una URL. Sin paquete, sin paso de instalación — el servidor es un endpoint hospedado al que te conectas. Y todo lo demás va en _meta, una bolsa de extensiones con namespaces de DNS inverso, la misma convención que la spec 2026-07-28 adoptó para las extensiones del protocolo. Los extras del publisher viven bajo io.modelcontextprotocol.registry/publisher-provided; cualquier otro elige su propia clave.

Los namespaces son la capa de identidad

El modelo de confianza del registry se concentra en un solo lugar: probar que eres dueño del nombre bajo el que publicas. Los namespaces io.github.* se verifican via GitHub OAuth (o GitHub OIDC desde Actions, para publicar desde CI). Los dominios propios — com.example/* — se verifican con un registro DNS TXT o un challenge HTTP. La publicación pasa por el CLI mcp-publisher: init genera el server.json, login github corre un device flow, publish sube el documento.

Sobre la verificación de namespace se apoya la validación de propiedad del paquete. Para un paquete npm, el registry exige un campo mcpName dentro del package.json que coincida exactamente con el nombre en el registry. Si publicas metadata reclamando el paquete de otro, el registry lo rechaza: el artefacto mismo debe apuntar de vuelta al nombre. Esto cierra exactamente el hueco que la auditoría de ERC-8004 expuso on-chain, donde cualquiera podía registrar una identidad envolviendo cualquier URL y solo el 3–15% de las entradas resolvía a un archivo de registro válido y vivo. En el MCP Registry, una entrada está como mínimo atada a un artefacto real y con dueño.

El API: pequeño, congelado, paginado por cursor

El API de lectura es mínimo y ha sido estable desde el freeze. Tres endpoints importan: GET /v0.1/servers lista todo, GET /v0.1/servers/{name}/versions lista las versiones de un servidor, y GET /v0.1/servers/{name}/versions/{version} trae un documento — con latest como alias especial de versión. Los nombres de servidor contienen una barra, así que deben ir URL-encoded: io.modelcontextprotocol/everything se convierte en io.modelcontextprotocol%2Feverything. El endpoint de listado acepta cursor y limit para paginación, search para matching por substring sobre nombres, version=latest para colapsar a versiones actuales, y — el parámetro que hace funcionar todo el modelo de consumo — updated_since, un timestamp RFC 3339 para sync incremental.

# primera página de servidores actuales
curl "https://registry.modelcontextprotocol.io/v0.1/servers?limit=100&version=latest"

# todo lo que cambió desde un timestamp — el loop del agregador
curl "https://registry.modelcontextprotocol.io/v0.1/servers?updated_since=2026-07-28T00:00:00Z"

Cada documento devuelto lleva metadata generada por el registry bajo _meta["io.modelcontextprotocol.registry/official"]: publishedAt, updatedAt, isLatest, y un status que es active, deprecated o deleted. El resto de la metadata del servidor se trata como inmutable — el status es el único campo que se espera que cambie, y la documentación recomienda a los consumidores mantenerlo fresco. El documento OpenAPI está versionado por fecha, 2025-12-01, espejando cómo se versiona la propia spec de MCP.

Nadie lo consume directamente — por diseño

Aquí viene la parte inusual. La documentación oficial dice sin rodeos que las aplicaciones host no deberían consumir el registry oficial. No ofrece garantías de uptime ni de durabilidad de datos. En cambio, espera que agregadores downstream lo scrapeen de forma regular pero infrecuente — la documentación sugiere una vez por hora — persistan los datos en sus propios stores, y sirvan a los usuarios finales ellos mismos. El registry es una raíz, no un resolver. La analogía con DNS es difícil de esquivar: una zona raíz pequeña y neutral, y todo el serving opinionado empujado a los bordes.

Los agregadores que además implementan la spec OpenAPI del registry se convierten en subregistries: fuentes drop-in compatibles que cualquier host MCP puede consumir por la misma interfaz. La spec bendice explícitamente inyectar metadata custom — el ejemplo de la documentación muestra un subregistry agregando user_rating, download_count y resultados de security_scan bajo su propia clave de _meta. Curación, ratings, scanning, políticas enterprise: todo downstream, todo con namespace, nada contaminando la raíz.

Esto ya es un ecosistema real, no un diagrama. La lista de proyectos de la comunidad incluye servidores de subregistry de grado enterprise como ToolHive de Stacklok (nativo de Kubernetes, con access control y audit logging), extensiones hospedadas como ToolSDK, frontends de exploración, SDKs cliente en Go, TypeScript y Java, y una GitHub Action para publicar desde CI. Los vendors enterprise están posicionando registries como planos de control de gobernanza. La raíz neutral creó un mercado de opiniones encima de ella.

Midiendo el registry, en vivo

La documentación describe la intención; el API describe la realidad. Así que lo medimos. El 29 de julio de 2026 paginamos GET /v0.1/servers?version=latest desde el primer cursor hasta el último: 191 páginas de 100, para un total de 19,016 servidores en su última versión — 18,814 con status active y 202 deprecated. Las entradas eliminadas no aparecen salvo que pases include_deleted=true, así que el catálogo visible es en la práctica el posterior a la moderación. Los nombres barren alfabéticamente desde dominios vanity ai.*, pasando por namespaces corporativos com.*, hasta la larga cola de io.github.* — con publishers agregados en el medio, como las 213 entradas bajo el namespace ai.smithery/ de Smithery.

Una nota operativa del ejercicio: un crawl completo con limit=100 tomó casi una hora contra un endpoint público sin SLA. Eso no es un bug — es el diseño diciéndote cómo comportarte. Los escaneos completos son para el bootstrap; después de eso, se supone que mantengas tu propia copia y consultes updated_since cada hora. Cualquier consumidor serio de este registry está, estructuralmente, obligado a convertirse en un agregador.

La lección de la auditoría de ERC-8004 aplica también aquí: los conteos de registro no son adopción. Registrarse es barato, y un registry en preview con moderación permisiva va a acumular ruido. La diferencia estructural es que cada entrada del MCP Registry está al menos anclada a un artefacto o namespace con dueño — el piso es más alto que un puntero on-chain sin verificar. Lo que al registry todavía le falta, deliberadamente, es cualquier señal de calidad o de liveness: sin probes, sin ratings, sin datos de uso. Ese es el trabajo de los subregistries.

Tres capas de discovery, un solo stack

Pon las tres capas lado a lado y la división del trabajo es limpia. El MCP Registry resuelve naming y packaging: identificadores canónicos, namespaces verificados, metadata de instalación y conexión legible por máquinas. x402 Bazaar resuelve el discovery pago: indexa endpoints en el momento del settlement y los rankea por actividad real de pago — una señal de reputación que cuesta dinero falsificar. ERC-8004 apunta a identidad on-chain portable, y por ahora entrega las garantías más débiles de las tres. Ninguna reemplaza a las otras. Una economía de agentes necesita las tres respuestas: cómo se llama esto, funciona de verdad, y quién responde por ello.

La apuesta del registry es que mantenerse sin opinión en la raíz es lo que le permite ganar la capa de naming. Se niega a rankear, se niega a escanear, se niega a hospedar, y congela un API diminuto. Todo lo disputado — confianza, calidad, precio — se empuja a capas donde puede haber competencia. Es la pieza con más forma de infraestructura del ecosistema MCP, en el sentido de que nadie se va a emocionar nunca con ella, y todo va a depender silenciosamente de ella.

Qué significa para LLM4Agents

LLM4Agents publica un servidor MCP hospedado — la superficie de 67 tools que los agentes usan para inferencia, wallets, workspace y memoria. Hoy, un agente lo encuentra porque su operador leyó nuestra documentación. Una entrada en el registry cambia el funnel: un namespace com.llm4agents verificado por DNS con una entrada remotes de tipo streamable-http hace el gateway descubrible por cualquier cliente MCP que consuma cualquier subregistry, con metadata de configuración lo bastante rica para conectarse sin leer nada. Combinado con el walk-up de x402 — pagar por llamada, sin cuenta — el camino de discovery a primer settlement se vuelve completamente autónomo: un agente puede encontrar el gateway en un registry, conectarse por Streamable HTTP, recibir un 402, pagar en USDC y hacer su trabajo, sin un humano en el loop en ningún paso.

El lado consumidor importa igual. Un gateway que pone al frente cientos de modelos es, funcionalmente, un curador — y el modelo de subregistry es la forma estándar de exponer curación. Sincronizar cada hora desde la raíz oficial con updated_since, filtrar a servidores remotos vivos, y servir el resultado por la misma interfaz OpenAPI le daría a los agentes de nuestra plataforma una superficie de discovery compatible con el estándar y opinionada donde cuenta: liveness, soporte de pago, confiabilidad observada. La amenaza es simétrica: el discovery es la parte alta del funnel, y quien cure la confianza para los agentes es dueño de él. Los vendors de subregistries enterprise ya lo entendieron; todo gateway debería.

Cómo mantenerse en la frontera

Pasos concretos, en orden. Primero, publicar: verificar el namespace com.llm4agents con un registro DNS TXT y subir un server.json con un remote streamable-http apuntando al endpoint MCP — y como el registry está en preview y hay resets de datos posibles, hacer de la publicación un paso de CI con mcp-publisher y GitHub OIDC en vez de un acto único. Segundo, construir el subregistry: un sync horario con updated_since hacia nuestro propio store, expuesto por la spec OpenAPI del registry, filtrado a servidores que pasen probes de salud en vivo — el chequeo que la raíz deliberadamente no hace. Tercero, adjuntar metadata de pago: una clave _meta con namespace declarando soporte x402, schemes y precios para cada servidor indexado, y una propuesta upstream para estandarizar esa convención y que el discovery consciente de pagos deje de ser artesanal. Cuarto, rankear por settlements: incorporar el historial de settlements del propio gateway al ordenamiento del subregistry, importando la única idea de Bazaar que de verdad resiste ataques Sybil. Quinto, seguir el camino a GA: el API v1 será el corte de compatibilidad que importa, y monitorear a diario las transiciones de status mantiene servidores deprecated y deleted fuera de los contextos de los agentes.