Design Azure API Center as the enterprise inventory and governance plane for APIs, agent tools, OpenAPI definitions, environments, deployments, metadata, linting, and MCP server discovery. Use when building an API or tool catalog, enforcing API standards, registering MCP servers, or making approved tools discoverable to agent builders.
Design Azure API Center as the catalog and governance plane for APIs, tools, versions, definitions, environments, deployments, and MCP servers so agent builders discover approved capabilities instead of ungoverned endpoints.
When to invoke
"Create an API Center catalog for our agent tools."
"Govern OpenAPI definitions and MCP servers for agent builders."
"Design API standards and linting with Azure API Center."
"Make backend APIs discoverable for an agentic platform."
Inputs
Use $ARGUMENTS as the governance scenario: API families, tool types, MCP servers, environments, required metadata, linter standards, consumers, and discovery experience. If the current Azure API Center feature set matters, verify it before stating final design.
Prerequisites and context
Confirm current API Center capabilities, including MCP registration, linting rules, portal features, and extension support, on Microsoft Learn before committing a design.
Do not assert a feature without a source when the platform capability is time-sensitive.
Pair API Center with API Management only when runtime enforcement is in scope; API Center itself is the inventory and governance plane.
Core concepts
Concept
Purpose
Design questions
API
Logical entry for a product, backend, tool, or capability.
Who owns it? What domain does it serve?
Version
Specific version of an API.
What is the lifecycle stage and compatibility policy?
Definition
Contract, typically an OpenAPI document.
Is it linted, complete, and linked to a version?
Environment
Runtime environment such as Azure API Management or a Kubernetes cluster.
Is it dev, staging, production, or sandbox?
Deployment
Runtime location where a version is available.
Which environment, gateway, base URL, and owner apply?
Metadata
Custom governance properties.
Which fields are required for compliance and reporting?
MCP server
Tool server agents can discover and call.
Is it approved, owned, documented, and secured?
Governance model
Governance need
API Center mechanism
Minimum metadata
Ownership
Required custom metadata
owner, team, support contact.
Data sensitivity
Required custom metadata and review workflow
classification, PII, retention, region.
Lifecycle
Version and metadata
stage, deprecation date, replacement API.
Security standards
Linter and required fields
auth type, scopes, network exposure.
Discoverability
Portal or VS Code extension
description, tags, domain, examples.
Agent tool reuse
OpenAPI or MCP registration
tool purpose, side effects, rate limits, safety notes.
Procedure
Model the catalog. Define metadata schema first: owner, classification, lifecycle stage, data sensitivity, cost center, support path, and allowed consumers.
Register APIs and tools. Import OpenAPI definitions for backend APIs and HTTP tools. Register MCP servers so agents can discover them through the governed catalog.
Link environments and deployments. Connect Azure API Management instances and other runtimes so API Center reflects where each API version actually runs.
Govern definitions. Apply the API Center linter and required metadata. Reject or flag definitions that miss security, naming, versioning, or documentation standards.
Publish discovery. Expose the API Center portal or VS Code extension to agent builders with filters for approved tools, environments, and lifecycle stage.
Connect runtime enforcement. Use APIM AI gateway for authentication, token limits, semantic cache, and load balancing when the cataloged API is used at runtime.
Platform fit
Backend APIs / Tools / MCP servers
| register definitions and metadata
Azure API Center (inventory + governance + discovery)
| reference governed APIs
Azure API Management (runtime AI gateway: authN, token limit, cache)
|
Agents (Foundry, Container Apps) select and call governed tools
Related primitives
Name
Type
Use it when
apim-ai-gateway
skill
You need runtime enforcement, authN, token limits, cache, routing, and metrics.
foundry-agent-blueprint
skill
Agents need to consume cataloged APIs as OpenAPI or MCP tools.
azure-agentic-architecture-patterns
skill
You need architecture guidance for tools and MCP boundaries.
Gotchas
Catalogs fail without ownership: require owner and support metadata before publishing an API or tool.
Discovery is not enforcement: API Center does not replace API Management for runtime authentication or throttling.
Linting must run before registration is trusted: imported OpenAPI alone does not guarantee secure or usable APIs.
MCP tool descriptions affect agent behavior: document side effects, auth, and rate limits, not just endpoints.
Output template
## Azure API Center governance design
**Scope:** <APIs, tools, MCP servers, or platform>
| Catalog item | Definition source | Required metadata | Environment/deployment | Governance check |
| --- | --- | --- | --- | --- |
| <API or tool> | <OpenAPI, MCP, manual> | <owner, classification, lifecycle> | <dev/stage/prod runtime> | <linter/approval> |
### Discovery model
- Portal or extension: <audience and filters>
- Approved tool criteria: <criteria>
### Runtime handoff
- API Management/APIM AI gateway: <when used>
Quality gate
Current API Center capabilities are verified when feature specificity matters.
API, Version, Definition, Environment, Deployment, Metadata, and MCP server concepts are mapped where relevant.
Required metadata covers owner, classification, lifecycle, data sensitivity, and support path.
OpenAPI definitions and MCP servers have governance checks before discovery.
Runtime concerns are handed to API Management or apim-ai-gateway instead of overstating API Center.
Agent builders have a clear discovery path for approved APIs and tools.
1---2name: azure-api-center3description: Design Azure API Center as the enterprise inventory and governance plane for APIs, agent tools, OpenAPI definitions, environments, deployments, metadata, linting, and MCP server discovery. Use when building an API or tool catalog, enforcing API standards, registering MCP servers, or making approved tools discoverable to agent builders.4---56<!-- Generated from harness/github-copilot/skills/azure-api-center/SKILL.md by harness/claude-code/scripts/convert_from_copilot.py. Edit the source, not this file. -->78# Azure API Center910Design Azure API Center as the catalog and governance plane for APIs, tools, versions, definitions, environments, deployments, and MCP servers so agent builders discover approved capabilities instead of ungoverned endpoints.1112## When to invoke1314- "Create an API Center catalog for our agent tools."15- "Govern OpenAPI definitions and MCP servers for agent builders."16- "Design API standards and linting with Azure API Center."17- "Make backend APIs discoverable for an agentic platform."1819## Inputs2021Use `$ARGUMENTS` as the governance scenario: API families, tool types, MCP servers, environments, required metadata, linter standards, consumers, and discovery experience. If the current Azure API Center feature set matters, verify it before stating final design.2223## Prerequisites and context2425- Confirm current API Center capabilities, including MCP registration, linting rules, portal features, and extension support, on Microsoft Learn before committing a design.26- Do not assert a feature without a source when the platform capability is time-sensitive.27- Pair API Center with API Management only when runtime enforcement is in scope; API Center itself is the inventory and governance plane.2829## Core concepts3031| Concept | Purpose | Design questions |32| --- | --- | --- |33| API | Logical entry for a product, backend, tool, or capability. | Who owns it? What domain does it serve? |34| Version | Specific version of an API. | What is the lifecycle stage and compatibility policy? |35| Definition | Contract, typically an OpenAPI document. | Is it linted, complete, and linked to a version? |36| Environment | Runtime environment such as Azure API Management or a Kubernetes cluster. | Is it dev, staging, production, or sandbox? |37| Deployment | Runtime location where a version is available. | Which environment, gateway, base URL, and owner apply? |38| Metadata | Custom governance properties. | Which fields are required for compliance and reporting? |39| MCP server | Tool server agents can discover and call. | Is it approved, owned, documented, and secured? |4041## Governance model4243| Governance need | API Center mechanism | Minimum metadata |44| --- | --- | --- |45| Ownership | Required custom metadata | owner, team, support contact. |46| Data sensitivity | Required custom metadata and review workflow | classification, PII, retention, region. |47| Lifecycle | Version and metadata | stage, deprecation date, replacement API. |48| Security standards | Linter and required fields | auth type, scopes, network exposure. |49| Discoverability | Portal or VS Code extension | description, tags, domain, examples. |50| Agent tool reuse | OpenAPI or MCP registration | tool purpose, side effects, rate limits, safety notes. |5152## Procedure53541. Model the catalog. Define metadata schema first: owner, classification, lifecycle stage, data sensitivity, cost center, support path, and allowed consumers.552. Register APIs and tools. Import OpenAPI definitions for backend APIs and HTTP tools. Register MCP servers so agents can discover them through the governed catalog.563. Link environments and deployments. Connect Azure API Management instances and other runtimes so API Center reflects where each API version actually runs.574. Govern definitions. Apply the API Center linter and required metadata. Reject or flag definitions that miss security, naming, versioning, or documentation standards.585. Publish discovery. Expose the API Center portal or VS Code extension to agent builders with filters for approved tools, environments, and lifecycle stage.596. Connect runtime enforcement. Use APIM AI gateway for authentication, token limits, semantic cache, and load balancing when the cataloged API is used at runtime.6061## Platform fit6263```text64Backend APIs / Tools / MCP servers65 | register definitions and metadata66 Azure API Center (inventory + governance + discovery)67 | reference governed APIs68 Azure API Management (runtime AI gateway: authN, token limit, cache)69 |70 Agents (Foundry, Container Apps) select and call governed tools71```7273## Related primitives7475| Name | Type | Use it when |76| --- | --- | --- |77| `apim-ai-gateway` | skill | You need runtime enforcement, authN, token limits, cache, routing, and metrics. |78| `foundry-agent-blueprint` | skill | Agents need to consume cataloged APIs as OpenAPI or MCP tools. |79| `azure-agentic-architecture-patterns` | skill | You need architecture guidance for tools and MCP boundaries. |8081## Gotchas8283- **Catalogs fail without ownership**: require owner and support metadata before publishing an API or tool.84- **Discovery is not enforcement**: API Center does not replace API Management for runtime authentication or throttling.85- **Linting must run before registration is trusted**: imported OpenAPI alone does not guarantee secure or usable APIs.86- **MCP tool descriptions affect agent behavior**: document side effects, auth, and rate limits, not just endpoints.8788## Output template8990```markdown91## Azure API Center governance design9293**Scope:** <APIs, tools, MCP servers, or platform>9495| Catalog item | Definition source | Required metadata | Environment/deployment | Governance check |96| --- | --- | --- | --- | --- |97| <API or tool> | <OpenAPI, MCP, manual> | <owner, classification, lifecycle> | <dev/stage/prod runtime> | <linter/approval> |9899### Discovery model100- Portal or extension: <audience and filters>101- Approved tool criteria: <criteria>102103### Runtime handoff104- API Management/APIM AI gateway: <when used>105```106107## Quality gate108109- [ ] Current API Center capabilities are verified when feature specificity matters.110- [ ] API, Version, Definition, Environment, Deployment, Metadata, and MCP server concepts are mapped where relevant.111- [ ] Required metadata covers owner, classification, lifecycle, data sensitivity, and support path.112- [ ] OpenAPI definitions and MCP servers have governance checks before discovery.113- [ ] Runtime concerns are handed to API Management or `apim-ai-gateway` instead of overstating API Center.114- [ ] Agent builders have a clear discovery path for approved APIs and tools.115116## References117118- [Azure API Center](https://learn.microsoft.com/azure/api-center/)119- [Register APIs in API Center](https://learn.microsoft.com/azure/api-center/register-apis)120- [API governance and linting](https://learn.microsoft.com/azure/api-center/enable-api-analysis-linting)121- [API Center and API Management](https://learn.microsoft.com/azure/api-center/)
Run npx skillmds@latest add paulasilvatech/azure-api-center in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.
Design Azure API Center as the enterprise inventory and governance plane for APIs, agent tools, OpenAPI definitions, environments, deployments, metadata, linting, and MCP server discovery. Use when building an API or tool catalog, enforcing API standards, registering MCP servers, or making approved tools discoverable to agent builders. It is listed under Product & Planning on SkillMD.
This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.
This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.
Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.
paulasilvatech (@paulasilvatech) published this skill. Their other Agent Skills are listed on their SkillMD profile.
paulasilvatech