MoEngage's Engineering Practice: Turning 400 Private APIs into Agent-Discoverable Tools with Cedar Policies and Semantic Search
Customer engagement platform MoEngage faced a common but thorny problem: approximately 400 internal REST APIs were already running in production, but how could AI Agents call them safely? This article details how the four attributes of the AgentCore Gateway correspond to its architectural constraints—automatically generating MCP tools from OpenAPI specifications, filtering tool catalogs by permission via server-side Cedar policies, managing private outbound connections through VPC Lattice, and replacing hardcoded tool references with semantic search—as well as the design decision to pass identity as request headers rather than model parameters.
When engineering teams begin building AI Agents, the capabilities those agents need usually already exist as internal APIs. This was exactly the case for MoEngage: this customer engagement platform serving over 1,350 consumer brands relies on roughly 400 internal REST APIs, maintained by 25 engineering teams and running within private Virtual Private Clouds (VPCs) across seven AWS Regions. The real challenge was not building new functionality, but enabling these APIs to be called safely by Agents without exposing them to the public internet, without giving models control over identity, and without flooding context windows with hundreds of tool definitions.
The initial intuitive approach was for each team to expose its own MCP server. After estimating the costs, MoEngage rejected this: having over 20 MCP servers meant over 20 deployments to monitor, patch, and keep protocol-compatible; cross-domain Agents would need to connect to multiple servers and coordinate between them; and every team would need MCP expertise unrelated to their actual product work. The principle established here ran through all subsequent designs: engineering teams do not implement MCP, they only build REST APIs and declare which operations should be treated as tools; the AI Platform team owns the MCP layer end-to-end; and a team's responsibility ends at writing a good OpenAPI specification.
This principle immediately created three requirements: a central tool surface that Agents connect to just once, server-side authorization enforced by the Agent, and private connectivity that does not need to be rebuilt for every new API. Building a central MCP server from scratch could solve the twenty-servers problem, but it would still require manually building a tool-generation pipeline, policy file formats, alias registries for renames, and circuit breakers—all undifferentiated work for the platform team that would not make MoEngage’s Agents smarter or improve campaign outcomes for customers.
The four attributes of the AgentCore Gateway map precisely to these constraints. First, OpenAPI in, MCP tools out: registering a specification automatically generates tools in the gateway; when the spec changes, the tools change, requiring no deployment or protocol expertise. Second, Cedar policies are evaluated before catalog serialization: the gateway uses partial evaluation to filter the response to tools/list per principal. Each Agent authenticates with its own IAM role, and its policy determines which tools it can see and call. This is what makes 400 tools manageable—not client-side post-hoc filtering, but server-side scoping before the response is built. A campaign QA bot, for example, can only see read-only tools; write operations simply do not appear in its tools/list response.
Third, managed egress via Amazon VPC Lattice: the gateway reaches internal services through AgentCore managed egress, while inbound access is only possible through VPC interface endpoints (private DNS), leaving no public path. Onboarding a new API is merely adding a target, not changing network topology—this breaks the operational explosion caused by multiplying by seven Regions. Fourth, semantic search as a gateway capability: Agents discover tools by describing tasks rather than memorizing tool names. MoEngage’s client library exposes only one meta-tool, search_tools, to the model. The model describes its needs, the gateway returns candidates, and only those candidates become callable for the remainder of the turn. The full catalog never enters the context.
Identity handling is another key design decision. Every internal API call carries tenant, user, role, and database context. If this information were passed as LLM-visible tool parameters, the model might get it wrong or be induced to modify it. MoEngage passes identity as request headers rather than tool parameters: the client library converts the Identity object into headers prefixed with X-MOE-*, which the model cannot see or set. Discovery and execution have different identity requirements—listing and searching tools carry no tenant identity, only tools/call does—keeping discovery lightweight and ensuring an unambiguous audit trail.
The onboarding process is fully automated: teams add an x-moe-mcp block to their existing OpenAPI specification to declare tool descriptions and parameter overrides. Upon push, the CI pipeline validates the declaration, registers the target with the gateway, and applies Cedar policies, requiring no manual steps or tickets to the platform team. MoEngage found that directly reusing API descriptions led to poor tool selection—the model picked tools based on implementation details (e.g., returning paginated lists) rather than intent (e.g., finding campaigns by status or channel). The tool_description and param_overrides fields exist specifically to write model-facing text without altering developer-facing documentation.
It should be noted that this article was co-written by AWS and MoEngage; the estimated saving of six months of engineering effort and the reduction of onboarding time from days to hours are self-estimates by the parties involved, with no independent measurement. The solution is deeply tied to AWS infrastructure (AgentCore, VPC Lattice, SigV4), and cross-cloud portability is not discussed. The rename tolerance brought by semantic search (matching by description rather than identifier) is a practical benefit, but it also means that the quality of tool descriptions directly determines whether an Agent can find the correct tool—a burden requiring continuous maintenance. The search-first mode changed how MoEngage thinks about Agent design: new Agents start with zero hardcoded tool references, describe intent, receive candidates, and call the tools they find; when teams rename operations or release new ones, existing Agents can pick them up without code changes.