Govern MCP access through API Management

Learning objective

Expose and govern MCP endpoints using Azure API Management.

Core idea

Azure API Management can turn selected managed REST operations into MCP tools or proxy an existing remote MCP server. Both paths give you a gateway endpoint where you can govern access and traffic. Choose the path from what the backend already implements, rather than assuming that every REST API is already an MCP server.

For an architect, governance means controlling admission, downstream credentials, traffic, and evidence of execution. A gateway does not establish that a tool’s arguments are compatible or that its result is correct. Those checks belong to 2.3.9 and 2.3.10. It also does not replace approval of a sensitive side effect.

How it works

Choose the exposure path

For a managed HTTP-compatible REST API, select Expose an API as an MCP server, choose the API or API version, and select the operations to expose as tools. The server’s Tools interface lets you revise that selection. A narrow tool set gives the agent only the operations its task needs while leaving the underlying API available for other consumers.

For a server that already implements MCP, select Expose an existing MCP server, provide its MCP server base URL, and choose its transport. Streamable HTTP is the documented default; the external-server path also supports SSE. The external server must conform to MCP revision 2025-06-18 or later. This is a minimum documented revision, not proof that every extension in every later revision is supported end to end.

The resulting Server URL is the endpoint the client should use. A client still pointing directly at the original backend bypasses the gateway’s admission and traffic policies. Verify the effective client configuration, not only the successful creation of a gateway resource.

Scope capabilities by path. The REST-to-MCP page documents tools, without resources or prompts. The existing-server page documents tools and resources, without prompts. The overview describes tools-only support, so these pages disagree about resources for external servers. Validate resource-dependent designs against the target gateway; this lesson’s tool exposure does not depend on that disputed capability.

MCP server management is documented for Developer, Basic, Standard, Premium, Basic v2, Standard v2, and Premium v2, and for the self-hosted gateway. MCP capabilities are not supported in API Management workspaces. Do not infer availability from a policy’s “all tiers” label: policy availability and MCP exposure availability are different facts.

Separate inbound and outbound security

Inbound security controls the MCP client-to-gateway request. A subscription key uses the Ocp-Apim-Subscription-Key header. Token-based access can use Microsoft Entra ID tokens in Authorization, validated through validate-azure-ad-token. Configure the accepted identity and application requirements rather than accepting any bearer string.

Outbound security controls gateway-to-backend access. API Management credential manager can supply OAuth tokens through get-authorization-context, with set-header attaching the resulting access token to the outbound Authorization header. This is a different decision from validating the inbound token. Decide whether your operation needs a caller-specific downstream identity or an integration credential.

A request through the Server URL passes inbound and outbound security separately, while a client pointing directly at the original backend bypasses the gateway.

Keep those identities visible in the architecture. If many inbound callers share one outbound credential, the backend’s view of the integration identity alone cannot explain which person initiated a business action. Preserve correlation and enforce caller-specific business authorization at the appropriate service. Do not assume that replacing an incoming header with a backend token also preserves the caller’s permissions.

Package access and bound traffic

API Management products can group MCP servers and apply subscription, approval, and policy assignment workflows. For example, a finance product can bundle invoice lookup and notification servers for one consuming team. Product subscription approval grants access to the offering; it is not approval to send a particular notification.

Use documented policy identifiers such as rate-limit-by-key to control request traffic. Its calls, renewal-period, and counter-key express the permitted volume, time window, and partition. A counter based on client IP is a different allocation from one based on a consumer identity. Shared network addresses can combine unrelated users into one counter, so choose a partition that matches your fairness requirement.

Policies configured on the MCP server apply to all API operations exposed as its tools. Global policies are evaluated before MCP server policies. Review the effective policy scopes rather than assuming that an MCP-specific policy erases global behavior. Products also support quota-by-key for consumer-partitioned usage ceilings. The product guidance identifies gen_ai.tool.name for a tool-name counter when one tool needs separate throttling; distinguish that counter partition from the scope where the policy executes.

Rate limits reduce admitted traffic; they do not repair authorization defects or make repeated mutations safe. Retry and circuit-breaker choices require a separate failure policy; see 2.3.8. Avoid raising limits merely because a retry loop is generating extra requests.

Preserve streaming and useful telemetry

The exposure pages warn against reading context.Response.Body in MCP server policies because it triggers buffering that interferes with streaming. Do not implement tool-result validation by consuming a streamed response body at this gateway layer. Validate the completed result at the consumer or in an implementation that owns the result contract.

When global diagnostic logging is enabled, the documented prerequisite is to set Frontend Response Number of payload bytes to log to 0. Configure selective payload logging at the API scope where appropriate. A familiar REST logging configuration can otherwise interfere with MCP behavior and capture more content than intended.

Use Azure Monitor or Application Insights integration for gateway activity. The trace policy can add custom trace information, and correlation IDs in request headers connect gateway requests to downstream work. Record the selected server and tool, caller context, and terminal outcome in your application evidence. Keep credentials out of that evidence and distinguish gateway admission from backend business completion.

Key distinctions and trade-offs

REST adaptation versus proxying: Adaptation creates tools from selected API operations. Proxying governs a server that already speaks MCP. Choosing the wrong path adds unnecessary translation or assumes a protocol the backend does not implement.

Subscription approval versus action approval: Products govern who can access a tool offering. Per-call approval governs a concrete operation and arguments; see 2.3.4 and 2.3.9.

Gateway health versus result quality: A successful gateway response can contain an unusable tool result. Traffic telemetry explains delivery; contract and domain checks explain whether downstream consumption is valid.

Architecture / decision scenario

A procurement assistant needs a REST-based supplier lookup and a Logic Apps MCP notification server. The architect exposes selected lookup operations through REST-to-MCP adaptation and proxies the existing notification MCP endpoint. Both client configurations use the corresponding gateway Server URL.

The finance product governs subscriptions. validate-azure-ad-token validates inbound Entra access, while credential manager supplies the separately selected backend token through get-authorization-context and set-header. The team applies rate-limit-by-key with a consumer-aligned counter and records correlated gateway activity with trace and Application Insights.

The notification still requires side-effect approval. The team tests forbidden callers, exhausted traffic limits, and backend failures as well as a successful request. It preserves streaming by avoiding context.Response.Body access and follows the global payload-logging prerequisite. If the design later needs MCP resources, it explicitly tests the external-server capability because the documentation disagrees; it does not extrapolate from successful tool calls.

Common exam traps

• Treating an arbitrary REST endpoint as an existing MCP server.
• Configuring gateway policies while the client keeps using the direct backend URL.
• Treating inbound token validation and outbound credential injection as one control.
• Confusing product subscription approval with approval of a tool’s side effect.
• Assuming all MCP exposure paths support resources, prompts, or workspaces.
• Reading a streaming response body inside an MCP server policy.

What to remember

Choose adaptation or proxying, expose only needed tools, and make clients use the gateway. Govern inbound access and outbound credentials separately, apply traffic policies at deliberate scopes, and preserve streaming. Gateway governance complements compatibility, result validation, and per-call approval.

Knowledge check

References

• Microsoft, Overview of MCP servers in Azure API Management.
• Microsoft, Expose REST API as MCP server.
• Microsoft, Connect and govern existing MCP server.
• Microsoft, Secure access to MCP servers.
• Microsoft, Govern MCP servers with API Management products.