Same Kitchen, Two Doors, One Maître d'
Azure API Management (APIM) can act as a gatekeeper for both REST and Microsoft Connector Protocol (MCP) endpoints, ensuring consistent authentication, throttling, and observability. Three patterns—APIM in front of REST, APIM in front of MCP, and APIM as an MCP server—offer different trade‑offs dep…
When building a backend that exposes the same functionality through both a traditional REST API and the newer Microsoft Connector Protocol (MCP), the question isn’t whether to choose one or the other. It’s how to keep both doors behaving the same way, especially around authentication, error handling, and idempotency. Azure API Management (APIM) can step in as the maître d’, applying policies that keep the kitchen—your backend—unaware of the traffic flow.
Why a Gatekeeper Is Needed
Both REST and MCP endpoints in a typical sample share a single mechanical authentication method: a function key or an MCP system key. That key simply proves the caller has a string; it doesn’t identify the caller, it can’t be revoked per user, and it offers no per‑caller limits. As soon as agents start retrying, chaining calls, or misreading tool descriptions, the lack of identity becomes a security and operational risk. The gateway’s job is to answer the platform team’s core question: who called what, how often, and should they be allowed to?
Pattern One – APIM in Front of the REST Door
This is the classic use case. APIM sits in front of the /api endpoints, handling JWT validation against Entra ID, subscription key checks, rate limits, quotas, and IP filtering. The REST contract stays unchanged, but the endpoint is no longer exposed directly to the internet. The function app is locked down so only the gateway can reach it.
Pattern Two – APIM in Front of the MCP Door
APIM can also expose an existing MCP server as a passthrough. The MCP traffic, which is streamable HTTP, flows through the gateway and inherits all the same policies as any other API. The key benefit is that the agent no longer holds the backend credential; the client authenticates to APIM with OAuth or a subscription key, and a policy injects the x-functions-key to the backend. Rotating the system key becomes an internal operation invisible to external clients. Additional benefits include per‑agent throttling, request tracing, and, starting with Build 2026, MCP‑aware content safety policies.
Pattern Three – APIM as the MCP Door
In this configuration APIM itself manufactures an MCP server from a REST API it already manages. The function app implements only the REST door; the MCP extension disappears from the codebase, and the second door is generated at the gateway. This is attractive when you can’t or don’t want to modify existing code. However, tool descriptions move from code to gateway configuration, which means the business‑logic owner no longer controls the text the agent reads. This can lead to misaligned tool selection if the description is vague or out of sync with the implementation.
Choosing the Right Pattern
Pattern one is never wrong; it simply covers only the door that agents don’t use. Pattern two is the default for new systems because it keeps tool descriptions in code and lets APIM handle identity, limits, and observability. Pattern three is best for estates that already own many APIs in APIM and cannot change the backend code. Each pattern has trade‑offs around control, cost, and the number of tool choices presented to an agent.
What the Deployment Revealed
- mcpProperties.endpoints expects an object keyed by endpoint name, not an array as the docs suggest.
- The client‑facing URL is the API path plus an /mcp suffix—a small but common trap.
- When a spec‑compliant MCP client receives a 401, it initiates OAuth dynamic client registration; APIM responds with a 404 if the flow isn’t configured.
These nuances underscore the importance of setting up OAuth correctly and verifying that the gateway policies match the expected contract.
Where to Put Discovery and Hard Contracts
The core decision is whether you want discovery (MCP) or a hard contract (REST). Wherever you place discovery, put a gateway in front that knows who is discovering. The backend stays the same; the doors stay honest; the maître d’ remembers every guest.
For more detailed infrastructure examples, a companion repo will provide Bicep templates and policies for patterns two and three.
Conclusion
APIM can act as a single, consistent gatekeeper for both REST and MCP endpoints, ensuring that authentication, throttling, and observability are applied uniformly. By choosing the appropriate pattern, teams can balance control, code ownership, and operational simplicity while keeping the backend free from traffic concerns.
Why it matters
APIM’s ability to unify MCP and REST access simplifies security and governance, allowing teams to enforce consistent policies across all entry points without touching backend code.
Key points
- APIM can enforce auth, throttling, and observability for both REST and MCP endpoints.
- Pattern two keeps tool descriptions in code, giving the backend team full control.
- Pattern three is ideal for existing APIs that cannot be modified.
- The gateway handles OAuth and key rotation, reducing operational risk.
- Choosing the right pattern depends on code ownership and the need for discovery.
- APIM’s MCP support is currently tools‑only; future releases may add more features.
Frequently asked questions
What is the difference between MCP and REST in this context?
REST is a traditional HTTP API with a fixed contract, while MCP is a protocol that allows agents to discover available tools and call them dynamically.
Can I use APIM to protect both endpoints at the same time?
Yes, APIM can sit in front of both the REST and MCP doors, applying policies to each.
Do I need to modify my backend code to use APIM as the MCP door?
No, APIM can generate an MCP server from an existing REST API, eliminating the need for MCP extensions in code.
