Enterprise API Marketplace and GovernanceMarketplace Corporativo de APIs e GovernançaMarketplace Corporativo de APIs y Gobernanza
A unified control plane for governing APIs, VS Code extensions, MCP servers, and Copilot agents: inventory, linting, policy enforcement, and air-gapped deployment.Um plano de controle unificado para governar APIs, extensões VS Code, servidores MCP e agentes Copilot: inventário, linting, aplicação de políticas e deploy air-gapped.Un plano de control unificado para gobernar APIs, extensiones VS Code, servidores MCP y agentes Copilot: inventario, linting, aplicación de políticas y deploy air-gapped.
Read the article below, present the deck, or go deep with the playbook. The same thesis, calibrated to how you need to engage with it. Leia o artigo abaixo, apresente o deck ou aprofunde com o playbook. A mesma tese, calibrada para a forma como você precisa engajar. Lee el artículo abajo, presenta el deck o profundiza con el playbook. La misma tesis, calibrada para cómo necesitas interactuar.
Five pillars, twelve sections.Cinco pilares, doze seções.Cinco pilares, doce secciones.
The runbook is organized in five pillars. Inventory grounds the API catalog. Marketplace governs every extension. AI tooling controls MCP, Copilot extensions, and agents. Security threads identity and audit through every hop. Operations turns it into Day 0, Day 1, Day 2 sequences.O runbook está em cinco pilares. Inventário ancora o catálogo de API. Marketplace governa cada extensão. AI tooling controla MCP, extensões Copilot e agentes. Segurança costura identidade e auditoria. Operações vira sequência Dia 0, Dia 1, Dia 2.El runbook está en cinco pilares. Inventario ancla el catálogo de API. Marketplace gobierna cada extensión. AI tooling controla MCP, extensiones Copilot y agentes. Seguridad atraviesa identidad y auditoría. Operaciones lo convierte en secuencia Día 0, Día 1, Día 2.
API inventoryInventário de APIsInventario de APIs
Sections 3 and 4. Azure API Center as the single organizational register. Versions, definitions, environments, custom metadata, linting, shadow API discovery, APIM sync, and the VS Code extension that brings it into the IDE.Seções 3 e 4. Azure API Center como registro organizacional único. Versões, definições, ambientes, metadata, linting, descoberta de shadow API, sync APIM, e extensão VS Code que traz para o IDE.Secciones 3 y 4. Azure API Center como registro organizacional único. Versiones, definiciones, entornos, metadata, linting, descubrimiento de shadow API, sync APIM, y extensión VS Code que lo lleva al IDE.
Internal marketplaceMarketplace internoMarketplace interno
Sections 5 and 6. The VS Code Private Marketplace deployed as a stateless container. Internal extension publishing. Public extension rehosting. AllowedExtensions policy via Group Policy and Intune. Recommended enterprise catalog.Seções 5 e 6. VS Code Private Marketplace como container stateless. Publicação de extensão interna. Rehosting de extensões públicas. Policy AllowedExtensions via GPO e Intune. Catálogo enterprise recomendado.Secciones 5 y 6. El VS Code Private Marketplace como contenedor sin estado. Publicación de extensión interna. Rehosting de extensiones públicas. Policy AllowedExtensions via GPO e Intune. Catálogo enterprise recomendado.
AI tooling layerCamada de tooling IACapa de tooling IA
Sections 7 and 8. MCP servers, GitHub Copilot extensions, custom agents, prompt files, and skills. Distribution at scale via .vscode/mcp.json and .github/agents/. Approval process, scope, and the AI artifact governance loop.Seções 7 e 8. Servidores MCP, extensões Copilot, agentes customizados, prompts e skills. Distribuição em escala via .vscode/mcp.json e .github/agents/. Processo de aprovação, escopo, governança de artefato IA.Secciones 7 y 8. Servidores MCP, extensiones Copilot, agentes custom, prompts y skills. Distribución a escala vía .vscode/mcp.json y .github/agents/. Proceso de aprobación, alcance, gobernanza del artefacto IA.
Security architectureArquitetura de segurançaArquitectura de seguridad
Section 9. Threat model for the integrated platform. Extension supply chain. API security in API Center. MCP trust model. Copilot data privacy. Audit and compliance logging that satisfies regulated industries.Seção 9. Modelo de ameaça da plataforma integrada. Supply chain de extensão. Segurança de API no API Center. Modelo de confiança MCP. Privacidade de dados Copilot. Auditoria e logging de compliance.Sección 9. Modelo de amenaza de la plataforma integrada. Supply chain de extensión. Seguridad de API en API Center. Modelo de confianza MCP. Privacidad de datos Copilot. Auditoría y logging de cumplimiento.
Operations and governanceOperações e governançaOperaciones y gobernanza
Sections 10 to 12. Integration scenarios for full flow, air-gapped, and regulated industries. Day 0, Day 1, Day 2 runbook. Ownership matrix, artifact approval process, review cadence. The complete governance framework.Seções 10 a 12. Cenários integrados, air-gapped e regulados. Runbook Dia 0, Dia 1, Dia 2. Matriz de responsabilidades, processo de aprovação de artefato, cadência de revisão. Framework completo.Secciones 10 a 12. Escenarios integrados, air-gapped y regulados. Runbook Día 0, Día 1, Día 2. Matriz de responsabilidades, proceso de aprobación de artefacto, cadencia de revisión. Framework completo.
The problem: sprawl without a control plane
Enterprise development environments accumulate risk in three compounding categories, and most organizations have no single surface from which to address all three at once.
Security is the first pressure point. Extensions and MCP servers installed ad hoc, outside any approval process, may exfiltrate code or credentials. The IDE becomes the soft target. It sits inside the perimeter, has deep access to the filesystem and network, and is rarely covered by the same threat model as production infrastructure.
Compliance is the second. Sensitive data reaches AI model APIs without authorization. Audit teams cannot prove what left the environment, when it left, or to whom it was sent. As AI-assisted development becomes standard, the compliance gap widens faster than manual governance can close it.
Productivity is the third, and often the least intuitive risk. When developers cannot discover what APIs exist, they rebuild. They reach for deprecated endpoints. They burn hours configuring tooling that already exists somewhere in the organization. Shadow APIs proliferate. The cost of duplication compounds quietly.
These three risks are not independent. Unvetted tooling drives shadow API usage. Shadow API usage produces data-flow gaps. Data-flow gaps create compliance exposure. A control plane that addresses only one category leaves the other two open.
Architecture: three hubs, one workstation
The integrated architecture closes all three loops through three specialized hubs. They converge on a single developer workstation, VS Code (Desktop) with GitHub Copilot, protected by a shared policy layer that enforces AllowedExtensions, RBAC, identity, and audit logging.
Hub 01: Azure API Center is the authoritative inventory for every API in the organization. Every version, every definition, every environment and deployment is registered here. CLI and CI/CD pipelines feed registration automatically. Custom metadata fields capture ownership and classification, making the catalog both a discovery surface and a governance record. Spectral linting rules run at registration time, blocking APIs that violate organizational design standards before they ship. Dev Proxy discovery surfaces undocumented APIs that developers are already calling, bringing shadow APIs into the catalog before they accumulate as production debt. Azure API Management feeds the catalog upstream automatically: gateway truth and inventory truth converge into one record.
Hub 02: VS Code Private Marketplace gives enterprises a curated extension catalog under their own control. The architecture is intentionally stateless: a container with object storage backing that can be deployed in any region, serving internal extensions and rehosted public ones. Air-gap deployments keep developers productive without any network egress to the public marketplace. Policy enforcement uses Group Policy on Windows and Intune on macOS and managed devices. A bootstrap install ensures that every developer opens a curated VS Code on day one, not a raw, unmanaged installation.
Hub 03: Copilot Governance extends the same design principle to AI artifacts. MCP servers are registered in .vscode/mcp.json and distributed through the marketplace, with a documented trust model per server. Copilot extensions are reviewed for data flow and allowlisted at the GitHub Enterprise organization level. Custom agents live in .github/agents/ files, version-controlled alongside the code they govern and reviewed in the same PR pipeline. Prompt files and skills are curated in a shared repository with an approval workflow before they reach the developer fleet.
The policy layer sits across all three hubs. Nothing reaches the developer workstation unvetted.
Deployment scenarios
The same architecture supports three deployment shapes, making it applicable across cloud-connected enterprises, restricted networks, and regulated industries.
| Scenario | Context | Key characteristics |
|---|---|---|
| A · Full integrated | Cloud-connected enterprise | API design in VS Code, registered to API Center, synced to APIM, consumed from the IDE. Marketplace and Copilot fully online. |
| B · Air-gapped | No public network egress | Marketplace rehosts public extensions on internal storage. MCP servers run on internal endpoints. Copilot Enterprise on private link. |
| C · Regulated | Finance, public sector | Audit log retention, classification labels, signed artifacts, identity propagation per request. Auditor independent from platform. |
The regulated scenario adds depth to the compliance posture: audit log retention, classification labels on artifacts, signed binaries, and per-request identity propagation ensure that every action is attributable and every artifact is traceable.
From Day 0 to Day 2
The operational sequence follows a clear progression. Day 0 establishes the platform: API Center provisioned, Private Marketplace deployed, Copilot governance policies configured, identity and RBAC wired up. Day 1 onboards the developer fleet: bootstrap installs distribute curated VS Code instances, API registrations flow through CI/CD, MCP server trust models are documented. Day 2 is steady-state operations: linting blocks non-compliant APIs at the gate, Dev Proxy surfaces shadow APIs before they reach production, audit logs give compliance teams continuous visibility.
The design principle
The three hubs share one design principle. Each artifact category (APIs, extensions, AI tools) gets its own governance contract, but all contracts are enforced through the same control plane. The artifacts change. The contract does not.
Governance built this way is not a compliance layer bolted onto an existing development environment. It is the platform. Build it once, and every new artifact category (whatever comes after MCP servers and Copilot agents) inherits the same enforcement surface automatically.
O problema: dispersão sem plano de controle
Ambientes corporativos de desenvolvimento acumulam risco em três categorias que se compõem, e a maioria das organizações não tem uma superfície única a partir da qual endereçar as três ao mesmo tempo.
Segurança é o primeiro ponto de pressão. Extensões e servidores MCP instalados ad hoc, fora de qualquer processo de aprovação, podem exfiltrar código ou credenciais. O IDE vira o alvo fácil. Está dentro do perímetro, tem acesso profundo ao sistema de arquivos e à rede, e raramente é coberto pelo mesmo modelo de ameaça que a infraestrutura de produção.
Compliance é o segundo. Dado sensível chega às APIs de modelo IA sem autorização. A auditoria não consegue provar o que saiu do ambiente, quando saiu ou para quem foi enviado. À medida que o desenvolvimento assistido por IA se torna padrão, a lacuna de compliance se alarga mais rápido do que a governança manual consegue fechar.
Produtividade é o terceiro, e muitas vezes o risco menos intuitivo. Quando o dev não descobre o que existe, ele reconstrói. Usa endpoints depreciados. Queima horas configurando ferramentas que já existem em algum lugar da organização. Shadow APIs proliferam. O custo da duplicação cresce silenciosamente.
Os três riscos não são independentes. Tooling sem vetting impulsiona o uso de shadow APIs. O uso de shadow APIs produz lacunas de fluxo de dados. Lacunas de fluxo de dados geram exposição de compliance. Um plano de controle que endereça apenas uma categoria deixa as outras duas abertas.
Arquitetura: três hubs, uma workstation
A arquitetura integrada fecha todos os três ciclos por meio de três hubs especializados. Eles convergem para uma única workstation de desenvolvimento, VS Code (Desktop) com GitHub Copilot, protegida por uma camada de política compartilhada que aplica AllowedExtensions, RBAC, identidade e log de auditoria.
Hub 01: Azure API Center é o inventário autoritativo para cada API da organização. Cada versão, cada definição, cada ambiente e deployment é registrado aqui. Pipelines de CLI e CI/CD alimentam o registro automaticamente. Campos de metadata customizada capturam ownership e classificação, tornando o catálogo tanto uma superfície de descoberta quanto um registro de governança. Regras Spectral de linting executam no momento do registro, bloqueando APIs que violam padrões organizacionais antes do deploy. A descoberta via Dev Proxy traz à superfície APIs não documentadas que os devs já estão chamando, incorporando shadow APIs ao catálogo antes que acumulem dívida em produção. O Azure API Management alimenta o catálogo upstream automaticamente: verdade do gateway e verdade do inventário convergem em um único registro.
Hub 02: VS Code Private Marketplace oferece às empresas um catálogo curado de extensões sob seu próprio controle. A arquitetura é intencionalmente stateless: um container com object storage de apoio que pode ser implantado em qualquer região, servindo extensões internas e extensões públicas rehosted. Deploys air-gap mantêm os devs produtivos sem qualquer egress para o marketplace público. A aplicação de políticas usa Group Policy no Windows e Intune em macOS e dispositivos gerenciados. Um bootstrap install garante que todo desenvolvedor abra um VS Code curado no primeiro dia, não uma instalação bruta e não gerenciada.
Hub 03: Governança Copilot estende o mesmo princípio de design para artefatos de IA. Servidores MCP são registrados em .vscode/mcp.json e distribuídos pelo marketplace, com modelo de confiança documentado por servidor. Extensões Copilot são revisadas quanto ao fluxo de dados e adicionadas à allowlist no nível da organização GitHub Enterprise. Agentes customizados vivem em arquivos .github/agents/, versionados junto ao código que governam e revisados no mesmo pipeline de PR. Prompts e skills são curados em um repositório compartilhado com workflow de aprovação antes de chegarem à frota de desenvolvimento.
A camada de política abrange os três hubs. Nada chega à workstation do dev sem passar pelo processo de vetting.
Cenários de deploy
A mesma arquitetura suporta três formatos de deploy, tornando-a aplicável em empresas conectadas à nuvem, redes restritas e setores regulados.
| Cenário | Contexto | Características principais |
|---|---|---|
| A · Integrado completo | Empresa conectada à nuvem | Design de API no VS Code, registrado no API Center, sync para APIM, consumido no IDE. Marketplace e Copilot online. |
| B · Air-gapped | Sem egress público | Marketplace rehosting extensões públicas em storage interno. Servidores MCP em endpoints internos. Copilot Enterprise via private link. |
| C · Regulado | Financeiro, setor público | Retenção de log de auditoria, rótulos de classificação, artefatos assinados, propagação de identidade por request. Auditor independente. |
O cenário regulado adiciona profundidade à postura de compliance: retenção de log de auditoria, rótulos de classificação em artefatos, binários assinados e propagação de identidade por request garantem que toda ação seja atribuível e todo artefato seja rastreável.
Do Dia 0 ao Dia 2
A sequência operacional segue uma progressão clara. O Dia 0 estabelece a plataforma: API Center provisionado, Private Marketplace implantado, políticas de governança Copilot configuradas, identidade e RBAC conectados. O Dia 1 faz o onboarding da frota de desenvolvimento: bootstrap installs distribuem instâncias de VS Code curadas, registros de APIs fluem via CI/CD, modelos de confiança de servidores MCP são documentados. O Dia 2 é a operação em estado estável: linting bloqueia APIs não conformes no portão, Dev Proxy traz shadow APIs à superfície antes de chegarem à produção, logs de auditoria dão aos times de compliance visibilidade contínua.
O princípio de design
Os três hubs compartilham um princípio de design. Cada categoria de artefato (APIs, extensões, ferramentas de IA) recebe seu próprio contrato de governança, mas todos os contratos são aplicados pelo mesmo plano de controle. Os artefatos mudam. O contrato não.
Governança construída dessa forma não é uma camada de compliance colada sobre um ambiente de desenvolvimento existente. É a plataforma. Construa uma vez, e toda nova categoria de artefato (o que vier depois de servidores MCP e agentes Copilot) herda automaticamente a mesma superfície de aplicação.
El problema: dispersión sin plano de control
Los entornos de desarrollo empresariales acumulan riesgo en tres categorías que se componen, y la mayoría de las organizaciones no tienen una superficie única desde la cual abordar las tres al mismo tiempo.
Seguridad es el primer punto de presión. Las extensiones y servidores MCP instalados ad hoc, fuera de cualquier proceso de aprobación, pueden exfiltrar código o credenciales. El IDE se vuelve el blanco fácil. Está dentro del perímetro, tiene acceso profundo al sistema de archivos y a la red, y rara vez está cubierto por el mismo modelo de amenaza que la infraestructura de producción.
Cumplimiento es el segundo. Datos sensibles llegan a las APIs de modelo IA sin autorización. Los equipos de auditoría no pueden probar qué salió del entorno, cuándo salió ni a quién fue enviado. A medida que el desarrollo asistido por IA se convierte en estándar, la brecha de cumplimiento se amplía más rápido de lo que la gobernanza manual puede cerrarla.
Productividad es el tercero, y con frecuencia el riesgo menos intuitivo. Cuando el dev no descubre lo que existe, reconstruye. Usa endpoints deprecados. Quema horas configurando tooling que ya existe en algún lugar de la organización. Las shadow APIs proliferan. El costo de la duplicación crece silenciosamente.
Los tres riesgos no son independientes. El tooling sin revisión impulsa el uso de shadow APIs. El uso de shadow APIs produce brechas en el flujo de datos. Las brechas en el flujo de datos generan exposición de cumplimiento. Un plano de control que aborda solo una categoría deja las otras dos abiertas.
Arquitectura: tres hubs, una estación de trabajo
La arquitectura integrada cierra los tres ciclos a través de tres hubs especializados. Convergen en una única estación de trabajo de desarrollo, VS Code (Desktop) con GitHub Copilot, protegida por una capa de política compartida que aplica AllowedExtensions, RBAC, identidad y log de auditoría.
Hub 01: Azure API Center es el inventario autoritativo para cada API de la organización. Cada versión, cada definición, cada entorno y deployment se registra aquí. Los pipelines de CLI y CI/CD alimentan el registro automáticamente. Los campos de metadata personalizada capturan la propiedad y la clasificación, convirtiendo el catálogo tanto en una superficie de descubrimiento como en un registro de gobernanza. Las reglas de linting Spectral se ejecutan en el momento del registro, bloqueando APIs que violan estándares organizacionales antes del deploy. El descubrimiento vía Dev Proxy detecta APIs no documentadas que los devs ya están llamando, incorporando las shadow APIs al catálogo antes de que acumulen deuda en producción. Azure API Management alimenta el catálogo upstream automáticamente: la verdad del gateway y la del inventario convergen en un único registro.
Hub 02: VS Code Private Marketplace ofrece a las empresas un catálogo curado de extensiones bajo su propio control. La arquitectura es intencionalmente sin estado: un contenedor con object storage de respaldo que puede desplegarse en cualquier región, sirviendo extensiones internas y extensiones públicas rehospedadas. Los despliegues air-gap mantienen a los devs productivos sin ningún egress al marketplace público. La aplicación de políticas usa Group Policy en Windows e Intune en macOS y dispositivos gestionados. Un bootstrap install asegura que cada desarrollador abra un VS Code curado desde el primer día, no una instalación bruta y no gestionada.
Hub 03: Gobernanza Copilot extiende el mismo principio de diseño a los artefactos de IA. Los servidores MCP se registran en .vscode/mcp.json y se distribuyen a través del marketplace, con un modelo de confianza documentado por servidor. Las extensiones Copilot se revisan por flujo de datos y se agregan a la allowlist a nivel de la organización GitHub Enterprise. Los agentes custom viven en archivos .github/agents/, versionados junto al código que gobiernan y revisados en el mismo pipeline de PR. Los prompts y skills se curan en un repositorio compartido con workflow de aprobación antes de llegar a la flota de desarrollo.
La capa de política abarca los tres hubs. Nada llega a la estación de trabajo del dev sin pasar por la revisión.
Escenarios de despliegue
La misma arquitectura soporta tres formatos de deploy, haciéndola aplicable en empresas conectadas a la nube, redes restringidas e industrias reguladas.
| Escenario | Contexto | Características principales |
|---|---|---|
| A · Integrado completo | Empresa conectada a la nube | Diseño de API en VS Code, registrado en API Center, sync a APIM, consumido desde el IDE. Marketplace y Copilot online. |
| B · Air-gapped | Sin egress público | El marketplace rehospeda extensiones públicas en almacenamiento interno. Servidores MCP en endpoints internos. Copilot Enterprise vía private link. |
| C · Regulado | Finanzas, sector público | Retención de log de auditoría, etiquetas de clasificación, artefactos firmados, propagación de identidad por request. Auditor independiente. |
El escenario regulado añade profundidad a la postura de cumplimiento: retención de log de auditoría, etiquetas de clasificación en artefactos, binarios firmados y propagación de identidad por request garantizan que cada acción sea atribuible y cada artefacto sea trazable.
Del Día 0 al Día 2
La secuencia operacional sigue una progresión clara. El Día 0 establece la plataforma: API Center aprovisionado, Private Marketplace desplegado, políticas de gobernanza Copilot configuradas, identidad y RBAC conectados. El Día 1 hace el onboarding de la flota de desarrollo: los bootstrap installs distribuyen instancias de VS Code curadas, los registros de APIs fluyen vía CI/CD, los modelos de confianza de servidores MCP quedan documentados. El Día 2 es la operación en estado estable: el linting bloquea APIs no conformes en la puerta, Dev Proxy trae las shadow APIs a la superficie antes de que lleguen a producción, los logs de auditoría dan a los equipos de cumplimiento visibilidad continua.
El principio de diseño
Los tres hubs comparten un principio de diseño. Cada categoría de artefacto (APIs, extensiones, herramientas de IA) recibe su propio contrato de gobernanza, pero todos los contratos se aplican a través del mismo plano de control. Los artefactos cambian. El contrato no.
La gobernanza construida de esta forma no es una capa de cumplimiento añadida sobre un entorno de desarrollo existente. Es la plataforma. Constrúyela una vez, y cada nueva categoría de artefacto (lo que venga después de los servidores MCP y los agentes Copilot) hereda automáticamente la misma superficie de aplicación.
Three governance metrics, three sources.Três métricas de governança, três fontes.Tres métricas de gobernanza, tres fuentes.
Anchor every claim to a number that survives a security review. These three baselines tie back to API Center, the Private Marketplace policy, and Microsoft Purview.Ancore toda alegação a um número que sobreviva à revisão de segurança. Estes três baselines voltam ao API Center, à policy do Private Marketplace e ao Microsoft Purview.Ancla cada afirmación a un número que sobreviva a la revisión de seguridad. Estos tres baselines vuelven al API Center, la policy del Private Marketplace y Microsoft Purview.
Typical share of APIs that are running in production but missing from any register before API Center is connected to APIM. Defender for APIs and Application Insights surface the gap. Most teams underestimate this number by half until they run the discovery.Fatia típica de APIs rodando em produção mas ausentes de qualquer registro antes do API Center estar conectado ao APIM. Defender for APIs e Application Insights expõem a lacuna. A maioria dos times subestima esse número pela metade até rodar a descoberta.Porcentaje típico de APIs corriendo en producción pero ausentes de cualquier registro antes de conectar API Center al APIM. Defender for APIs y Application Insights exponen la brecha. La mayoría subestima ese número a la mitad hasta correr el descubrimiento.
Reference reduction observed when AllowedExtensions policy enforces the curated catalog. From the typical 150 distinct extensions across a developer base to roughly 12 vetted ones plus internal ones. The unblocked extensions are still installable on request, with traceable approval.Redução de referência observada quando a policy AllowedExtensions força o catálogo curado. Das típicas 150 extensões distintas na base para cerca de 12 vetadas mais internas. As bloqueadas continuam instaláveis sob pedido, com aprovação rastreável.Reducción de referencia observada cuando la policy AllowedExtensions fuerza el catálogo curado. De las típicas 150 extensiones distintas en la base a unas 12 vetadas más internas. Las bloqueadas siguen instalables a pedido, con aprobación rastreable.
When the four planes are wired together, every developer-facing surface produces a logged event into Microsoft Purview or the SIEM of choice. The audit trail is the difference between a regulated industry pilot that scales and one that gets revoked at the next external audit.Quando os quatro planos estão conectados, toda superfície voltada para o dev gera evento logado no Microsoft Purview ou no SIEM escolhido. A trilha de auditoria é a diferença entre um piloto em indústria regulada que escala e um que é revogado na próxima auditoria externa.Cuando los cuatro planos se conectan, cada superficie hacia el dev produce un evento loggeado en Microsoft Purview o el SIEM elegido. La traza de auditoría es la diferencia entre un piloto en industria regulada que escala y uno que es revocado en la próxima auditoría externa.
The sources behind the claims on this page. Every link is public and verifiable. As fontes por trás das afirmações desta página. Todos os links são públicos e verificáveis. Las fuentes detrás de las afirmaciones de esta página. Todos los enlaces son públicos y verificables.
- Microsoft Learn What is Azure API Center: centralized inventory and governance ↗
- Microsoft Learn Analyze APIs in your API center: Spectral linting and analysis ↗
- Microsoft Learn How to find shadow APIs with Dev Proxy and API Center ↗
- Microsoft Learn Link an Azure API Center to Azure API Management ↗
- VS Code Docs Enterprise extension management in Visual Studio Code ↗
- VS Code Docs Use MCP servers in Visual Studio Code ↗