MoEngage Opens 400 Private APIs to AI Agents Through AgentCore Gateway, Without Building Its Own MCP Servers

MoEngage, a messaging platform for 1350+ brands, wanted to give AI agents access to roughly 400 internal REST APIs. The APIs sit inside private networks across seven AWS regions. Instead of building 20+ MCP servers of its own (MCP is the protocol agents use to discover and call tools), the company chose Amazon's managed AgentCore Gateway, which turns OpenAPI descriptions into tools automatically. Each agent signs in under its own IAM role, and Cedar policies on the gateway side decide which tools it can see at all. Customer and user identity travel in headers; the model neither sees nor changes them. Instead of a 20,000+ token catalog, the agent is shown a single search tool. • By the company's estimate, the platform team saved about six months of work. • Connecting a new API takes hours instead of days. • In production for three months: 10 internal agents, 7 regions.

AI-processed from AWS Machine Learning Blog; edited by Hamidun News
MoEngage Opens 400 Private APIs to AI Agents Through AgentCore Gateway, Without Building Its Own MCP Servers
Source: AWS Machine Learning Blog. Collage: Hamidun News.
Listen to article
Article Fact Sheet & Key Figures
ParameterDetails
Primary sourceAWS Machine Learning Blog ↗
Editor-in-Chief
Key metric #1By the company's estimate, the platform team saved about six months of work.
Key metric #2Connecting a new API takes hours instead of days.
In production for three months10 internal agents, 7 regions.

MoEngage builds a platform that more than 1350 consumer brands use to send personalized push, email, SMS, WhatsApp and RCS messages. When the company started work on AI agents, it found that everything it needed already existed: campaign creation, segment queries, delivery statistics. That is about 400 internal REST APIs, written by 25 teams and running in private cloud networks (VPCs) across seven AWS regions. They are not exposed externally because of data-residency requirements. The task was to let agents reach them safely. The solution was the managed Amazon Bedrock AgentCore Gateway. By MoEngage's estimate, it saved about six months of platform development. That is the company's internal estimate; no one has verified it independently.

Why 20 MCP servers is a bad idea

MCP (Model Context Protocol) is the standard agents use to learn which tools they have and to call them. The obvious path is for each team to run its own MCP server. MoEngage worked out what that would cost:

• more than 20 deployments to monitor, patch and keep in step with the evolving protocol; • agents that need data from several domains (a campaign, its segment, delivery statistics) would have to connect to multiple servers and merge the responses; • every product team would need MCP expertise unrelated to its actual work.

Hence the rule: teams do not write MCP. They build a REST API and mark which operations should count as tools. The AI Platform team runs the entire MCP layer. A product team's responsibility ends with a well-written OpenAPI specification.

From that rule, the company derived four hard requirements that must all hold at once:

• no public endpoints: no NAT gateways, no proxies, no VPN per integration, otherwise the work is multiplied by seven regions; • call identity is not the model's decision: tenant, user, role and database context cannot be parameters that the model could change by mistake or be talked into changing; • a catalog of 400 tools must not land in the context window: at roughly 50 schema tokens per tool, the full list is over 20,000 tokens on every connection; • client-side filtering does not count as protection: if the catalog has already been sent, the agent has seen too much.

How AgentCore Gateway meets these requirements

The gateway works as a fully managed MCP server. You register OpenAPI specifications as targets, and it generates the tools and routes the calls itself. Each operation gets a name in the form Target___operationId, for example CampaignsAPI___searchCampaigns. Add an endpoint to the specification and the tool appears; remove it and the tool disappears. No deployment and no sign-off from the platform team.

Access is restricted with policies written in Cedar. Each agent authenticates under its own IAM role. The policy engine filters the tools before the tools/list response is built. A campaign-review bot, for example, gets the campaigns-read tool group and an explicit deny on the write-actions group. Write tools are simply absent from its list: they were never sent, rather than hidden on the client.

Connectivity comes from managed egress through Amazon VPC Lattice. Inbound traffic goes only through a VPC interface endpoint with private DNS. A new API adds a target to the gateway and does not change the network topology. The network is configured once.

Three more decisions worth copying:

• SigV4 instead of JWT: internal agents are already services with IAM roles, so they sign requests with the keys they already have, and nothing new needs to be issued or rotated. MoEngage's public MCP server for people using Claude and other clients runs separately on OIDC JWT; • identity in headers: a client library turns a small Identity object into X-MOE-* headers. The model does not see them.

Because SigV4 occupies the Authorization header, a third-party bearer token is forwarded in a separate header with a MoEngage prefix; • search instead of a list: the model is shown a single meta-tool, search_tools. The agent describes the task, the gateway's semantic search returns candidates, and only those become callable for the rest of the turn. If get_segment_user_count is renamed get_segment_size, semantic search will still find it.

Connecting an API in hours, and three months in production

A team adds an x-moe-mcp block to its specification. Exposing an API externally is an explicit opt-in: no block, no tool, and CI does not warn about it. Agents need no cache warm-up or migrations. The internal and external flags independently open an operation to internal agents, the public MCP server, or both.

One separate observation: an API description written for developers works poorly as a tool description for a model. When MoEngage pasted "Returns a paginated list" verbatim, models chose tools based on implementation details rather than intent. Now the tool_description and param_overrides fields provide space for text written for the model, without touching the documentation for humans. CI does the rest: it validates the block, registers the target in the gateway and applies the Cedar policy.

The system now runs in seven regions and serves about 400 operations for 10 internal agents. They include a campaign-review agent (targeting rules and content before launch), a delivery-health agent (send rate and bounce spikes by channel) and a segment builder (turns a natural-language audience description into a query). Each has its own role and its own set of tools. New agents start without hard-coded tool names: they describe the intent, get candidates and make the call. A rename or a new operation is picked up without code changes. According to the company, connecting a new API now takes hours instead of days.

The takeaway for engineers: if you have many internal APIs, do not hand each team an MCP server. Keep a single layer, restrict access on the server side, and keep identity out of parameters the model can see. A caveat: this is an AWS blog about an AWS product, written together with a customer, and AgentCore is not available in all regions.

Story

Key Questions Answered

Why 20 MCP servers is a bad idea?

MCP (Model Context Protocol) is the standard agents use to learn which tools they have and to call them. The obvious path is for each team to run its own MCP server. MoEngage worked out what that would cost: more than 20 deployments to monitor, patch and keep in step with the evolving protocol; agents that need data from several domains (a campaign, its segment, delivery statistics) would have to connect to multiple servers and merge the responses; every product team would need MCP expertise unrelated to its actual work. Hence the rule: teams do not write MCP. They build a

How AgentCore Gateway meets these requirements?

The gateway works as a fully managed MCP server. You register OpenAPI specifications as targets, and it generates the tools and routes the calls itself. Each operation gets a name in the form Target___operationId, for example CampaignsAPI___searchCampaigns. Add an endpoint to the specification and the tool appears; remove it and the tool disappears. No deployment and no sign-off from the platform team. Access is restricted with policies written in Cedar. Each agent authenticates under its own IAM role. The policy engine filters the tools before the tools/list response is bu

What are the key details on Connecting an API in hours, and three months in production?

A team adds an x-moe-mcp block to its specification. Exposing an API externally is an explicit opt-in: no block, no tool, and CI does not warn about it. Agents need no cache warm-up or migrations. The internal and external flags independently open an operation to internal agents, the public MCP server, or both. One separate observation: an API description written for developers works poorly as a tool description for a model. When MoEngage pasted "Returns a paginated list" verbatim, models chose tools based on implementation details rather than intent. Now the tool_descripti

ZK
Zhemal Khamidun — CPO at Alpina Digital, product manager of AlpinaGPT. Building AI products since 2019. Hamidun News is a pet project that grew into a production aggregator with 6,000+ readers.
✦ Autonomous AI Execution · Nomad Agent

Delegate Deep Research, Coding & Multi-Step Workflows to Nomad Agent

Deploy autonomous task execution with Nomad Agent (agent.nomadnet.ai) — automated web research, data synthesis, code generation, and MCP tool orchestration.

Launch Nomad Agent →Nomad AI Workspace
What do you think?
Loading comments…