MoEngage moved from dozens of custom MCP servers to a centrally managed AgentCore Gateway, allowing hundreds of private REST APIs to be accessed by AI agents without exposing them to the internet. Practitioners care because the change cuts platform‑engineering time, simplifies networking, and enforces per‑agent authorization at the server level.
Why a fleet of MCP servers didn’t work
Each engineering team could have published its own MCP server, but that would have meant over 20 independent deployments to monitor, patch, and keep compatible as the protocol evolves. Agents that needed to call multiple services would have to stitch together responses from several servers, and every team would have to acquire MCP expertise unrelated to its core product work. The resulting operational surface was deemed unsustainable.
Four constraints that guided the solution
- No public endpoints. All internal APIs are confined to VPCs across seven AWS Regions to satisfy data‑residency policies. Any approach requiring a public URL, even with extra authentication, was rejected.
- Identity must be injected, not supplied by the model. Calls to internal services carry tenant, user, role, and database context. Allowing the LLM to set these values could lead to incorrect or malicious context.
- Tool catalog size exceeds context windows. With roughly 400 APIs, a full
tools/listpayload would be over 20,000 tokens, consuming the model’s token budget before any useful work begins. - Centralized authorization. Per‑agent permissions need to be enforced server‑side rather than relying on client‑side conventions.
How AgentCore Gateway satisfies the constraints
Amazon Bedrock AgentCore Gateway is a fully managed MCP server. Teams register their OpenAPI specifications as targets; the gateway automatically generates MCP tool definitions and routes calls to the private services. Because the gateway runs inside the VPC, no public endpoint is created. Identity information is supplied by the calling service, keeping it out of the model’s prompt. The gateway can filter the tool list per agent, so only the authorized subset traverses the model’s context window. This eliminates the need for each team to build and maintain its own MCP server, tool‑generation pipeline, or custom policy format.
Operational and security implications
From an operations perspective, the shift consolidates monitoring and patching to a single managed service, reducing the engineering headcount required for MCP maintenance. Network changes are limited to the initial VPC integration of the gateway; adding a new API only requires updating an OpenAPI spec, not provisioning new NAT gateways or VPN tunnels. Security benefits include the removal of public exposure for all internal APIs and the enforcement of per‑agent authorization at the gateway layer, which aligns with MoEngage’s data‑residency commitments. Identity handling remains under the control of the platform, mitigating the risk of model‑driven credential misuse.
Related CloudNinjas coverage: AWS.
What This Means For Practitioners
Teams building AI‑enabled platforms should evaluate whether a managed MCP service like AgentCore Gateway can replace custom tool‑exposure layers. Key evaluation points include: ability to register existing OpenAPI specs, support for VPC‑only deployment, and server‑side per‑agent authorization. If those capabilities match your constraints, you can expect faster onboarding of new APIs, reduced operational overhead, and a tighter security posture without introducing public endpoints.