ARM MCP Server: Um Catálogo de 24 PoCs para Governança, FinOps e SRE no Azure

ARM MCP Server: Um Catálogo de 24 PoCs para Governança, FinOps e SRE no Azure

TL;DR: A Microsoft lançou o ARM MCP Server, um servidor remoto MCP que expõe seis ferramentas para agentes de IA interagirem com o Azure via Resource Graph (leitura) e ARM templates (escrita). Um catálogo público de 24 PoCs mostra aplicações reais em governança, FinOps, platform engineering e SRE. Três padrões emergem: agentes read-only entregam 80% do valor com 5% do risco; agentes com escrita exigem gating triplo; e o loop "what changed" é a funcionalidade matadora. Para empresas brasileiras, a mensagem principal é começar pelos PoCs read-only, como o Reliability Posture Scorecard (SRE-PoC-5), que substitui revisões semestrais por scorecards semanais sem risco de deploy.

Introdução

O Azure Resource Manager MCP Server é um servidor remoto Model Context Protocol que dá a agentes de IA acesso de primeira classe às operações de infraestrutura do Azure. Seis ferramentas formam uma superfície pequena, mas o ARM e o Azure Resource Graph não são planos de controle pequenos. Para explorar o que essa superfície pode suportar na prática, construímos o arm-mcp-poc-catalog: 24 provas de conceito autocontidas cobrindo governança empresarial, FinOps, platform engineering e Site Reliability Engineering.

Este post tem duas partes. A Parte 1 resume o que o ARM MCP Server oferece. A Parte 2 apresenta o catálogo e como usá-lo.

O que o ARM MCP Server oferece de diferente?

Arquitetura

O ARM MCP Server é um servidor MCP remoto hospedado em https://mcp.management.azure.com. Não há container para executar, sidecar para implantar ou service principal para gerenciar. Cada operação executa no contexto do usuário azure logado — as permissões efetivas do agente são exatamente as permissões efetivas do humano, tanto para leituras (ARG) quanto para escritas (deployments de ARM template). As atribuições de Azure Policy se aplicam de forma idêntica.

As seis ferramentas

#	Tool	Half	Purpose
1	generate_query	Read	Traduz uma pergunta em linguagem natural para KQL do Azure Resource Graph.
2	validate_query	Read	Valida estaticamente uma consulta ARG antes da execução.
3	execute_query	Read	Executa uma consulta ARG no escopo do usuário logado.
4	create_template_deployment	Write	Submete um ARM template para um resource group alvo.
5	get_arm_template_deployment_status	Write	Polla o progresso, outputs e erros de um deployment.
6	cancel_arm_template_deployment	Write	Aborta um deployment em andamento.

O conjunto de ferramentas se divide claramente em metade de leitura (Azure Resource Graph) e metade de escrita (Azure Resource Manager). As duas metades se compõem: um agente pode ler o estado atual do parque, decidir o que mudar, fazer deploy de um template e acompanhar o resultado, tudo em uma única conversa.

Por que isso importa

Três propriedades tornam o ARM MCP Server qualitativamente diferente de abordagens anteriores do tipo "Azure SDK em uma função":

1. Herança de identidade. O agente opera como o usuário. Não há credencial compartilhada, service principal superprivilegiado ou caminho de escalação de "o agente pode ler isso" para "o agente pode escrever aquilo".
2. Leitura em todo o tenant em uma única consulta. O Azure Resource Graph indexa todos os tipos de recurso em todas as subscriptions que o usuário pode ver. Uma única chamada execute_query pode retornar todas as contas de storage do tenant, ou todos os IPs públicos, ou todas as VMs por SKU, em segundos.
3. Superfície de escrita determinística. ARM templates são declarativos, idempotentes e auditáveis. Cada create_template_deployment produz um correlation ID e uma entrada no activity log. O agente herda tudo isso de graça.

Juntas, essas propriedades deslocam a pergunta prática de "podemos deixar um agente tocar nossa nuvem?" para "qual é a coisa mais útil a construir sobre essas seis ferramentas?" Essa é a pergunta que o catálogo de PoCs tenta responder.

O Catálogo de PoCs

O arm-mcp-poc-catalog é um repositório público contendo 24 agentes de prova de conceito, organizados em dois lotes de 12. Cada PoC é um workspace VS Code autocontido com sua própria persona de agente, skill determinístico, queries ARG pré-definidas, templates de saída congelados e stubs de ARM template quando aplicável. Cada pasta de PoC contém um README.md, um diretório runbooks/ com um template de escopo versionado e um arquivo de valores gitignorado, além da definição do agente, regras e templates de saída.

O contrato de determinismo

Antes de percorrer o catálogo, uma decisão de design merece destaque porque aparece em todos os PoCs. A ferramenta generate_query do ARM MCP Server é não determinística: o mesmo prompt pode produzir KQL ligeiramente diferente em invocações distintas, o que gera conjuntos de resultados diferentes, o que produziria ações de remediação diferentes em um agente recorrente.

Para tornar esses PoCs seguros para uso repetido (relatórios semanais, playbooks de plantão, gates de pré-deploy), cada PoC segue um contrato de cinco regras:

1. Queries ARG são lidas literalmente de um arquivo rules.yaml, nunca criadas pelo LLM em tempo de execução.
2. Cada chamada de query é validate_query seguido de execute_query. Validações com falha são marcadas como INVALID e o agente não tenta novamente nem reescreve.
3. Filtros de escopo (IDs de subscription, nomes de resource group) são substituídos por string a partir de um arquivo de valores separado.
4. A saída é um template markdown congelado com slots {{placeholder}}. Sem paráfrase pelo modelo.
5. Os run IDs seguem <POC-PREFIX>-{YYYYMMDD}-{scope}-{sha256(rules.yaml)[:8]}, então entradas idênticas produzem IDs idênticos.

A ferramenta generate_query ainda é útil, mas como auxílio em tempo de desenvolvimento para redigir o KQL que será commitado no rules.yaml, não como etapa de runtime em um agente recorrente.

Catálogo: PoCs Empresariais (governança, FinOps, platform)

#	PoC	Primary tools	What it does
1	Tag Hygiene Czar	Read + Write	Encontra recursos sem tags obrigatórias, gera um ARM template de correção e faz deploy mediante aprovação.
2	Blast Radius Analyzer	Read + What-if	Pré-deploy: cruza um ARM template com o estado atual para prever impacto create/modify/replace/delete.
3	Cost Driver Finder	Read	Revela os principais recursos geradores de custo por região/proprietário/workload usando topologia ARG e tags.
4	Golden Path Provisioner	Read + Write	Provisionamento por template de padrões de workload com defaults cientes de políticas.
5	IaC Drift Detector	Read	Compara o estado implantado com uma baseline ARM/Bicep armazenada em Git e reporta drift.
6	Incident Responder	Read + Write	Avaliação de impacto em todo o parque para um incidente declarado, com deploys de remediação opcionais.
7	Policy What-If	Read	Simula uma atribuição de Azure Policy proposta contra recursos atuais para prever negações.
8	Estate Cartographer	Read	Gera um mapa topológico (recursos, dependências, ownership) para todo o tenant a partir do ARG.
9	ARM Template Fixer	Read + Write	Diagnostica um deployment com falha, propõe um template corrigido e faz redeploy mediante aprovação.
10	Crown-Jewels Security	Read	Identifica o pequeno conjunto de recursos de alto valor (Key Vaults, bancos de produção, identidades) e sua exposição.
11	FinOps Rightsizer	Read	Recomenda downgrades de SKU para recursos de computação e dados subutilizados.
12	ChatOps Bot	Read + Write	Wrapper amigável para Slack/Teams expondo um subconjunto curado de verbos do agente para não engenheiros.

Catálogo: PoCs SRE (resposta a incidentes, segurança de mudanças, confiabilidade)

#	PoC	Primary tools	What it does
1	Incident Triage	Read + Cancel	"Primeiros 60 segundos": feed de mudanças para o escopo afetado, com cancelamento com um clique para deploys em andamento.
2	Change Freeze Enforcer	Read + Write gate	Intercepta deploys durante janelas de congelamento; exige justificativa break-glass registrada em ticketing.
3	Pre-flight Safety	Read	Bateria de verificações de saúde/dependência/capacidade antes de qualquer deploy em produção.
4	Auto Rollback	Write + Cancel	Observa um deploy; em caso de falha ou violação de health gate, cancela e aplica o último template bom conhecido.
5	Reliability Posture Scorecard	Read	Pontuação ponderada de ~15 regras de confiabilidade (zone redundancy, geo-replication, soft-delete, etc.) em um escopo.
6	SLO Deployment Gate	Read	Bloqueia deploys quando o error budget do serviço alvo está esgotado.
7	Capacity / Quota Guardian	Read	Acompanha o headroom de quota de subscription/região e alerta antes que deploys o excedam.
8	Blast Radius Simulator	Read	Simulação de dependência: "e se eu drenar essa AZ?" ou "e se esse RG sumir?".
9	Stuck Deployment Janitor	Read + Cancel	Encontra deployments presos em Running além do SLA, resume e opcionalmente cancela.
10	Runbook Executor	Write	Runbooks parametrizados com ARM template para operações rotineiras (rotação de certificados, eventos de escala, etc.).
11	Post-Incident Reconstructor	Read	Reconstrói a linha do tempo exata de mudanças de recursos durante uma janela de incidente para o postmortem.
12	Weekly Cleanup PRs	Read + Write	Gera PRs para limpeza de baixo risco (NICs órfãs, IPs públicos não utilizados, recursos de dev sem tag).

SRE-PoC-5 (Reliability Posture Scorecard) é a implementação de referência. Leia-o primeiro para entender o contrato de determinismo de ponta a ponta: KQL literal, validate depois execute, template congelado, run ID determinístico e nenhum risco de deploy.

Padrões que emergiram dos 24 PoCs

Três padrões se mostraram repetidamente e merecem destaque.

Padrão 1: Agentes read-only entregam 80% do valor com 5% do risco. Relatórios de hygiene de tags, análise de blast radius, descoberta de drivers de custo, postura de segurança crown-jewels, scorecard de confiabilidade, reconstrução pós-incidente: nenhum deles precisa da metade de escrita da API. Eles transformam o ARG em uma camada de consulta que os humanos existentes podem interrogar em inglês (ou português, via KQL). A maioria dos times deveria começar por aqui.

Padrão 2: Agentes com capacidade de escrita precisam de três coisas, não uma. Cada PoC com deploy no catálogo protege create_template_deployment atrás de (a) um verbo explícito do usuário como apply ou remediate, (b) uma etapa de confirmação que mostra o template resolvido e o escopo, e (c) uma flag global de congelamento na configuração de escopo que é verificada antes de qualquer outra lógica executar. O change-freeze enforcer (SRE-PoC-2) é ele mesmo um dos PoCs e pode ser conectado na frente de qualquer outro agente com capacidade de escrita.

Padrão 3: O loop "what changed" é a funcionalidade matadora. O ARG pode responder "como está meu parque agora?" em segundos. Combine isso com polling de status de deployment e você obtém "o que mudou, quem mudou e ainda está em andamento?" – a base para triagem de incidentes, reconstrução pós-incidente, auto-rollback e o stuck-deployment janitor. Nada disso era prático antes do MCP Server condensar a pilha de auth, ARG e ARM client em uma única superfície de ferramentas.

Como começar com qualquer PoC

1. Instale o ARM MCP Server uma vez: abra https://aka.ms/JoinARMMCP no VS Code e faça login.
2. Verifique o acesso ao Azure com az login. PoCs somente leitura precisam de Reader + Resource Graph Reader no escopo alvo. PoCs com deploy precisam adicionalmente de Contributor nos resource groups alvo.
3. Clone o catálogo: git clone https://github.com/jvargh/arm-mcp-poc-catalog.git.
4. Abra uma pasta de PoC no VS Code como workspace. O arquivo .vscode/mcp.json declara o servidor ARM MCP no escopo do workspace e o inicia no primeiro uso do chat.
5. Configure o escopo: copie runbooks/<scope>.values.yaml.example para runbooks/<scope>.values.yaml e preencha o ID da subscription e os resource groups. O arquivo de valores é gitignorado.
6. Invoque o agente: veja o README.md de cada PoC para os verbos aceitos (tipicamente run, drilldown, remediate).

Spotlight: SRE-PoC-5, Reliability Posture Scorecard

Dos 24 PoCs do catálogo, o Reliability Posture Scorecard (SRE-PoC-5-Reliability-posture-scorecard/) é a implementação de referência. É o PoC mais simples que exercita o contrato de determinismo completo de ponta a ponta sem nenhum risco de deploy.

O que ele faz

O agente carrega um pacote fixo de regras de confiabilidade ponderadas do rules.yaml: verificações como App Services sem zone redundancy, SQL databases sem geo-replication, Storage accounts sem soft delete e Key Vaults sem purge protection. Para cada regra, ele chama validate_query e depois execute_query contra o escopo configurado, agrega falhas por workload (resource group por padrão, ou qualquer tag) e calcula uma pontuação:

score = max(0, 100 - Σ weight of failed rules)

A saída é um relatório markdown congelado com um run ID determinístico no formato RPS-{YYYYMMDD}-{scope}-{sha256(rules.yaml)[:8]. Execute duas vezes seguidas contra o mesmo escopo e você obtém saída byte-idêntica. Execute na semana seguinte e qualquer diferença é uma mudança real no parque.

Por que ARM MCP é uma boa escolha

• Uma ferramenta cobre todos os tipos de recurso. Regras de confiabilidade abrangem App Services, SQL, Storage, Key Vault, NSGs e mais. O ARG expõe todos eles como colunas na mesma linguagem de consulta; um pacote de 12 regras são 12 strings KQL em vez de 12 SDK clients.
• Amplitude de tenant em uma única ida e volta. Um único execute_query inspeciona todos os recursos de um tipo no escopo em segundos, sem loop de paginação e sem malabarismos de rate limit.
• Herança de identidade mantém a pontuação honesta. O agente só pode pontuar o que o operador pode ver. Nenhum service principal de scoring precisa de leitura em todo o tenant.
• Somente leitura, portanto seguro para implantar primeiro. Reader + Resource Graph Reader é todo o requisito de permissão, o que o torna o ponto de prova natural antes de introduzir qualquer agente com capacidade de deploy.

Benefícios para resiliência

• Contínuo, não episódico. Substitui a revisão semestral do Well-Architected Review por uma execução semanal que produz uma pontuação de 0 a 100 por workload e uma linha de tendência em exports/scorecard-trend.csv.
• Diffs reais, não drift de consulta. Run IDs determinísticos significam que uma pontuação que vai de 78 para 64 é uma regressão real, não um humor diferente do modelo.
• Gate de pré-lançamento. O mesmo pacote de regras roda em dev, staging e prod, então zone redundancy ou configuração de backup ausente é capturada antes da promoção, não depois.
• Evidência para postmortem. O scorecard da manhã está em disco com as regras exatas que falharam e os IDs dos recursos, pronto para ser citado diretamente na análise.
• Barato para estender. Adicionar uma regra é um bloco de YAML (KQL literal, peso, severidade, dica de remediação). Sem alterações no código do agente, sem engenharia de prompt.

O passo a passo completo, incluindo o fluxo ponta a ponta desde o prompt do chat até o relatório renderizado, está no README do próprio PoC.

Conclusão

As seis ferramentas do ARM MCP Server são deliberadamente pequenas. A engenharia interessante está na forma como você as envolve: como trocar a flexibilidade do modelo pelo determinismo que um agente recorrente precisa, como proteger escritas e como compor leituras ARG com deploys ARM para responder às perguntas que um operador humano realmente faz.

O arm-mcp-poc-catalog é um conjunto de respostas para essas perguntas. Vinte e quatro PoCs são um menu inicial, não um roadmap. Escolha o mais próximo de um problema que seu time tem na segunda-feira de manhã, leia seu README.md, execute contra uma subscription não produtiva e decida se a forma se encaixa antes de se comprometer a construir a sua própria.

Se você construir algo interessante em cima disso, abra uma issue ou um PR no repositório do catálogo.

Referências

• Introducing the Azure Resource Manager MCP Server, Steven Bucher, Azure Governance and Management Blog
• Azure-Resource-Manager-MCP on GitHub: repositório e documentação oficial do servidor
• arm-mcp-poc-catalog: o catálogo de 24 PoCs descrito neste post
• ARM MCP Server install link

Perguntas Frequentes

• O ARM MCP Server substitui o Azure SDK ou ferramentas como Terraform?

  • Não. Ele é uma camada de interface para agentes de IA operarem diretamente sobre o Azure Resource Manager e o Azure Resource Graph. Ferramentas de IaC tradicionais continuam sendo a base para provisionamento e gerenciamento de estado; o MCP Server adiciona capacidade de consulta e escrita orientada por linguagem natural, com determinismo via templates ARM.

• Quais permissões são necessárias para usar os PoCs do catálogo?

  • PoCs somente leitura exigem Reader + Resource Graph Reader no escopo alvo. PoCs com capacidade de deploy exigem adicionalmente Contributor nos resource groups. A identidade do usuário logado é herdada pelo agente, evitando service principals sobre-privilegiados.

• O que é o contrato de determinismo e por que ele é importante?

  • Para garantir que agentes recorrentes (relatórios semanais, playbooks de plantão) produzam resultados consistentes, os PoCs seguem cinco regras: queries KQL fixas em rules.yaml, validação antes de execução, substituição de escopo via arquivo de valores, saída em template congelado e IDs de execução determinísticos. Isso elimina variações causadas por LLMs não determinísticos.

• Como o Reliability Posture Scorecard (SRE-PoC-5) pode ajudar times de SRE?

  • O PoC gera um scorecard semanal (0 a 100) com base em ~15 regras de confiabilidade (zone redundancy, geo-replication, soft-delete, purge protection). Ele substitui revisões trimestrais do Well-Architected Review por uma execução contínua, detecta regressões reais e serve como pre-deploy gate, tudo sem riscos de escrita.

• Posso usar o ARM MCP Server em produção imediatamente?

  • Sim, o servidor é remoto e não requer containers nem service principals. No entanto, recomenda-se começar com PoCs read-only (como o Reliability Scorecard ou o Crown-Jewels Security) para validar o modelo de identidade e a superfície de consulta antes de habilitar agentes com deploy. O catálogo oferece 24 pontos de partida seguros.

---

Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.