Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
In this article, you learn how to package one or more MCP servers into an API Management product so consumers go through the same subscription, approval, and policy assignment workflows your organization already uses for REST APIs.
Prerequisites
An API Management instance. To create one, see Create an Azure API Management instance.
At least one MCP server in your instance. See Expose a REST API as an MCP server or Expose an existing MCP server.
Permissions to manage products in API Management (the API Management Service Contributor role or equivalent).
Why use products for MCP servers
Products are API Management's packaging unit. They control which consumers can subscribe, whether approval is required, what policies such as quotas apply, and how the offering appears in the developer portal. Because MCP servers are first-class API Management resources, they support the same product primitives.
Typical scenarios:
A Sales tools product contains a CRM MCP server, a Pricing MCP server, and a Quote MCP server: one subscription grants access to all three.
Free and paid plans with different quotas.
Per-team subscriptions for chargeback reporting.
Add an MCP server to a product
You can add an MCP server to an existing product directly from the MCP server's settings page, without navigating to the Products blade.
- In the Azure portal, go to your API Management instance.
- In the sidebar menu, select APIs > MCP servers, and then select the MCP server that you want to govern.
- Select Settings, and then select the Products tab.
- Select one or more existing products to add the MCP server to. Select Save.
Alternatively, to create a new product first, go to Products > + Add, and complete the form. Then return to the MCP server's Settings > Products tab to bind it. For information about creating a product, see Tutorial: Create and manage a product.
Subscribe and get keys
A consumer can subscribe to a product that includes an MCP server and receive the necessary keys to access it by following these steps:
In the developer portal, a consumer selects the product and chooses Subscribe. If approval is required, an administrator approves the request.
The consumer receives a primary key and secondary key. The same key authorizes calls to every MCP server in the product.
The consumer configures their MCP client (for example, Visual Studio Code or Claude Desktop) to send the key in the
Ocp-Apim-Subscription-Keyheader.
Tip
To rotate a subscription key without disrupting consumers, regenerate the secondary key, update clients to use it, and then regenerate the primary key.
Apply quotas and rate limits
Use product-scoped policies to cap usage per subscription or per consumer. For example:
The quota policy enforces a long-window call ceiling (for example, per month).
The rate-limit policy enforces a short-window throttle (for example, per minute).
The quota-by-key policy keys the counter off
context.Subscription.Idor a JWT claim so each consumer gets its own bucket.
Note
These policies count tool-call requests. To cap LLM token consumption, use the llm-token-limit policy on the MCP server's backing API.
To throttle one noisy tool on an MCP server, key a counter on the tool name:
<quota-by-key calls="50" renewal-period="60"
counter-key="@(context.Variables.GetValueOrDefault<string>("gen_ai.tool.name",,""))" />
Important
Don't access context.Response.Body from policies attached to product with bound MCP servers. MCP responses are streamed, and reading the body breaks the stream.