“Where do we run our MCP servers?” has become a standard question in Azure integration projects. Azure now has two services that answer different halves of it: Azure API Management governs MCP traffic like any other API, and Azure Connector Namespace hosts connectors and MCP servers for you. This guide explains what each one does, how to manage MCP servers in API Management as code, where Connector Namespace fits, and how I would combine them with API Center into one architecture.

Two different jobs

MCP servers in Azure API Management

API Management supports the remote MCP server mode and offers two ways to expose MCP servers:

• REST API as MCP server – any REST API managed in API Management can be exposed as an MCP server, with API operations becoming MCP tools.
• Pass-through MCP server – point API Management at an existing MCP backend using the streamable HTTP or SSE transport, and apply gateway policies in front of it.

Know the boundaries before you design: API Management currently supports MCP tools, not MCP resources or prompts, and the MCP server capabilities are not supported in workspaces. Check tier availability for your instance as well; MCP export is not available in the Consumption tier.

Managing MCP servers as code

For production you want MCP servers in your pipeline, not clicked together in the portal. API Management supports creating and managing them with the REST API, ARM templates, Bicep, the Azure CLI and Terraform, using REST API version 2025-09-01-preview or later – pin that version in every request. The resource model is straightforward:

• An MCP server is an API Management API resource of type mcp.
• A pass-through server declares the backend URL and transport.
• Tools are sub-resources of the MCP server, so you can add, rename or remove tools from CI/CD without recreating the server.
• Policies attach to MCP servers the same way they attach to regular APIs.

Listing the MCP servers in an instance, for example as a drift check in a pipeline:

API_VERSION="2025-09-01-preview"
BASE_URL="https://management.azure.com/subscriptions/$SUBSCRIPTION_ID/resourceGroups/$RESOURCE_GROUP/providers/Microsoft.ApiManagement/service/$APIM_NAME"
TOKEN=$(az account get-access-token --resource https://management.azure.com --query accessToken -o tsv)
curl -sG "$BASE_URL/apis"   --data-urlencode "api-version=$API_VERSION"   --data-urlencode "$filter=type eq 'mcp'"   -H "Authorization: Bearer $TOKEN"

The identity running the pipeline needs permission to read the service and to create or update APIs, API tools, API policies and product-API links.

Governance policies I put in front of every MCP server

1. Authentication – validate Microsoft Entra ID tokens for MCP clients; no anonymous tool access. See OAuth 2.0 with Entra ID in API Management.
2. Per-client limits – rate limits and quotas per client or agent identity, because an agent loop can call a tool far more often than a human ever would.
3. Tool scope – expose only the operations an agent should use. Turning a whole REST API into tools is easy; turning only the safe read operations into tools is responsible.
4. Logging and tracing – send gateway activity to Azure Monitor and propagate a correlation ID to the backend, so you can answer which agent called which tool with which outcome.
5. Versioning – treat tool names and parameter schemas as a contract. Renaming a tool breaks agents that learned the old one.

Azure Connector Namespace

Connector Namespace is a fully managed integration service for compute that does not run on a workflow engine – Azure Functions, Container Apps, App Service and similar. It is deliberately separate from Azure Logic Apps: it does not require, use or change anything in Logic Apps, and the Logic Apps connector gallery keeps working independently.

What it provides:

• Connectors with SDKs – your app calls connector actions and subscribes to triggers through strongly typed SDKs for C# (Azure.Connectors.Sdk), Node.js and Python. The namespace handles authentication, credential rotation, polling, webhook delivery, retries and throttling.
• Managed MCP servers – convert a connector in your namespace into an MCP server in one step; the namespace handles server configuration, tool definitions, lifecycle and runtime.
• Hosted MCP servers (preview) – deploy prebuilt servers from a curated catalog, such as Playwright for browser automation or an Azure SQL server built on Data API Builder. The namespace pulls the image, provisions compute, exposes a secure endpoint and handles scaling, health and authentication.

Hosted servers have two authentication boundaries: inbound (MCP client to server, OAuth with Microsoft Entra ID) and outbound (server to the downstream service). You can attach Application Insights for logs and telemetry. During preview, hosted servers are available in a limited set of regions (West Central US, East Asia, Central US and North Europe), Microsoft does not recommend the service for production workloads, and you are responsible for configuring hosted servers correctly.

One architecture: host, govern, catalog

1. Host tools where it makes sense: your own APIs, existing MCP servers, or Connector Namespace for SaaS connectivity.
2. Govern all agent traffic through API Management, so authentication, limits and logging are consistent regardless of where a tool runs.
3. Catalog every approved MCP server in Azure API Center, so agents and developers discover only what has been reviewed – see Azure API Center as the registry for APIs, MCP servers and agents.

Until Connector Namespace leaves preview, I would use it for prototypes and non-critical internal agents, and keep production tools on APIs you already operate behind API Management.

Checklist

• MCP servers and tools defined in code with a pinned API version.
• Entra ID authentication and per-client limits on every MCP endpoint.
• Only intended operations exposed as tools; tool names versioned like API contracts.
• Gateway logs and correlation IDs available to operations.
• Preview services kept out of production paths until GA.
• Every approved server registered in API Center.

Sources

• About MCP servers in Azure API Management
• Manage MCP servers programmatically in API Management
• Azure Connector Namespace overview
• Hosted MCP servers in Connector Namespace
• Developer guide for hosted MCP servers