MoEngage abre 400 API cerradas a agentes de IA con AgentCore Gateway, sin servidores MCP propios

MoEngage desarrolla una plataforma con la que más de 1350 marcas de consumo envían mensajes personalizados por push, email, SMS, WhatsApp y RCS. Cuando la compañía empezó a trabajar con agentes de IA, comprobó que todo lo necesario ya funcionaba: creación de campañas, consultas a segmentos y estadísticas de entrega. Son unas 400 API REST internas, escritas por 25 equipos, que viven en redes cloud privadas (VPC) de siete regiones de AWS.

No se exponen al exterior por los requisitos de almacenamiento de datos en la región. El reto era permitir el acceso de los agentes de forma segura. La solución fue Amazon Bedrock AgentCore Gateway, un gateway gestionado.

Según MoEngage, le ahorró unos seis meses de desarrollo de plataforma. Es una estimación interna de la compañía y nadie la ha verificado de forma independiente.

Por qué 20 servidores MCP son una mala idea

MCP (Model Context Protocol) es el estándar con el que un agente descubre qué herramientas tiene y las invoca. El camino obvio es que cada equipo levante su propio servidor MCP. MoEngage calculó lo que eso implicaría:

• más de 20 despliegues que habría que monitorizar, parchear y adaptar a la evolución del protocolo; • los agentes que necesiten datos de varios dominios (una campaña, su segmento, las estadísticas de entrega) tendrían que conectarse a varios servidores y combinar las respuestas; • cada equipo de producto necesitaría una experiencia en MCP ajena a su trabajo real.

De ahí la regla: los equipos no escriben MCP. Hacen su API REST y marcan qué operaciones deben considerarse herramientas. Toda la capa MCP la lleva el equipo de AI Platform. La responsabilidad del equipo de producto termina en una especificación OpenAPI bien escrita.

A partir de esa regla, la compañía fijó cuatro condiciones estrictas que deben cumplirse a la vez:

• sin direcciones públicas: ni gateways NAT, ni proxies, ni VPN por cada integración, porque habría que multiplicarlo por siete regiones; • la identidad de la llamada no la decide el modelo: el tenant, el usuario, el rol y el contexto de la base de datos no pueden ser parámetros que el modelo pueda cambiar por error o que se le pueda convencer de modificar; • el catálogo de 400 herramientas no debe entrar en el contexto: con unos 50 tokens de esquema por herramienta, la lista completa supone más de 20 000 tokens en cada conexión; • un filtro en el cliente no cuenta como protección: si el catálogo ya se ha enviado, el agente ha visto más de lo debido.

Cómo AgentCore Gateway cumple estas condiciones

El gateway funciona como un servidor MCP totalmente gestionado. Se registran las especificaciones OpenAPI como destinos (targets) y él genera las herramientas y enruta las llamadas. Cada operación recibe un nombre con el formato Target___operationId, por ejemplo CampaignsAPI___searchCampaigns. Si se añade un endpoint a la especificación, aparece la herramienta; si se quita, desaparece. Sin despliegues ni aprobaciones del equipo de plataforma.

El acceso se limita con políticas en lenguaje Cedar. Cada agente se autentica con su propio rol de IAM. El motor de políticas selecciona las herramientas antes de componer la respuesta a tools/list. Un bot de revisión de campañas, por ejemplo, recibe el grupo de herramientas campaigns-read y una prohibición explícita sobre el grupo write-actions. Las herramientas de escritura simplemente no están en su lista: no se envían, en lugar de ocultarse en el cliente.

La conectividad la aporta una salida (egress) gestionada a través de Amazon VPC Lattice. El tráfico entrante pasa solo por un punto de conexión de interfaz de VPC con DNS privado. Para añadir una API nueva basta con registrar un destino en el gateway, sin cambiar la topología de red. La red se configura una sola vez.

Hay otras tres decisiones que merece la pena copiar:

• SigV4 en lugar de JWT: los agentes internos ya son servicios con roles de IAM, así que firman las peticiones con las claves que ya tienen y no hay que emitir ni rotar nada nuevo. El servidor MCP público de MoEngage, pensado para personas que usan Claude y otros clientes, funciona aparte con OIDC JWT; • identidad en cabeceras: la biblioteca cliente convierte un pequeño objeto Identity en cabeceras X-MOE-*. El modelo no las ve.

Como SigV4 ocupa la cabecera Authorization, el bearer token de un tercero se reenvía en una cabecera aparte con el prefijo MoEngage; • búsqueda en lugar de lista: al modelo se le muestra una sola metaherramienta, search_tools. El agente describe la tarea, la búsqueda semántica del gateway devuelve candidatos y solo ellos pasan a ser invocables hasta el final del turno. Si get_segment_user_count se renombra a get_segment_size, la búsqueda por significado seguirá encontrándola.

Conectar una API en horas y tres meses de experiencia en producción

El equipo añade a su especificación un bloque x-moe-mcp. Exponer una operación al exterior requiere consentimiento explícito: si no hay bloque, no hay herramienta, y el CI no avisa de ello. Los agentes no necesitan calentamiento de caché ni migraciones. Los flags internal y external abren la operación de forma independiente a los agentes internos, al servidor MCP público o a ambos.

Una observación aparte: la descripción de una API pensada para desarrolladores funciona mal como descripción de herramienta para un modelo. Cuando MoEngage pegaba literalmente «Returns a paginated list», los modelos elegían la herramienta por detalles de implementación y no por la intención. Ahora los campos tool_description y param_overrides reservan un espacio para texto escrito para el modelo, sin tocar la documentación para personas. De lo demás se encarga el CI: valida el bloque, registra el destino en el gateway y aplica la política Cedar.

Hoy el sistema opera en siete regiones y sirve unas 400 operaciones a 10 agentes internos. Entre ellos hay un agente de revisión de campañas (reglas de segmentación y contenido antes del lanzamiento), un agente de salud de la entrega (velocidad de envío y picos de bounce por canal) y un constructor de segmentos (convierte una descripción de audiencia en lenguaje natural en una consulta). Cada uno tiene su propio rol y su propio conjunto de herramientas.

Los agentes nuevos arrancan sin nombres de herramientas fijados en el código: describen la intención, reciben candidatos y los invocan. Un cambio de nombre o una operación nueva se incorporan sin tocar código. Según la compañía, conectar una API nueva ahora lleva horas en lugar de días.

La conclusión para los ingenieros: si tienen muchas API internas, no den a cada equipo su servidor MCP. Mantengan una capa única, limiten el acceso en el servidor y no dejen que la identidad viaje en parámetros visibles para el modelo. Una salvedad: es un blog de AWS sobre un producto de AWS, escrito junto con un cliente, y AgentCore no está disponible en todas las regiones.