AgentCore Gateway is a managed service that can turn registered OpenAPI operations into Model Context Protocol (MCP) tools. AWS’s co-written account with MoEngage describes the company using it to give 10 internal agents permission-scoped access to roughly 400 registered operations. The design separates declaring tools, deciding which agents can use them, and routing requests to internal APIs.
How MoEngage turns APIs into agent tools
MoEngage teams annotate existing OpenAPI specifications with x-moe-mcp. OpenAPI describes how an API works; AgentCore Gateway registers those specifications and generates MCP tools from their operations. A continuous integration (CI) pipeline validates the annotation, registers the target and applies the relevant Cedar policy.
That lets teams expose selected API operations as tools without building a separate MCP server for each API. The account describes internal agents handling campaign checks before launch, delivery-health monitoring and natural-language audience-segment building. MoEngage’s client library can plug into LangChain, Google ADK and other MCP-compatible frameworks, or run through a separate agent-runner mode.
The reported scale has two distinct counts: MoEngage’s internal estate comprises roughly 400 REST APIs, while the gateway serves roughly 400 registered operations. The APIs were built by 25 engineering teams across seven AWS Regions.
How permissions and identity are separated
Each internal agent uses its own AWS Identity and Access Management (IAM) role. Cedar policies tied to the agent’s principal determine which tools it can see and call. The gateway evaluates those policies on the server, before returning the permitted tool list. In the account’s campaign-quality example, an agent can use campaign-reading tools while write actions are forbidden.
Tenant, user, role and database context travels in MoEngage-prefixed X-MOE-* headers, rather than as model-editable tool arguments. The account distinguishes the stages: tool listing and semantic search do not carry tenant identity, while a tools/call request does.
For the internal gateway, agents sign requests with SigV4, using their IAM roles. MoEngage’s separate public MCP service uses OIDC JSON Web Tokens (JWTs) on AgentCore Runtime. Those are different authentication setups for different services.
How requests reach private APIs
The described internal path begins with an agent connecting over HTTPS to a VPC interface endpoint with private DNS. AgentCore Gateway then uses managed egress through Amazon VPC Lattice to reach MoEngage’s internal APIs. The account describes no public endpoint in this path.
This keeps network routing distinct from tool authorization: VPC connectivity carries requests to the services, while IAM roles and Cedar policies govern which tools an agent may access. The account describes MoEngage’s implementation; it does not make the same design a fit for every deployment.
How agents find the right tools
Rather than loading the full catalog into an agent’s context, the client library offers a search_tools meta-tool. The agent can describe a task, and semantic search returns candidate tools relevant to it. MoEngage’s account estimates a tool’s JSON schema at roughly 50 tokens and a catalog of 400 tools at more than 20,000 tokens. Those are approximate context-size figures, not a response-time measurement.
The distinction matters when interpreting the reported efficiency gains. MoEngage estimates that avoiding more than 20 separately operated MCP servers and per-API network provisioning saved about six months of platform-engineering effort. The company also says onboarding a new API takes hours rather than days. That comparison concerns API onboarding, not how quickly an agent answers a request.
