Build. Secure. Launch Your Private MCP Registry with Azure API Center.
We are thrilled to embrace a new era in the world of MCP registries. As organizations increasingly build and consume MCP servers, the need for a secure, governed, robust and easily discoverable tools catalog has become critical. Today, we are excited to show you how to do just that with MCP Center, a live example demonstrating how Azure API Center (APIC) can serve as a private and enterprise-ready MCP registry. The registry puts your MCPs just one click away for developers, ensuring no setup fuss and a direct path to coding brilliance. Why a private registry? đ¤ Public OSS registries have been instrumental in driving growth and innovation across the MCP ecosystem. But as adoption scales, so does the need for tighter security, governance, and control, this is where private MCP registries step in. This is where Azure API Center steps in. Azure API Center offers a powerful and centralized approach to MCP discovery and governance across diverse teams and services within an organization. Let's delve into the key benefits of leveraging a private MCP registry with Azure API Center. Security and Trust: The Foundation of AI Adoption Review and Verification: Public registries, by their open nature, accept submissions from a wide range of developers. This can introduce risks from tools with limited security practices or even malicious intent. A private registry empowers your organization to thoroughly review and verify every MCP server before it becomes accessible to internal developers or AI agents (like Copilot Studio and AI Foundry). This eliminates the risk of introducing random, potentially vulnerable first or third-party tools into your ecosystem. Reduced Attack Surface: By controlling which MCP servers are accessible, organizations significantly shrink their potential attack surface. When your AI agents interact solely with known and secure internal tools, the likelihood of external attackers exploiting vulnerabilities in unvetted solutions is drastically reduced. Enterprise-Grade Authentication and Authorization: Private registries enable the enforcement of your existing robust enterprise authentication and authorization mechanisms (e.g., OAuth 2) across all MCP servers. Public registries, in contrast, may have varying or less stringent authentication requirements. Enforced AI Gateway Control (Azure API Management): Beyond vetting, a private registry enables organizations to route all MCP server traffic through an AI gateway such as Azure API Management. This ensures that every interaction, whether internal or external, adheres to strict security policies, including centralized authentication, authorization, rate limiting, and threat protection, creating a secure front for your AI services. Governance and Control: Navigating the AI Landscape with Confidence Centralized Oversight and "Single Source of Truth": A private registry provides a centralized "single source of truth" for all AI-related tools and data connections within your organization. This empowers comprehensive oversight of AI initiatives, clearly identifying ownership and accountability for each MCP server. Preventing "Shadow AI": Without a formal registry, individual teams might independently develop or integrate AI tools, leading to "shadow AI" â unmanaged and unmonitored AI deployments that can pose significant risks. A private registry encourages a standardized approach, bringing all AI tools under central governance and visibility. Tailored Tool Development: Organizations can develop and host MCP servers specifically tailored to their unique needs and requirements. This means optimized efficiency and utility, providing specialized tools you won't typically find in broader public registries. Simplified Integration and Accelerated Development: A well-managed private registry simplifies the discovery and integration of internal tools for your AI developers. This significantly accelerates the development and deployment of AI-powered applications, fostering innovation. Good news! Azure API Center can be created for free in any Azure subscription. You can find a detailed guide to help you get started: Inventory and Discover MCP Servers in Your API Center - Azure API Center Get involved đĄ Your remote MCP server can be discoverable on API Centerâs MCP Discovery page today! Bring your MCP server and reach Azure customers! These Microsoft partners are shaping the future of the MCP ecosystem by making their remote MCP Servers discoverable via API Centerâs MCP Discovery page. Early Partners: Atlassian â Connect to Jira and Confluence for issue tracking and documentation Box â Use Box to securely store, manage and share your photos, videos, and documents in the cloud Neon â Manage and query Neon Postgres databases with natural language Pipedream â Add 1000s of APIs with built-in authentication and 10,000+ tools to your AI assistant or agent - coming soon - Stripe â Payment processing and financial infrastructure tools If partners would like their remote MCP servers to be featured in our Discover Panel, reach out to us here: GitHub/mcp-center and comment under the following GitHub issue: MCP Server Onboarding Request Ready to Get Started? đ Modernize your AI strategy and empower your teams with enhanced discovery, security, and governance of agentic tools. Now's the time to explore creating your own private enterprise MCP registry. Check out MCP Center, a public showcase demonstrating how you can build your own enterprise MCP registry - MCP Center - Build Your Own Enterprise MCP Registry - or go ahead and create your Azure API Center today!
Not able to setup azure private endpoint url as webservice/backend for Azure API Management service
Hi all, I have integrated Private endpoint connected to private link service. Private link service is created by azure standard load balancer created by kubernetes load balancer service using below annotations . annotations: service.beta.kubernetes.io/azure-load-balancer-internal: "true" service.beta.kubernetes.io/azure-pls-create: "true" service.beta.kubernetes.io/azure-pls-name: myPLS service.beta.kubernetes.io/azure-pls-ip-configuration-subnet: YOUR SUBNET service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address-count: "1" service.beta.kubernetes.io/azure-pls-ip-configuration-ip-address: SUBNET_IP service.beta.kubernetes.io/azure-pls-proxy-protocol: "false" service.beta.kubernetes.io/azure-pls-visibility: "*" # does not apply here because we will use Front Door later service.beta.kubernetes.io/azure-pls-auto-approval: "YOUR SUBSCRIPTION ID" i am getting expected response i.e response from kubernetes service from Private endpoint ip which confirms that private link and private endpoint integration is working fine. we now want to integrate above private endpoint service with azure api management service so we tried adding private endpoint url as web service url for api management service but api management service is returning 500 error { "statusCode": 500, "message": "Internal server error", "activityId": "76261291-7121-4814-b0e4-66b52284d76c" } I also tried api management service Troubleshoot & analysis page for exact error its showing below error: BackendConnectionFailure An attempt was made to access a socket in a way forbidden by its access permissions <private_endpoint_url>:80 Please help me what i am doing wrong in this implementation Our requirement is to have kubernetes private load balancer and integrate it with azure api management service. so user can access api only through api management service and only api management service should be able to access load balancer service. Thanks in advance
How to update the proxyAddresses of a Cloud-only Entra ID user
I currently have a client with an Entra ID user (not migrated from on-premises) that is cloud-based, but has proxyAddresses values assigned. Now, I want to update the proxyAddresses through the Graph Explorer and have used this link as a guide: https://learn.microsoft.com/en-us/answers/questions/2280046/entra-connect-sync-blocking-user-creation-due-to-h. Now this guide is suggesting you can use the BETA model and this URL format... https://graph.microsoft.com/beta/users/%USERGUID% It states you can use that URL to do both 'GET' and 'PATCH' queries - the PATCH query being the one that will change the settings. You have to put forth a body for the proxyAddresses property in the PATCH query, which represents all of the addresses you want the user to utilise as proxy addresses. Now the GET query works... The PATCH query does not... Screenshot provided: Now, regarding the error message, I have applied ALL possible permissions in the 'Modify Permissions' tab. It is still erroring, Now I cannot use Exchange Online PowerShell, as the user does not have a mailbox! Aside from potentially using a license for Exchange Online or provisioning a mailbox for the user, and making the necessary changes, would the only other option be to delete/recreate the user?
Announcing the Public Preview of the Applications feature in Azure API management
API Management now supports built-in OAuth 2.0 application-based access to product APIs using the client credentials flow. This feature allows API managers to register Microsoft Entra ID applications, streamlining secure API access for developers through OAuth 2.0 authorization. API publishers and developers can now more effectively manage client identity, access, and authorization flows. With this feature: API managers can identify which products require OAuth authorization by setting a product property to enable application-based access API managers can create and manage client applications and assign them access to specific products. Developers can see their registered applications in API management developer portal and use OAuth tokens to securely call APIs and products OAuth tokens presented in API requests are validated by the API Management gateway to authorize access to the product's APIs. This feature simplifies identity and access management in API programs, enabling a more secure and scalable approach to API consumption. Enable OAuth authorization API managers can now identify specific products which are protected by Microsoft Entra identity by enabling "Application based access". This ensures that only valid client applications which have a secure OAuth token from Microsoft Entra identity can access the APIs associated with this product. An application is created in Microsoft Entra corresponding to the product, with appropriate app role. Register client applications and assign products API managers can register client applications, identify specific developers as owners of these applications and assign products to these applications. This creates a new application in Microsoft Entra and assigns API permissions to access the product. Securely access the API using client applications Developers can login into API management developer portal and see the appropriate applications assigned to them. They can retrieve the application credentials and call Microsoft Entra to get an OAuth token, use this token to call APIM gateway and securely access the product/API. Preview limitations The public preview of the Applications is a limited-access feature. To participate in the preview and enable Applications in your APIM service instance, you must complete a request form. The Azure API Management team will review your request and respond via email within five business days. Learn more Securely access product APIs with Microsoft Entra applicationsEnforce or Audit Policy Inheritance in API Management
Weâre excited to announce a new Azure Policy definition that lets you enforce or audit policy inheritance in Azure API Management. With this capability, platform and governance teams can ensure that API Management policies are always inherited across all policy scopes â operations, APIs, products, and workspaces â strengthening consistency, compliance, and security across your API estate. Why this matters In Azure API Management, the <base /> policy element plays a critical role: it ensures that a runtime policy inherits policies defined at a higher scope, such as product, workspace, or all APIs (global). Without <base />, developers can inadvertently (or intentionally) bypass important platform rules, for example: Security controls like authentication or IP restrictions Operational requirements such as logging, tracing, or rate-limiting Business policies such as quota enforcement The result can be inconsistent behavior, compliance drift, and gaps in governance. How the new policy helps With the new Azure Policy definition, you can automatically ensure that <base /> is located at the start of each API Management policy section â <inbound>, <outbound>, <backend>, and <on-error> â across policies configured on operations, APIs, products, and workspaces. You can set the effect parameter to: Audit: Identify operation, API, product, or workspace policies where <base /> is missing. Deny: Prevent deployment of policies that do not include <base />. Get started To enable this new Azure Policy definition: Navigate to Azure Policy in the Azure portal. Select âDefinitionsâ from the menu and choose âAPI Management policies should inherit parent scope policies using <base />â. In the policy definition view, select âAssignâ. Configure the policy assignment scope, parameter (audit or deny), and other details. View built-in Azure Policy definitions for API Management.Update To API Management Workspaces Breaking Changes: Built-in Gateway & Tiers Support
Whatâs changing? If your API Management service uses preview workspaces on the built-in gateway and meets the tier-based limits below, those workspaces will continue to function as-is and will automatically transition to general availability once built-in gateway support is fully announced. API Management tier Limit of workspaces on built-in gateway Premium and Premium v2 Up to 30 workspaces Standard and Standard v2 Up to 5 workspaces Basic and Basic v2 Up to 1 workspace Developer Up to 1 workspace Why this change? We introduced the requirement for workspace gateways to improve reliability and scalability in large, federated API environments. While we continue to recommend workspace gateways, especially for scenarios that require greater scalability, isolation, and long-term flexibility, we understand that many customers have established workflows using the preview workspaces model or need workspaces support in non-Premium tiers. Whatâs not changing? Other aspects of the workspace-related breaking changes remain in effect. For example, service-level managed identities are not available within workspaces. In addition to workspaces support on the built-in gateway described in the section above, Premium and Premium v2 services will continue to support deploying workspaces with workspace gateways. Resources Workspaces in Azure API Management Original breaking changes announcements Reduced tier availability Requirement for workspace gatewaysAnnouncing the availability of TLS 1.3 in Azure API Management in Preview
TLS 1.3 is the latest version of the internetâs most deployed security protocol, which encrypts data to provide a secure communication channel between two endpoints. TLS 1.3 support in Azure API Management is planned to rollout during the first week of February 2024. The rollout will happen in stages, this means some regions will get it first as we roll out globally.Expose REST APIs as MCP servers with Azure API Management and API Center (now in preview)
As AI-powered agents and large language models (LLMs) become central to modern application experiences, developers and enterprises need seamless, secure ways to connect these models to real-world data and capabilities. Today, weâre excited to introduce two powerful preview capabilities in the Azure API Management Platform: Expose REST APIs in Azure API Management as remote Model Context Protocol (MCP) servers Discover and manage MCP servers using API Center as a centralized enterprise registry Together, these updates help customers securely operationalize APIs for AI workloads and improve how APIs are managed and shared across organizations. Unlocking the value of AI through secure API integration While LLMs are incredibly capable, they are stateless and isolated unless connected to external tools and systems. Model Context Protocol (MCP) is an open standard designed to bridge this gap by allowing agents to invoke toolsâsuch as APIsâvia a standardized, JSON-RPC-based interface. With this release, Azure empowers you to operationalize your APIs for AI integrationâsecurely, observably, and at scale. 1. Expose REST APIs as MCP servers with Azure API Management An MCP server exposes selected API operations to AI clients over JSON-RPC via HTTP or Server-Sent Events (SSE). These operations, referred to as âtools,â can be invoked by AI agents through natural language prompts. With this new capability, you can expose your existing REST APIs in Azure API Management as MCP serversâwithout rebuilding or rehosting them. Addressing common challenges Before this capability, customers faced several challenges when implementing MCP support: Duplicating development efforts: Building MCP servers from scratch often led to unnecessary work when existing REST APIs already provided much of the needed functionality. Security concerns: Server trust: Malicious servers could impersonate trusted ones. Credential management: Self-hosted MCP implementations often had to manage sensitive credentials like OAuth tokens. Registry and discovery: Without a centralized registry, discovering and managing MCP tools was manual and fragmented, making it hard to scale securely across teams. API Management now addresses these concerns by serving as a managed, policy-enforced hosting surface for MCP toolsâoffering centralized control, observability, and security. Benefits of using Azure API Management with MCP By exposing MCP servers through Azure API Management, customers gain: Centralized governance for API access, authentication, and usage policies Secure connectivity using OAuth 2.0 and subscription keys Granular control over which API operations are exposed to AI agents as tools Built-in observability through APIMâs monitoring and diagnostics features How it works MCP servers: In your API Management instance navigate to MCP servers Choose an API: + Create a new MCP Server and select the REST API you wish to expose. Configure the MCP Server: Select the API operations you want to expose as tools. These can be all or a subset of your APIâs methods. Test and Integrate: Use tools like MCP Inspector or Visual Studio Code (in agent mode) to connect, test, and invoke the tools from your AI host. Getting started and availability This feature is now in public preview and being gradually rolled out to early access customers. To use the MCP server capability in Azure API Management: Prerequisites Your APIM instance must be on a SKUv1 tier: Premium, Standard, or Basic Your service must be enrolled in the AI Gateway early update group (activation may take up to 2 hours) Use the Azure Portal with feature flag: ⤠Append ?Microsoft_Azure_ApiManagement=mcp to your portal URL to access the MCP server configuration experience Note: Support for SKUv2 and broader availability will follow in upcoming updates. Full setup instructions and test guidance can be found via aka.ms/apimdocs/exportmcp. 2. Centralized MCP registry and discovery with Azure API Center As enterprises adopt MCP servers at scale, the need for a centralized, governed registry becomes critical. Azure API Center now provides this capabilityâserving as a single, enterprise-grade system of record for managing MCP endpoints. With API Center, teams can: Maintain a comprehensive inventory of MCP servers. Track version history, ownership, and metadata. Enforce governance policies across environments. Simplify compliance and reduce operational overhead. API Center also addresses enterprise-grade security by allowing administrators to define who can discover, access, and consume specific MCP serversâensuring only authorized users can interact with sensitive tools. To support developer adoption, API Center includes: Semantic search and a modern discovery UI. Easy filtering based on capabilities, metadata, and usage context. Tight integration with Copilot Studio and GitHub Copilot, enabling developers to use MCP tools directly within their coding workflows. These capabilities reduce duplication, streamline workflows, and help teams securely scale MCP usage across the organization. Getting started This feature is now in preview and accessible to customers: https://aka.ms/apicenter/docs/mcp AI Gateway Lab | MCP Registry 3. Whatâs next These new previews are just the beginning. We're already working on: Azure API Management (APIM) Passthrough MCP server support Weâre enabling APIM to act as a transparent proxy between your APIs and AI agentsâno custom server logic needed. This will simplify onboarding and reduce operational overhead. Azure API Center (APIC) Deeper integration with Copilot Studio and VS Code Today, developers must perform manual steps to surface API Center data in Copilot workflows. Weâre working to make this experience more visual and seamless, allowing developers to discover and consume MCP servers directly from familiar tools like VS Code and Copilot Studio. For questions or feedback, reach out to your Microsoft account team or visit: Azure API Management documentation Azure API Center documentation â The Azure API Management & API Center Teamsđ New in Azure API Management: MCP in v2 SKUs + external MCP-compliant server support
Your APIs are becoming tools. Your users are becoming agents. Your platform needs to adapt. Azure API Management is becoming the secure, scalable control plane for connecting agents, tools, and APIs â with governance built in. -------------------------------------------------------------------------------------------------------------------------------------------------------------------- Today, weâre announcing two major updates to bring the power of the Model Context Protocol (MCP) in Azure API Management to more environments and scenarios: MCP support in v2 SKUs â now in public preview Expose existing MCP-compliant servers through API Management These features make it easier than ever to connect APIs and agents with enterprise-grade controlâwithout rewriting your backends. Why MCP? MCP is an open protocol that enables AI agentsâlike GitHub Copilot, ChatGPT, and Azure OpenAIâto discover and invoke APIs as tools. It turns traditional REST APIs into structured, secure tools that agents can call during execution â powering real-time, context-aware workflows. Why API Management for MCP? Azure API Management is the single, secure control plane for exposing and governing MCP capabilities â whether from your REST APIs, Azure-hosted services, or external MCP-compliant runtimes. With built-in support for: Security using OAuth 2.1, Microsoft Entra ID, API keys, IP filtering, and rate limiting. Outbound token injection via Credential Manager with policy-based routing. Monitoring and diagnostics using Azure Monitor, Logs, and Application Insights. Discovery and reuse with Azure API Center integration. Comprehensive policy engine for request/response transformation, caching, validation, header manipulation, throttling, and more. âŚyou get end-to-end governance for both inbound and outbound agent interactions â with no new infrastructure or code rewrites. â Whatâs New? 1. MCP support in v2 SKUs Previously available only in classic tiers (Basic, Standard, Premium), MCP support is now in public preview for v2 SKUs â Basic v2, Standard v2, and Premium v2 â with no pre-requisites or manual enablement required. You can now: Expose any REST API as an MCP server in v2 SKUs Protect it with Microsoft Entra ID, keys or tokens Register tools in Azure API Center 2. Expose existing MCP-compliant servers (pass-through scenario) Already using tools hosted in Logic Apps, Azure Functions, LangChain or custom runtimes? Now you can govern those external tool servers by exposing them through API Management. Use API Management to: Secure external MCP servers with OAuth, rate limits, and Credential Manager Monitor and log usage with Azure Monitor and Application Insights Unify discovery with internal tools via Azure API Center đ You bring the tools. API Management brings the governance. đ§ Whatâs Next Weâre actively expanding MCP capabilities in API Management: Tool-level access policies for granular governance Support for MCP resources and prompts to expand beyond tools đ Get Started đ Expose APIs as MCP servers đ Connect external MCP servers đ Secure access to MCP servers đ Discover tools in API Center Summary Azure API Management is your single control plane for agents, tools and APIs â whether you're building internal copilots or connecting external toolchains. This preview unlocks more flexibility, less friction, and a secure foundation for the next wave of agent-powered applications. No new infrastructure. Secure by default. Built for the future.
