MoEngage abre 400 APIs privadas a agentes de IA via AgentCore Gateway, sem servidores MCP próprios

A MoEngage desenvolve a plataforma pela qual mais de 1350 marcas de consumo enviam mensagens personalizadas de push, e-mail, SMS, WhatsApp e RCS. Quando a empresa começou a trabalhar com agentes de IA, percebeu que tudo o que era necessário já funcionava: criação de campanhas, consultas a segmentos, estatísticas de entrega. São cerca de 400 APIs REST internas, escritas por 25 equipes, que ficam em redes de nuvem privadas (VPC) em sete regiões da AWS.

Elas não são expostas externamente por causa de requisitos de armazenamento de dados na região. O desafio era liberar o acesso dos agentes a essas APIs com segurança. A solução foi o gateway gerenciado Amazon Bedrock AgentCore Gateway.

Segundo a MoEngage, ele economizou cerca de seis meses de desenvolvimento de plataforma. Trata-se de uma estimativa interna da empresa, que ninguém verificou de forma independente.

Por que 20 servidores MCP são uma má ideia

MCP (Model Context Protocol) é o padrão pelo qual o agente descobre quais ferramentas tem à disposição e as chama. O caminho óbvio seria cada equipe subir o seu próprio servidor MCP. A MoEngage calculou o que isso significaria:

• mais de 20 deployments para monitorar, atualizar com patches e adaptar à evolução do protocolo; • agentes que precisam de dados de domínios diferentes (a campanha, o segmento dela, as estatísticas de entrega) teriam de se conectar a vários servidores e combinar as respostas; • cada equipe de produto precisaria de conhecimento em MCP, que não tem relação com o trabalho real dela.

Por isso, a regra é: as equipes não escrevem MCP. Elas criam a API REST e marcam quais operações devem ser tratadas como ferramentas. Toda a camada MCP fica com a equipe de AI Platform. A responsabilidade da equipe de produto termina em uma especificação OpenAPI bem escrita.

Para essa regra funcionar, a empresa definiu quatro condições rígidas, que precisam ser atendidas ao mesmo tempo:

• nenhum endereço público: nada de NAT gateways, proxies ou VPN para cada integração, senão multiplicamos o trabalho por sete regiões; • a identidade da chamada não é decisão do modelo: tenant, usuário, papel e contexto do banco de dados não podem ser parâmetros que o modelo consiga alterar por engano ou que possa ser convencido a alterar; • o catálogo de 400 ferramentas não deve entrar no contexto: com cerca de 50 tokens de esquema por ferramenta, a lista completa passa de 20 000 tokens a cada conexão; • filtro no cliente não conta como proteção: se o catálogo já foi entregue, o agente viu o que não devia.

Como o AgentCore Gateway atende a essas condições

O gateway funciona como um servidor MCP totalmente gerenciado. Você registra as especificações OpenAPI como destinos (targets), e ele gera as ferramentas e roteia as chamadas por conta própria. Cada operação recebe um nome no formato Target___operationId, por exemplo CampaignsAPI___searchCampaigns. Se um endpoint é adicionado à especificação, a ferramenta aparece; se é removido, ela some. Sem deploy e sem aprovação da equipe de plataforma.

O acesso é limitado por políticas escritas em Cedar. Cada agente se autentica com a própria função IAM. O mecanismo de políticas seleciona as ferramentas antes mesmo de montar a resposta a tools/list. Um bot de revisão de campanhas, por exemplo, recebe o grupo de ferramentas campaigns-read e uma proibição explícita ao grupo write-actions. As ferramentas de escrita simplesmente não estão na lista dele: não foram enviadas, em vez de ocultadas no cliente.

A conectividade fica por conta de uma saída gerenciada (egress) via Amazon VPC Lattice. O tráfego de entrada passa apenas por um endpoint de interface da VPC com DNS privado. Uma nova API adiciona um destino ao gateway e não altera a topologia de rede. A rede é configurada uma única vez.

Há ainda três decisões que vale a pena copiar:

• SigV4 em vez de JWT: os agentes internos já são serviços com funções IAM, então assinam as requisições com as chaves que já existem, sem emitir nem rotacionar nada novo. O servidor MCP público da MoEngage, usado por pessoas no Claude e em outros clientes, roda à parte com OIDC JWT; • identidade nos cabeçalhos: a biblioteca cliente converte um pequeno objeto Identity em cabeçalhos X-MOE-*. O modelo não os vê.

Como o SigV4 ocupa o cabeçalho Authorization, o bearer token de terceiros é encaminhado em um cabeçalho separado, com prefixo MoEngage; • busca em vez de lista: ao modelo é mostrada uma única metaferramenta, search_tools. O agente descreve a tarefa, a busca semântica do gateway devolve candidatas, e só elas ficam disponíveis para chamada até o fim do turno. Se get_segment_user_count for renomeada para get_segment_size, a busca por significado ainda a encontra.

Conexão de APIs em horas e três meses de experiência em produção

A equipe adiciona à sua especificação o bloco x-moe-mcp. Expor uma operação é um consentimento explícito: sem o bloco, não há ferramenta, e o CI não avisa sobre isso. Os agentes não precisam de aquecimento de cache nem de migrações. Os flags internal e external abrem a operação, de forma independente, para os agentes internos, para o servidor MCP público ou para ambos.

Uma observação à parte: a descrição de uma API escrita para desenvolvedores funciona mal como descrição de ferramenta para o modelo. Quando a MoEngage inseriu «Returns a paginated list» literalmente, os modelos passaram a escolher a ferramenta pelos detalhes de implementação, e não pela intenção. Agora os campos tool_description e param_overrides dão espaço para um texto escrito para o modelo, sem mexer na documentação voltada a pessoas. O resto fica com o CI: ele valida o bloco, registra o destino no gateway e aplica a política Cedar.

Hoje o sistema opera em sete regiões e atende cerca de 400 operações para 10 agentes internos. Entre eles estão o agente de revisão de campanhas (regras de segmentação e conteúdo antes do lançamento), o agente de saúde da entrega (velocidade de envio e picos de bounce por canal) e o construtor de segmentos (transforma a descrição de um público em linguagem natural em uma consulta). Cada um tem seu próprio papel e seu próprio conjunto de ferramentas.

Os novos agentes começam sem nomes de ferramentas fixos no código: descrevem a intenção, recebem candidatas e chamam. Uma renomeação ou uma nova operação é incorporada sem alterar o código. Segundo a empresa, conectar uma nova API agora leva horas, e não dias.

Para engenheiros, a conclusão é esta: se você tem muitas APIs internas, não dê um servidor MCP a cada equipe. Mantenha uma camada única, restrinja o acesso no lado do servidor e não deixe a identidade entre os parâmetros visíveis ao modelo. Ressalva: este é um blog da AWS sobre um produto da AWS, escrito em conjunto com um cliente, e o AgentCore não está disponível em todas as regiões.