Azure API Center started as an inventory for REST APIs. In 2026 it is becoming the enterprise registry for everything an AI agent or developer might call: APIs, MCP servers, skills, plugins and A2A agents. That makes it a governance tool as much as a catalog. This guide explains the asset types, the metadata model that makes the catalog useful, the agent registration and assessment features that became generally available in June 2026, and how to expose the catalog to developers and agents through the portal and the data plane MCP server.
Where API Center fits
API Center is Azure’s design-time governance and discovery service. Azure API Management governs traffic at runtime through a gateway; API Center keeps the inventory, versions, definitions and metadata of what exists, regardless of where it runs. A practical split:
| Question | Answered by |
|---|---|
| Which APIs, MCP servers and agents exist, who owns them and in which lifecycle stage are they? | API Center |
| Who may call this API right now, at what rate, with which policy? | API Management |
| Which approved tools may an agent discover? | API Center, with runtime enforcement in the gateway or tool host |
Asset types in the inventory
- APIs – REST, SOAP, GraphQL and others, with versions, definitions, environments and deployments.
- MCP servers – registered so agents and developer tools can find approved servers instead of random ones from the internet.
- Skills – reusable AI capabilities that agents can discover.
- Plugins – a higher-level bundle of registered skills and/or MCP servers, so developers install one capability instead of assembling parts.
- Agents – AI agents, including A2A agents, described by an agent card in JSON or an agent definition in Markdown.
Metadata: the difference between a list and a governed catalog
A catalog without consistent metadata becomes a junk drawer. API Center supports built-in metadata (such as kind, lifecycle stage, contact and license) and custom metadata of type boolean, number, string, array, predefined choices and object. Custom metadata can be assigned to APIs, environments and deployments as required or optional, and you can search and filter by metadata in the Azure portal, the REST API, the Azure CLI and the API Center portal.
A minimal custom schema I would start with:
| Metadata | Type | Assignment | Why |
|---|---|---|---|
| Owning team | Predefined choices | Required for APIs | Every asset has someone to call |
| Business domain | Predefined choices | Required for APIs | Filtering and portfolio reporting |
| Data classification | Predefined choices | Required for APIs | Drives security review and agent exposure |
| Agent-consumable | Boolean | Required for APIs | Explicit decision before AI tools may use it |
| Source repository | String | Optional | Link from catalog to code and pipeline |
Two rules from the documentation to remember: do not put sensitive or personal information in metadata titles, because titles appear in monitoring logs; and you cannot delete or change the type of custom metadata while it is assigned to entities – unassign it first. Design the schema carefully up front.
Registering and governing AI agents
Since June 2026, agent registration, agent assessment and Git-based synchronization are generally available. You register an agent under Inventory > Assets > Register an asset > Agent, provide an agent definition in Markdown or an A2A agent card in JSON, choose the version lifecycle stage and, where applicable, the A2A protocol. After registration you can add skills, configure capabilities and update provider information.
Three ways to keep the agent inventory current:
- Git synchronization – A2A agents and other AI assets stored in a Git repository can be synchronized automatically, so the catalog follows the source-controlled definitions.
- API Management synchronization – A2A agent APIs in a linked API Management instance synchronize to API Center.
- Pipelines – register or update assets from CI/CD with the CLI or REST API.
API Center also offers dependency maps for A2A agents (in preview), which help platform teams see which agents rely on which other agents.
AI assessment: a quality gate, not a safety guarantee
Under Governance > AI Assessment you can enable automated assessment of AI assets such as skills and agents. Microsoft describes it as an LLM-as-a-judge framework that scores agents across safety, reliability and behavioral completeness, with default criteria out of the box. Use the score as an entry criterion for the catalog – for example, a minimum score before the lifecycle stage may move to production – and keep runtime controls, identity and human approval for risky actions in place. Registration and a good score make an agent discoverable; they do not make it safe to run.
Plugins and the marketplace endpoint
A plugin bundles registered skills and MCP servers into one capability. API Center exposes registered plugins through a plugin marketplace endpoint based on the API Center data API, which developers can add to GitHub Copilot CLI or Claude Code to browse and install plugins from your own catalog. That is a strong governance lever: if developers install AI capabilities from the company catalog, you decide what is in it.
The data plane MCP server
The API Center MCP server exposes your catalog as a tool surface for agents and MCP-compatible clients such as VS Code with Copilot or Claude Code. Agents use it to search the registry and fetch asset details, and newly registered MCP servers and tools become discoverable without reconfiguring clients.
- Enable it in the Azure portal under Consumption > Data API settings > MCP endpoint. It requires the Standard tier.
- The endpoint follows the form
https://<service name>.data.<region>.azure-apicenter.ms/mcp. - Authentication follows the access method of the API Center portal (anonymous or Microsoft Entra ID).
A VS Code configuration looks like this:
{
"servers": {
"api-center": {
"url": "https://myapicenter.data.westeurope.azure-apicenter.ms/mcp",
"type": "http"
}
}
}For production, use Microsoft Entra ID instead of anonymous access, grant the developer group the Azure API Center Data Reader role at the API Center scope, and configure Data API visibility so only approved records are returned. Remember that discovery access is not runtime access: the MCP servers and APIs that agents find still enforce their own authorization.
The API Center portal for delivery teams
The portal is where developers browse and filter APIs, MCP servers, skills, plugins and agents. Make it part of the delivery process rather than an extra website: link to it from the developer onboarding page, require new APIs to be registered before their first production deployment, and use the metadata filters as the standard way to find an owner or a definition.
Operating model checklist
- Custom metadata schema agreed before the first bulk registration.
- Registration automated from Git, API Management or pipelines; manual registration is the exception.
- Lifecycle stages used consistently, with AI assessment as an entry criterion for production.
- Portal and MCP endpoint secured with Entra ID and Data API visibility rules.
- Runtime governance in API Management; see MCP servers in Azure API Management and Connector Namespace and governing AI APIs with the AI gateway.




0 Comments