MoEngage convirtió 400 API internas en herramientas de agente sin 20 servidores MCP
MoEngage expuso más de 400 operaciones de API privadas a diez agentes internos con AgentCore Gateway y filtrado por permisos en el servidor.
Escuche este artículo · 4 min
Narración completa del artículo, generada con IA.
Cada herramienta que un agente puede invocar cuesta unos 50 tokens de esquema JSON. En MoEngage, ese número pequeño se convirtió en una restricción de diseño: con más de 400 operaciones de API internas, un solo tools/list sobre todo el conjunto metería más de 20.000 tokens en cada conexión de agente antes de que el agente hiciera nada. Y la mayoría de esas herramientas eran cosas que el agente no tenía por qué llamar.
MoEngage, una plataforma de engagement de clientes usada por más de 1.350 marcas de consumo, describió cómo lo resolvió con AWS en un post publicado el 29 de octubre. Es una buena referencia para cualquier empresa con un gran conjunto de API privadas y un número creciente de agentes internos.
La opción que descartó
El camino obvio era un servidor MCP por equipo. Las API de MoEngage las construyen 25 equipos de ingeniería y corren en siete regiones de AWS, así que eso significaba más de 20 servidores MCP, cada uno con su propia autenticación, despliegue y deriva. La empresa eligió en su lugar un Amazon Bedrock AgentCore Gateway central.
Los equipos no escriben servidores MCP en absoluto. Anotan sus especificaciones OpenAPI existentes con un pequeño bloque x-moe-mcp, y el CI registra los targets en el gateway y aplica políticas Cedar. El gateway genera las herramientas. MoEngage estima que esto evitó unos seis meses de ingeniería de plataforma; es una estimación de la empresa.
Cuatro capas, y dónde se toman las decisiones
La ruta de las herramientas en MoEngage, de arriba abajo
Agente
- Diez agentes internos
- MCP SDK, LangChain, Google ADK, runner propio
Solo ve las herramientas que puede invocar
Gateway
- Filtrado del catálogo en el servidor
- Política Cedar por herramienta
- Identidad inyectada por el servidor
Donde se decide la autorización
Red
- Endpoint de interfaz de VPC
- Salida gestionada con VPC Lattice
Sin endpoints públicos
API privadas
- Más de 400 operaciones
- 25 equipos, siete regiones
Sin cambios
Dos decisiones de esa arquitectura merecen copiarse.
El catálogo se filtra en el servidor. Cada agente recibe solo las herramientas que sus permisos permiten. MoEngage es explícito en que filtrar en el cliente no es una frontera de autorización: a un agente que recibe la lista completa y se le dice que ignore casi toda se le ha entregado la lista. Filtrar en el servidor resuelve el problema de los tokens y el de la autorización con un solo mecanismo.
La identidad la inyecta el servidor, nunca la fija el modelo. La identidad de quien llama llega a la API interna desde el gateway, no desde un parámetro que rellena el modelo. Un agente no puede hacerse pasar por otra persona escribiendo otro user ID en una llamada a herramienta. Hicimos el mismo argumento en MCP empresarial empieza por la identidad; esto es cómo se ve con 400 herramientas.
Los detalles que cuestan tiempo
El post es sincero sobre la fricción. La firma SigV4 de AWS ocupa la cabecera Authorization, así que el token bearer de un usuario tiene que viajar en otra cabecera, y la propagación de cabeceras a través del gateway tiene un límite. Las funciones de AgentCore varían por región, lo que importa cuando las API viven en siete de ellas. Y nada de esto funciona sin especificaciones OpenAPI disciplinadas, porque las especificaciones son ahora la fuente de la descripción y el esquema de cada herramienta.
Qué significa más allá de MoEngage
Las grandes empresas ya son dueñas de casi toda la funcionalidad que necesitan sus agentes. Está en API privadas construidas a lo largo de una década. El trabajo no es rehacerlas como herramientas de agente, sino publicarlas de forma segura, y hay tres lecciones que viajan bien.
El catálogo de herramientas es un artefacto de autorización, así que trátelo como tal: revisado, versionado y filtrado por quien llama. El gateway central que lo hace posible se convierte en uno de los sistemas más sensibles de la empresa, y por eso sostenemos que los gateways de IA y los servidores MCP son activos de nivel cero. Y el patrón de anotar las especificaciones deja la decisión de qué exponer en el equipo dueño de la API, que es donde corresponde.
La aritmética de tokens hizo visible el problema en MoEngage. La aritmética de permisos es la razón por la que la solución importa en todos los demás sitios.