Here's a pattern I keep running into on teams that just started shipping agents: someone stands up a Model Context Protocol server over a weekend, hard-codes a bearer token, points it straight at the production orders API, and calls it done. Multiply that by five teams and you have five unmanaged doors into your backend — each with its own auth story, none with a rate limit, none showing up in a dashboard anyone watches.
The frustrating part is that the tools those agents want almost always already exist. They're REST endpoints you've spent years putting behind a gateway, with quotas and JWT validation and telemetry. Azure API Management's MCP support is the move that makes the two things one thing: it projects the APIs you already manage as MCP tools, behind the same gateway, without a rewrite.
MCP is Anthropic's open standard for connecting models and agents to external data. It's a client-server protocol over JSON-RPC 2.0: a host application (GitHub Copilot in VS Code, Claude, ChatGPT) runs a client that opens a connection to an MCP server, and the server exposes tools the model can call. The remote flavor runs over HTTP — specifically Streamable HTTP on a /mcp endpoint, which replaced the older HTTP+SSE transport that's been deprecated since protocol version 2024-11-05.
The insight API Management leans on: an MCP tool and a REST operation are the same shape. Both take structured input, do a thing, return structured output. So when you "expose an API as an MCP server," each API operation you pick becomes a tool. GET /orders/{id} becomes a getOrder tool an agent can invoke by name. You're not writing server code — you're selecting operations.
In the portal it's APIs > MCP Servers > + Create MCP server > Expose an API as an MCP server. Choose the managed API, tick the operations you want as tools, name it, and you get a server URL shaped like:
https://<apim-service-name>.azure-api.net/<api-name>-mcp/mcp
Prefer infrastructure as code? The same server is manageable through the API Management REST API, ARM, Bicep, the Azure CLI, and Terraform, so this fits a pipeline rather than a click-path.
Two front doors
There are two ways in, and they solve different problems:
- REST API as MCP server — the case above. Any HTTP-compatible API in API Management, including ones imported from Azure resources, becomes a set of tools. This is the one you'll reach for most.
- Existing MCP server — you already run an MCP-compatible server (a LangChain/LangServe app, a Logic App, a Function app) and want it governed. API Management fronts it as a proxy so the same policies, keys, and monitoring apply. You just give it the backend base URL and a route prefix.
Either way, the gateway sits in the middle, which is the whole reason to bother.
Governance is the point, not a side effect
A raw MCP server your team hand-rolls has none of the controls you'd never ship an API without. Put it behind API Management and the existing policy engine applies to tool calls. Rate limiting and quotas, JWT validation against Microsoft Entra ID, IP filtering, response caching — all of it works, because a tool invocation is just a request through the gateway.
Policies attach at the MCP server scope and apply to every operation exposed as a tool. Here's an inbound section that caps each caller to five calls per 30 seconds and traces the calling agent's ID:
<inbound>
<base />
<!-- 5 calls per 30s, keyed on client IP -->
<rate-limit-by-key calls="5" renewal-period="30"
counter-key="@(context.Request.IpAddress)"
remaining-calls-variable-name="remainingCallsPerIP" />
<!-- surface the agent id in request tracing -->
<trace source="My MCP" severity="information">
<message>MCP tool invoked</message>
<metadata name="agent-id"
value="@(context.Request.Headers.GetValueOrDefault("agent-id","n/a"))" />
</trace>
</inbound>
On the client side, wiring this into VS Code is a matter of MCP: Add Server > HTTP, pasting the server URL, and letting it write to .vscode/mcp.json (workspace) or your global settings.json (user). You add the auth header there — an API Management subscription key travels in Ocp-Apim-Subscription-Key, ideally as a prompted input rather than a checked-in literal. From there it shows up in Copilot's agent-mode tool list like any other tool.
The sharp edge: don't buffer the stream
This is the detail that will cost you an afternoon if you skip it. MCP over Streamable HTTP is, well, streamed. Two common API Management habits break that by forcing the response to buffer:
Don't touch context.Response.Body inside an MCP server policy. Reading it triggers response buffering, which interferes with the streaming transport and can make the server malfunction outright.
The same trap hides in diagnostics. If you've enabled Application Insights or Azure Monitor logging at the global (all-APIs) scope, set Number of payload bytes to log for the Frontend Response to 0. Logging the response body buffers it, and your MCP server that worked in isolation starts failing the moment observability is turned on. If you need payload logging for other APIs, scope it per-API instead of globally.
One more from the troubleshooting column worth internalizing: a 401 from the backend usually means the Authorization header wasn't forwarded — reattach it with a set-header policy rather than debugging the agent.
Know the current edges
This is real but young, so set expectations. API Management supports MCP tools today — not resources, not prompts. It isn't available inside API Management workspaces yet. And it's gated to specific tiers: the classic Developer, Basic, Standard, and Premium, plus the v2 line (Basic v2, Standard v2, Premium v2). The self-hosted gateway can run these servers in your own infrastructure. For finding servers across an org, Azure API Center acts as the registry.
The takeaway
Don't think of this as "API Management got an MCP feature." Think of it as the gateway becoming the control plane for agent traffic the same way it's long been the control plane for API traffic. The concrete next step is small: pick one internal REST API you already trust, expose three of its read-only operations as tools, attach a rate-limit and a JWT-validation policy, and point one agent at it. You'll have a governed, observable MCP server before lunch — and a template every other team can copy instead of hand-rolling door number six.
Sources: