Integration
Put the MCP Server Behind Your API Gateway, Not in Front of It
A common first diagram for giving AI agents access to a company’s systems looks like this: the agent connects to a new MCP server, and the MCP server calls the API gateway, or goes around it. It looks tidy. It also means the newest and least predictable consumer of your APIs arrives through a door with no throttle, no quota and no meter on it.
The short answer: put the MCP server behind your API gateway, not in front of it. Treat it as one more interface to your APIs. Agents reach the MCP server through the gateway. The MCP server’s own calls to your APIs go back through the gateway’s policies. Partners who write ordinary code call the same APIs through the same gateway. One policy point governs both paths, so agent traffic is throttled, metered, logged and billable exactly like everything else.
What an MCP Server Is, Briefly
The Model Context Protocol (MCP) is an open protocol for connecting AI applications to outside systems (MCP specification). An MCP server exposes tools: named operations a language model can discover and call, each described by a JSON Schema for its inputs (MCP tools). The agent might be a commercial assistant, a partner’s own model working over its own documents, or something your team builds.
When an MCP server is a translation layer over APIs you already have, as it often is, placement decides who governs it. “Look up an order” becomes a tool, and the tool calls the orders API. The MCP server is not a new system of record. It is a new front door to the old ones.
Where the MCP Server Belongs in an API Gateway Architecture
Every request should cross the gateway before it touches anything else. Here is the path for each kind of caller:
| Caller | Enters at | What happens next |
|---|---|---|
| An AI agent, yours or a partner’s | The gateway, on the MCP server’s route | The gateway applies that agent consumer’s policies, then forwards to the MCP server |
| The MCP server, calling your APIs | The gateway, on each API’s route | The gateway applies the MCP server’s policies as a caller, then forwards to the API |
| A partner’s application written in ordinary code | The gateway, on each API’s route | The gateway applies that partner’s policies, then forwards to the API |
| Anyone, directly | Nowhere | Neither the MCP server nor the APIs accept traffic that did not come through the gateway |
Now consider the other drawing, with the MCP server in front. The gateway sees one caller, the MCP server, making every request. It cannot tell which agent or which partner drove a call, so it cannot slow one runaway agent without slowing all of them, cannot meter usage per partner, and has no record to bill against. If the MCP server can also reach the APIs without crossing the gateway, agent traffic is not counted anywhere.
Some gateways can host the MCP endpoint themselves. Azure API Management, for example, can expose operations of a REST API it already manages as MCP tools, and the policies configured for that MCP server apply to every tool it exposes; Microsoft’s own example adds a rate limit per client IP address (Microsoft Learn). Whether the gateway hosts the endpoint or a separate service does, the rule holds: agent traffic crosses the policy point first.
What the Gateway Does That the MCP Server Should Not
The MCP specification says servers must rate limit tool invocations (MCP tools, security considerations). You could build that into every MCP server. The better place is the gateway, which already does it for your other consumers and does it the same way for all of them.
| Concern | What the gateway does | Why it matters for agents |
|---|---|---|
| Throttling | Caps each consumer’s call rate, for example 120 calls a minute per key | An agent retrying in a loop calls faster than any person can. One misbehaving caller should be slowed, not everyone |
| Quotas and tiers | Enforces an allowance per consumer over a renewal period; Azure API Management’s quota policy counts calls or bandwidth per key and refuses the excess (Microsoft Learn) | Agent access becomes a product with tiers: a plan that includes 50,000 calls a month, with charges beyond it |
| Logging and metering | Records every call against the consumer that made it | That record is both the invoice and the audit trail |
| Protection | Rejects traffic over the limit before it reaches the backend | Poorly written partner code, human or model-driven, can behave like a denial-of-service attack on your own API |
The numbers in that table are examples of settings, not recommendations. The point is where they live: in one place, applied to every consumer, rather than reimplemented in each MCP server you build. API management for AI agents is mostly the API management you already run, applied to a new kind of consumer.
What the MCP server should own is the translation: turning a tool call into the right API calls, and shaping the response into something a model can use.
Two Interface Paths, One Policy Point
Some partners will want agent access. They are connecting a commercial assistant, or their own model with retrieval over their own data, and they want tools. Others will write code against your API specification as they always have. You do not have to choose. Offer both through the same gateway, and a partner who moves from code to agents keeps the same subscription, the same limits and the same invoice.
Route the MCP server’s own API calls back through the gateway too, rather than straight to the backend. It costs a network hop. It buys one place where every call to an API is counted, whichever interface the consumer chose. We think that trade is worth making in almost every case.
Identity works in your favor here. MCP’s authorization specification treats a protected MCP server as an OAuth 2.1 resource server and forbids it from passing the token it received on to the APIs behind it; calls to those APIs use a separate token (MCP authorization). So the agent’s call and the MCP server’s call arrive at the gateway as two distinct, identifiable consumers, and each gets its own policy.
API Catalog vs API Gateway
These get confused because both list your APIs. They do different jobs.
An API catalog is a design-time inventory: what APIs and MCP servers exist, who owns them, which versions are live, and how to find them. Azure API Center, for example, can register MCP servers alongside APIs so developers can search and test them in one portal (Microsoft Learn). Its value is that the next team finds the MCP server you already built instead of writing a second one over the same API.
An API gateway is runtime enforcement on every request: authentication, throttling, quotas, logging. A catalog entry that says “rate limited” does not rate limit anything. You want both, and neither substitutes for the other.
Decisions to Make Before You Draw the Diagram
- Will partner agents connect to your gateway directly, or only through an assistant you host? Direct connections mean each partner needs its own credentials, limits and tier from the start.
- Will raw APIs ever be exposed to partners, or only the MCP layer? An MCP-only offering is simpler to govern, but the partner who codes traditionally will ask for the API, and it is easier to plan for that path than to add it later.
- How coarse are the tools? One tool per API operation is fast to ship. In our judgment, a model usually does better with fewer, task-shaped tools.
- How large are your API specifications? Gateways have import limits. Azure API Management caps an OpenAPI document imported inline at 4 MB and does not support recursively defined schemas (Microsoft Learn). If your APIs implement a large standard such as FHIR, plan to import the resources you actually expose rather than the whole specification (our HL7, FHIR and X12 integration guide covers the standards themselves).
- Who owns the tool descriptions? A model reads them to decide what to call, so they are part of the interface contract, not documentation to write at the end.
Ship the MCP Server Over the APIs You Already Have
If your partners already work with agents, they will not want to wait for your redesigned API. An MCP server over the APIs you have, legacy ones included, gives them something useful while the better APIs are built. It is the same move we recommend for modernizing legacy systems without a rewrite: put a clean interface in front of the old system and change what is behind it over time.
Placement is what makes that safe. Because the MCP server sits behind the gateway, replacing an API underneath it later changes nothing for the agent, the limits or the bill. The tool layer is also where you absorb an older API’s rough edges, such as responses carrying far more than a model needs, or one task that takes three calls, without touching the backend.
Frequently Asked Questions
Should an MCP server sit in front of or behind the API gateway?
Behind it. Agents reach the MCP server through the gateway, and the MCP server’s calls to your APIs go back through the gateway, so every consumer is throttled, metered and logged at one policy point.
Can the API gateway host the MCP server itself?
Some can. Azure API Management can expose operations of a REST API it manages as MCP tools and apply its policies to them. For servers built that way, Microsoft documents tool support but not MCP resources or prompts, so check the limits against what your agents need.
Is an API catalog the same as an API gateway?
No. A catalog is an inventory that helps people find and reuse APIs and MCP servers. A gateway enforces policy on every live request. You need both.
Where to Start
If you are drawing this diagram, start with two questions: where the gateway sits, and which consumers it has to tell apart. See how we take AI implementation into production under your IT governance, how we work as an engineering partner for IT teams, or book a discovery call.
Newsletter
Subscribe to newsletter
Subscribe to receive the latest blog posts to your inbox every week.
