A MoEngage tornou 400 APIs em ferramentas de agente sem 20 servidores MCP. A chave é o que cada agente não vê

Cada ferramenta que um agente pode chamar custa cerca de 50 tokens de JSON schema. Na MoEngage, esse número pequeno virou uma restrição de design: com mais de 400 operações de API interna, um único tools/list em todo o parque colocaria mais de 20.000 tokens em cada conexão de agente antes de o agente fazer qualquer trabalho. E a maioria dessas ferramentas era de coisas que o agente não deveria chamar.

A MoEngage, plataforma de engajamento de clientes usada por mais de 1.350 marcas de consumo, descreveu como resolveu isso com a AWS em um post publicado em 29 de outubro. É uma boa referência para qualquer empresa com um grande parque de APIs privadas e um número crescente de agentes internos.

A opção que ela rejeitou

O caminho óbvio era um servidor MCP por time. As APIs da MoEngage são construídas por 25 times de engenharia e rodam em sete regiões da AWS, então isso significava mais de 20 servidores MCP, cada um com sua própria autenticação, deploy e drift. A empresa escolheu um Amazon Bedrock AgentCore Gateway central.

Os times não escrevem servidores MCP. Eles anotam suas especificações OpenAPI existentes com um pequeno bloco x-moe-mcp, e o CI registra os alvos no gateway e aplica políticas Cedar. O gateway gera as ferramentas. A MoEngage estima que isso evitou cerca de seis meses de engenharia de plataforma; é uma estimativa da empresa.

Quatro camadas, e onde as decisões acontecem

O caminho das ferramentas da MoEngage, de cima para baixo

Agente

• Dez agentes internos
• MCP SDK, LangChain, Google ADK, runner próprio

Vê apenas as ferramentas que pode chamar

Gateway

• Filtragem de catálogo no servidor
• Política Cedar por ferramenta
• Identidade injetada pelo servidor

Onde a autorização é decidida

Rede

• Endpoint de interface VPC
• Egress gerenciado do VPC Lattice

Nenhum endpoint público

APIs privadas

• 400+ operações
• 25 times, sete regiões

Inalteradas

Duas escolhas nessa pilha merecem ser copiadas.

O catálogo é filtrado no servidor. Cada agente recebe apenas as ferramentas que suas permissões permitem. A MoEngage é explícita: filtrar no cliente não é uma fronteira de autorização. Um agente que recebe a lista completa e recebe a instrução de ignorar a maior parte dela recebeu a lista. Filtrar no servidor resolve o problema dos tokens e o problema da autorização com um único mecanismo.

A identidade é injetada pelo servidor, nunca definida pelo modelo. A identidade de quem chama chega à API interna pelo gateway, não por um parâmetro que o modelo preenche. Um agente não pode se passar por outra pessoa escrevendo um ID de usuário diferente em uma chamada de ferramenta. Fizemos o mesmo argumento em MCP enterprise começa pela identidade; é assim que isso se parece com 400 ferramentas.

Os detalhes que custam tempo

O post é franco sobre o atrito. A assinatura SigV4 da AWS ocupa o header Authorization, então o bearer token de um usuário precisa viajar em um header separado, e a propagação de headers pelo gateway tem limite. Os recursos do AgentCore variam por região, o que importa quando as APIs vivem em sete delas. E nada disso funciona sem especificações OpenAPI disciplinadas, já que as specs agora são a fonte da descrição e do schema de cada ferramenta.

O que isso significa além da MoEngage

Grandes empresas já são donas da maior parte da funcionalidade de que seus agentes precisam. Ela está em APIs privadas construídas ao longo de uma década. O trabalho não é reconstruí-la como ferramentas de agente, mas publicá-la com segurança, e três lições viajam bem.

O catálogo de ferramentas é um artefato de autorização, então trate-o como tal: revisado, versionado e filtrado por quem chama. O gateway central que faz isso funcionar se torna um dos sistemas mais sensíveis da empresa, e é por isso que defendemos que gateways de IA e servidores MCP são ativos tier-zero. E o padrão de anotação de specs coloca a decisão do que expor com o time que é dono da API, onde ela pertence.

A aritmética dos tokens tornou o problema visível na MoEngage. A aritmética das permissões é a razão pela qual a solução importa em todos os outros lugares.