¿Qué es MCP Registry? ¿Y por qué no se pueden ejecutar agentes sin uno

Si has estado jugando con Anthropic's Protocolo de contexto modelo (MCP), es probable que te hayas topado con el «muro de localhost».

Clonas un repositorio, ejecutas npx @modelcontextprotocol /server-postgres, lo conectas a Claude Desktop y se siente como por arte de magia. Tu LLM puede comunicarse de repente con tu base de datos. Pero en el momento en que intenta llevar esa arquitectura a la fase de producción (en la que tiene cincuenta agentes, veinte fuentes de datos y funciones de IAM estrictas), la «magia» se convierte en una pesadilla para los sistemas distribuidos.

No solo necesitas un protocolo. Necesitas una agenda telefónica. Necesitas un intermediario que sepa dónde se encuentra cada herramienta, quién puede llamarla y si está en buen estado actualmente.

En la industria, este concepto se está solidificando a medida que Registro MCP.

En TrueFoundry, no solo tratamos el registro como una lista estática de URL. Lo implementamos como una capa de infraestructura de enrutamiento activa utilizando lo que denominamos Servidores MCP virtuales. He aquí un análisis detallado de por qué el registro es el componente más importante que probablemente esté ignorando.

El problema: la matriz de conexiones «N x M»

Sin un registro central, la topología de un sistema de agentes es un desastre.

Supongamos que tiene tres agentes (Support, Sales, DevOps) y tres herramientas (Jira, Salesforce y AWS). Si los conecta directamente, debe codificar los puntos finales y la autenticación de cada herramienta en la configuración de cada agente.

Si el equipo de DevOps traslada la herramienta de Jira a un nuevo clúster, todos los agentes se interrumpen. Si cambias la clave de API para Salesforce, tendrás que volver a implementar todos los agentes.

El Registro MCP resuelve esto desacoplando el consumidor (el agente) del proveedora (la herramienta). El agente se conecta al registro y este dirige la solicitud a la herramienta adecuada.

Esta es la diferencia en la topología.

Figura 1: Flujo de trabajo de conexiones directas frente a topología de registro

El enfoque de TrueFoundry: el registro «virtual»

Implementamos el patrón de registro mediante una función llamada Servidor MCP virtual. Esto convierte de manera efectiva al Gateway en un Registro MCP y pasarela de IA, que combina el descubrimiento, la seguridad y el enrutamiento en tiempo de ejecución en un único plano de control para los sistemas de agentes.

En lugar de crear una base de datos de «catálogo» independiente que los agentes tengan que consultar, creamos el registro directamente en la ruta de red. El TrueFoundry AI Gateway actúa como un servidor MCP «virtual» que se encuentra frente a sus servicios de back-end reales.

Como se explica en el Documentación de TrueFoundry sobre servidores MCP virtuales:

«Un servidor MCP virtual agrega varios servidores MCP en un solo servidor MCP. Esto permite que un cliente MCP se conecte a un único punto final y acceda a herramientas, instrucciones o recursos desde varios servidores MCP».

Este es un cambio sutil pero masivo. Para su agente, el Gateway se parece a un servidor MCP gigante con capacidades infinitas. Entre bastidores, el Gateway dirige el tráfico a un pod de postgres-mcp en el clúster A y a un pod de slack-mcp en el clúster B.

Capacidades de un registro activo

Un registro adecuado hace más que solo enumerar herramientas. Gestiona el ciclo de vida de la interacción.

1. Descubrimiento dinámico

Cuando un agente se conecta a TrueFoundry Gateway, no necesita saber de antemano qué herramientas existen. La conexión usa eventos enviados por el servidor (SSE). Tras un apretón de manos, la puerta de enlace inspecciona la identidad del agente y crea de forma dinámica una lista de las herramientas que puede ver.

Si implementa un nuevo Herramienta de búsqueda vectorial mañana, simplemente agréguelo a la configuración de Gateway. La próxima vez que el agente se conecte, la nueva herramienta estará disponible automáticamente. No es necesario cambiar el código por parte del agente.

2. Autenticación centralizada (La Gorila)

Esta es la parte que hace feliz a InfoSec. Si ejecuta MCP sin procesar, su agente necesitará las credenciales de la base de datos. Eso es un fracaso en materia de seguridad.

Con un enfoque basado en el registro, aprovechamos Autenticación y seguridad de puertas de enlace. El agente solo tiene una clave de API de TrueFoundry. La puerta de enlace contiene los secretos de los servicios posteriores reales.

«La puerta de enlace valida la clave de API del cliente... y, a continuación, envía la solicitud por proxy al servidor MCP de fondo mediante encabezados seguros».

3. Seguimiento y gobernanza

Como todas las llamadas a las herramientas fluyen a través del Registro (la puerta de enlace), se obtiene un registro de auditoría centralizado. Puede ver exactamente qué agente llamó a la herramienta delete_user y cuándo. También puedes establecer límites de velocidad para que un bucle incontrolado en un agente no bloquee tu base de datos de producción.

Tabla 1: Esta es la comparación de los tipos de registro

Integración: cómo se ve en el código

La belleza de esta abstracción es lo limpio que se vuelve el código del cliente. Deja de preocuparte por la infraestructura.

Como se detalla en la guía sobre uso de la puerta de enlace MCP en un agente, simplemente dirija su cliente MCP al punto final virtual.

Por qué es importante

Estamos pasando de la fase de «chatbot» de la IA a la fase «agencial». En la práctica, esto significa Agentes de LLM ahora dependen de capas de infraestructura como los registros MCP para descubrir herramientas, hacer cumplir los permisos y ejecutar de manera confiable en todos los entornos. En este nuevo mundo, sus API internas son los activos más valiosos que tiene.

Exponerlos de forma segura a las LLM es un problema de infraestructura, no un problema de modelado. Esta es una de las razones MCP frente a RAG importa a la hora de diseñar los flujos de trabajo de los agentes empresariales.

Al tratar el Registro MCP como pieza central de la infraestructura, gestionada a través de los servidores MCP virtuales de TrueFoundry, obtenemos la capacidad de tratar las herramientas como microservicios. Podemos implementarlos, escalarlos, protegerlos y dejarlos obsoletos sin afectar a los agentes que dependen de ellos.

Convierte un montón de scripts de Python en una arquitectura empresarial componible.

‍

‍