AgentCore Gateway: MoEngage turns 400 private APIs into agent tools
AWS says MoEngage, in a co-written post with its engineers, used Amazon Bedrock AgentCore Gateway to expose roughly 400 internal REST APIs as MCP tools without public exposure, model-controlled identity, or large tool catalogs.
What happened
AWS’s Machine Learning Blog says MoEngage faced a tool-scaling problem common to agent builders: agents needed access to roughly 400 private internal REST APIs, but those APIs stayed behind private VPCs across seven AWS Regions and could not be exposed publicly. The post says Amazon Bedrock AgentCore Gateway is a fully managed MCP server that turns registered OpenAPI specs into MCP tools and routes requests to the backing services. It also says Cedar partial evaluation filters tool visibility before the catalog is serialized, with each agent using its own IAM role. For onboarding, the post says teams add an explicit x-moe-mcp block in the OpenAPI spec; without it, an endpoint is not treated as a tool.
Why it matters
This matters because the post turns a common agent-platform constraint into a concrete architecture choice: keep private APIs private, avoid handing models broad identity power, and prevent tool catalogs from becoming unmanageable. The practical implication is that teams with many internal services can evaluate whether OpenAPI plus policy-scoped tool generation is simpler than building a separate MCP layer.
Engineering impact
For engineering teams, the source supports a workflow where the OpenAPI spec becomes the tool source of truth, exposure is an explicit opt-in, and authorization happens before the tool list is serialized. That can reduce duplicated definitions and client-side filtering, but only for teams already committed to OpenAPI, IAM roles, and Cedar-based policy control.
Leadership impact
For leadership, the article implies an operating model split: product teams own API descriptions, while a platform team owns the protocol, policy, and connectivity layers. That can clarify ownership and lower coordination overhead, but the benefit is limited to organizations able to standardize around that separation across many internal services.
Editorial judgment
This changes a concrete platform decision: whether to build and police MCP tooling per API, or centralize tool generation and authorization around OpenAPI, IAM, and Cedar. The practical value is highest for teams with many private services and strict per-principal access control, but the source remains a company-reported case rather than independent validation.
Watch next
What to watch next is whether the same pattern holds outside this company-reported setup: onboarding friction for adding x-moe-mcp blocks, whether partial evaluation stays manageable as tools grow, and whether search-first agent design remains usable as operations change. The evidence here does not establish broader performance or adoption results.
Limitations & uncertainty
The evidence is limited to an AWS company blog co-written with MoEngage engineers, so it supports the described architecture and workflow but not independent verification of performance, security outcomes, or general applicability.