MoEngage made 400 internal APIs into agent tools without 20 MCP servers. The key is what each agent never sees

Each tool an agent can call costs about 50 tokens of JSON schema. At MoEngage, that small number became a design constraint: with more than 400 internal API operations, a single tools/list across the whole estate would put over 20,000 tokens into every agent connection before the agent did any work. And most of those tools were ones the agent had no business calling.

MoEngage, a customer engagement platform used by more than 1,350 consumer brands, described how it solved this with AWS in a post published on October 29. It is a good reference for any company with a large estate of private APIs and a growing number of internal agents.

The option it rejected

The obvious path was one MCP server per team. MoEngage’s APIs are built by 25 engineering teams and run in seven AWS regions, so that meant more than 20 MCP servers, each with its own authentication, deployment and drift. The company chose a central Amazon Bedrock AgentCore Gateway instead.

Teams do not write MCP servers at all. They annotate their existing OpenAPI specifications with a small x-moe-mcp block, and CI registers the targets in the gateway and applies Cedar policies. The gateway generates the tools. MoEngage estimates this avoided about six months of platform engineering; it is the company’s estimate.

Four layers, and where the decisions happen

MoEngage's tool path, top to bottom

Agent

• Ten internal agents
• MCP SDK, LangChain, Google ADK, own runner

Sees only the tools it may call

Gateway

• Server-side catalog filtering
• Cedar policy per tool
• Identity injected by the server

Where authorization is decided

Network

• VPC interface endpoint
• VPC Lattice managed egress

No public endpoints

Private APIs

• 400+ operations
• 25 teams, seven regions

Unchanged

Two choices in that stack deserve to be copied.

The catalog is filtered on the server. Each agent receives only the tools its permissions allow. MoEngage is explicit that filtering on the client is not an authorization boundary: an agent that receives the full list and is told to ignore most of it has been given the list. Filtering on the server solves the token problem and the authorization problem with one mechanism.

Identity is injected by the server, never set by the model. The caller’s identity reaches the internal API from the gateway, not from a parameter the model fills in. An agent cannot claim to be someone else by writing a different user ID into a tool call. We made the same argument in enterprise MCP starts with identity; this is what it looks like at 400 tools.

The details that cost time

The post is candid about the friction. AWS SigV4 signing occupies the Authorization header, so a user’s bearer token has to travel in a separate header, and header propagation through the gateway is capped. AgentCore features vary by region, which matters when the APIs live in seven of them. And none of this works without disciplined OpenAPI specs, since the specs are now the source of every tool’s description and schema.

What it means beyond MoEngage

Large companies already own most of the functionality their agents need. It sits in private APIs built over a decade. The work is not to rebuild it as agent tools, but to publish it safely, and three lessons travel well.

The tool catalog is an authorization artifact, so treat it like one: reviewed, versioned and filtered per caller. The central gateway that makes this work becomes one of the most sensitive systems in the company, which is why we argue that AI gateways and MCP servers are tier-zero assets. And the spec annotation pattern puts the decision of what to expose with the team that owns the API, where it belongs.

The token arithmetic made the problem visible at MoEngage. The permission arithmetic is the reason the solution matters everywhere else.