MoEngage: 400 private APIs become agent tools via AgentCore Gateway

AWS published a customer write-up on 29 October 2026 in which engineers from MoEngage, a customer engagement platform used by more than 1,350 consumer brands, describe how they made about 400 internal APIs callable by AI agents. The post says the system has run in production for three months and serves 10 internal agents across seven AWS Regions. Four authors wrote it, two from MoEngage and two from AWS, so it is vendor-published.

The problem

The APIs were built by 25 engineering teams and sit in private virtual private clouds (VPCs) in seven Regions, isolated regionally to meet data residency commitments. MoEngage set four constraints: no public endpoints, identity that a model cannot decide, a tool catalogue that does not swamp the context window, and one place for agents to connect. The post puts a full tool listing at over 20,000 tokens, at roughly 50 tokens of schema per tool, sent on every connection.

MoEngage rejected one Model Context Protocol (MCP) server per team, which would have meant more than 20 servers to patch and monitor. It also rejected building its own central server, which it says would have meant writing a tool-generation pipeline, a policy format and a rename registry. Its rule instead: product teams own REST APIs and an OpenAPI spec, and the AI Platform team owns everything MCP.

How it works

AgentCore Gateway, a managed MCP server in Amazon Bedrock AgentCore, turns each OpenAPI operation into a tool. Each agent authenticates as its own IAM role, using SigV4 request signing with credentials the service already has. A Cedar policy then filters the tool list per agent before it is sent, so a campaign QA bot gets read tools and never sees write tools. The post contrasts this with client-side filtering, which it says is not an authorisation boundary because the full catalogue has already crossed the wire.

Tenant, user, role and database context travel as X-MOE-* headers added by the client library, not as tool arguments, so the model cannot set or override them. Calls reach the internal services over Amazon VPC Lattice managed egress. A single search_tools meta-tool lets an agent describe a task and receive a handful of matching tools, so the context holds one definition at the start rather than hundreds.

What they learned

Exposure is opt-in: an endpoint with no x-moe-mcp block in its spec is not a tool, which keeps cache-warmup routes and migration triggers away from agents. MoEngage also reports that copying API descriptions verbatim led to poor tool selection, because models chose by implementation detail, such as "returns a paginated list", rather than intent. Teams now write a separate tool_description and parameter text. The CI pipeline validates the block, registers the target and applies the Cedar policy with no ticket to the platform team.

What the post leaves out

MoEngage estimates the approach saved about six months of engineering effort and says onboarding a new API takes hours instead of days. These are estimates, not measurements. The post gives no gateway cost, added latency, tool-call error rate, or evidence that agents choose the right tool from a search, and it names the agents but not the models behind them. It also notes that AgentCore feature availability varies by Region, which matters for a seven-Region design.

What a team can take from it

Three choices travel beyond AWS: keep identity out of model-visible parameters, scope each agent's tool list on the server, and make exposing an endpoint a deliberate act. If you run MCP servers per team today, count them and what each costs to patch before deciding whether to centralise.