A walkthrough of 24 proof-of-concept Copilot agents built on the Azure Resource Manager MCP Server, covering governance, FinOps, platform, and SRE workloads.
Introduction
The Azure Resource Manager MCP Server is a remote Model Context Protocol server that gives AI agents first-class access to Azure infrastructure operations. Six tools is a small surface area, but ARM and Azure Resource Graph are not small control planes. To explore what that surface area can support in practice, we built the arm-mcp-poc-catalog: 24 self-contained proof-of-concept agents spanning enterprise governance, FinOps, platform engineering, and Site Reliability Engineering.
This post is in two parts. Part 1 summarizes what the ARM MCP Server offers. Part 2 walks through the catalog and how to use it.
Part 1. What the ARM MCP Server Offers
Architecture
The ARM MCP Server is a remote MCP server hosted at https://mcp.management.azure.com. There is no container to run, no sidecar to deploy, and no service principal to manage. Every operation executes in the context of the signed-in Azure user, so the agent's effective permissions are exactly the human's effective permissions, for both reads (ARG) and writes (ARM template deployments). Azure Policy assignments apply identically.
The six tools
| # | Tool | Half | Purpose |
|---|---|---|---|
| 1 | generate_query | Read | Translate a natural-language ask into Azure Resource Graph KQL. |
| 2 | validate_query | Read | Statically validate an ARG query before execution. |
| 3 | execute_query | Read | Run an ARG query against the signed-in user's scope. |
| 4 | create_template_deployment | Write | Submit an ARM template to a target resource group. |
| 5 | get_arm_template_deployment_status | Write | Poll a deployment's progress, outputs, and errors. |
| 6 | cancel_arm_template_deployment | Write | Abort an in-flight deployment. |
The toolset partitions cleanly into a read half (Azure Resource Graph) and a write half (Azure Resource Manager). The two halves compose: an agent can read the current state of the estate, decide what to change, deploy a template, and watch the result, all in a single conversation.
Why this matters
Three properties make the ARM MCP Server qualitatively different from earlier "Azure SDK in a function" approaches:
- Identity inheritance. The agent operates as the user. There is no shared credential, no over-privileged service principal, and no escalation path from "the agent can read this" to "the agent can write that."
- Tenant-wide read in one query. Azure Resource Graph indexes every resource type across every subscription the user can see. A single execute_query call can return all storage accounts in the tenant, or every public IP, or every VM by SKU, in seconds.
- Deterministic write surface. ARM templates are declarative, idempotent, and auditable. Every create_template_deployment produces a correlation ID and an entry in the activity log. The agent inherits all of that for free.
Together, these properties move the practical question from "can we let an agent touch our cloud?" to "what is the most useful thing to put on top of these six tools?" That is the question the PoC catalog tries to answer.
Part 2. The PoC Catalog
The arm-mcp-poc-catalog is a public repository containing 24 proof-of-concept agents, organized into two batches of 12. Every PoC is a self-contained VS Code workspace with its own agent persona, deterministic skill, pre-canned ARG queries, frozen output templates, and ARM template stubs where applicable. Each PoC folder contains a README.md, a runbooks/ directory with a committed scope template and a gitignored values file, and the agent definition plus rules and output templates.
The determinism contract
Before walking through the catalog, one design decision is worth calling out because it shows up in every PoC. The ARM MCP Server's generate_query tool is non-deterministic: the same prompt can produce slightly different KQL on different invocations, which produces different result sets, which would produce different remediation actions in a recurring agent.
To make these PoCs safe for repeated use (weekly reports, on-call playbooks, pre-deploy gates), every PoC follows the same five-rule contract:
- ARG queries are read literally from a rules.yaml file, never authored by the LLM at runtime.
- Every query call is validate_query then execute_query. Failed validations are marked INVALID and the agent does not retry or rewrite.
- Scope filters (subscription IDs, resource group names) are string-substituted from a separate values file.
- Output is a frozen markdown template with {{placeholder}} slots. No paraphrasing by the model.
- Run IDs follow <POC-PREFIX>-{YYYYMMDD}-{scope}-{sha256(rules.yaml)[:8]}, so identical inputs produce identical IDs.
The generate_query tool is still useful, but as a dev-time aid for drafting the KQL that gets checked into rules.yaml, not as a runtime step in a recurring agent.
Catalog: Enterprise PoCs (governance, FinOps, platform)
| # | PoC | Primary tools | What it does |
|---|---|---|---|
| 1 | Tag Hygiene Czar | Read + Write | Finds resources missing required tags, generates a patch ARM template, deploys on approval. |
| 2 | Blast Radius Analyzer | Read + What-if | Pre-deploy: cross-references an ARM template against current state to predict create/modify/replace/delete impact. |
| 3 | Cost Driver Finder | Read | Surfaces top cost-driving resources by region/owner/workload using ARG topology and tags. |
| 4 | Golden Path Provisioner | Read + Write | Templated provisioning of standard workload patterns with policy-aware defaults. |
| 5 | IaC Drift Detector | Read | Compares deployed state to a Git-stored ARM/Bicep baseline and reports drift. |
| 6 | Incident Responder | Read + Write | Estate-wide impact assessment for a declared incident, with optional remediation deploys. |
| 7 | Policy What-If | Read | Simulates a proposed Azure Policy assignment against current resources to predict denials. |
| 8 | Estate Cartographer | Read | Generates a tenant-wide topology map (resources, dependencies, ownership) from ARG. |
| 9 | ARM Template Fixer | Read + Write | Diagnoses a failed deployment, proposes a corrected template, redeploys on approval. |
| 10 | Crown-Jewels Security | Read | Identifies the small set of high-value resources (Key Vaults, prod databases, identities) and their exposure. |
| 11 | FinOps Rightsizer | Read | Recommends SKU downshifts for under-utilized compute and data resources. |
| 12 | ChatOps Bot | Read + Write | Slack/Teams-friendly wrapper exposing a curated subset of agent verbs to non-engineers. |
Catalog: SRE PoCs (incident response, change safety, reliability)
| # | PoC | Primary tools | What it does |
|---|---|---|---|
| 1 | Incident Triage | Read + Cancel | "First 60 seconds" change feed for the affected scope, with one-key cancel for in-flight deploys. |
| 2 | Change Freeze Enforcer | Read + Write gate | Intercepts deployments during freeze windows; requires break-glass justification logged to ticketing. |
| 3 | Pre-flight Safety | Read | Battery of health/dependency/capacity checks before any prod deployment. |
| 4 | Auto Rollback | Write + Cancel | Watches a deploy; on failure or health-gate breach, cancels and applies last-known-good template. |
| 5 | Reliability Posture Scorecard | Read | Weighted scoring of ~15 reliability rules (zone redundancy, geo-replication, soft-delete, etc.) across a scope. |
| 6 | SLO Deployment Gate | Read | Blocks deploys when the target service's error budget is exhausted. |
| 7 | Capacity / Quota Guardian | Read | Tracks subscription/region quota headroom and warns before deploys would exceed it. |
| 8 | Blast Radius Simulator | Read | "What if I drained this AZ?" or "what if this RG went away?" dependency simulation. |
| 9 | Stuck Deployment Janitor | Read + Cancel | Finds deployments stuck in Running past their SLA, summarizes, optionally cancels. |
| 10 | Runbook Executor | Write | Parameterized ARM-template runbooks for routine ops (cert rotation, scale events, etc.). |
| 11 | Post-Incident Reconstructor | Read | Reconstructs an exact timeline of resource changes during an incident window for the postmortem. |
| 12 | Weekly Cleanup PRs | Read + Write | Generates PRs for low-risk cleanup (orphaned NICs, unused public IPs, untagged dev resources). |
SRE-PoC-5 (Reliability Posture Scorecard) is the reference implementation. Read it first to understand the determinism contract end to end: literal KQL, validate then execute, frozen template, deterministic run ID, and no deployment risk.
Patterns that emerged across the 24 PoCs
Three patterns showed up repeatedly and are worth naming.
Pattern 1: Read-only agents are 80% of the value and 5% of the risk. Tag hygiene reporting, blast-radius analysis, cost driver discovery, crown-jewels security posture, the reliability scorecard, post-incident reconstruction: none of these require the write half of the API. They turn ARG into a query layer the existing humans can interrogate in English. Most teams should start here.
Pattern 2: Write-capable agents need three things, not one. Every deploy-capable PoC in the catalog gates create_template_deployment behind (a) an explicit user verb such as apply or remediate, (b) a confirm step that shows the resolved template and scope, and (c) a global freeze flag in the scope config that is checked before any other logic runs. The change-freeze enforcer (SRE-PoC-2) is itself one of the PoCs and can be wired in front of any other write-capable agent.
Pattern 3: The "what changed" loop is the killer feature. ARG can answer "what does my estate look like right now?" in seconds. Pair that with deployment status polling and you get "what just changed, by whom, and is it still in flight?", which is the foundation for incident triage, post-incident reconstruction, auto-rollback, and the stuck-deployment janitor. None of these were practical before the MCP server collapsed the auth, ARG, and ARM client stack into a single tool surface.
Getting started with any PoC
- Install the ARM MCP Server once: open https://aka.ms/JoinARMMCP in VS Code and sign in.
- Verify Azure access with az login. Read-only PoCs need Reader plus Resource Graph Reader on the target scope. Deploy-capable PoCs additionally need Contributor on the target resource groups.
- Clone the catalog: git clone https://github.com/jvargh/arm-mcp-poc-catalog.git.
- Open one PoC folder in VS Code as a workspace. The .vscode/mcp.json declares the ARM MCP server at workspace scope and starts it on first chat use.
- Configure scope: copy runbooks/<scope>.values.yaml.example to runbooks/<scope>.values.yaml and fill in subscription ID and resource groups. The values file is gitignored.
- Invoke the agent: see each PoC's README.md for accepted verbs (typically run, drilldown, remediate).
Spotlight: SRE-PoC-5, Reliability Posture Scorecard
Of the 24 PoCs in the catalog, the Reliability Posture Scorecard (SRE-PoC-5-Reliability-posture-scorecard/) is the reference implementation. It is the simplest PoC that exercises the full determinism contract end to end without any deployment risk.
What it does
The agent loads a fixed pack of weighted reliability rules from rules.yaml: checks like App Services without zone redundancy, SQL databases without geo-replication, Storage accounts without soft delete, and Key Vaults without purge protection. For each rule it calls validate_query then execute_query against the configured scope, aggregates failures per workload (resource group by default, or any tag), and computes a score:
score = max(0, 100 - Σ weight of failed rules)
The output is a frozen markdown report with a deterministic run ID of the form RPS-{YYYYMMDD}-{scope}-{sha256(rules.yaml)[:8]}. Run it twice in a row against the same scope and you get byte-identical output. Run it next week and any diff is a real change in the estate.
Why ARM MCP is a good fit
- One tool covers every resource type. Reliability rules span App Services, SQL, Storage, Key Vault, NSGs, and more. ARG exposes all of them as columns in the same query language, so a 12-rule pack is 12 KQL strings instead of 12 SDK clients.
- Tenant breadth in one round-trip. A single execute_query inspects every resource of a type in scope in seconds, with no pagination loop and no rate-limit gymnastics.
- Identity inheritance keeps scoring honest. The agent can only score what the operator can see. No scoring service principal needs tenant-wide read.
- Read-only, so it's safe to roll out first. Reader plus Resource Graph Reader is the entire permission requirement, which makes it the natural proof point before introducing any deploy-capable agent.
Resiliency benefits
- Continuous, not episodic. Replaces the every-six-months Well-Architected Review with a weekly run that produces a 0–100 score per workload and a trend row in exports/scorecard-trend.csv.
- Real diffs, not query drift. Deterministic run IDs mean a score moving from 78 to 64 is a real regression, not a different mood from the model.
- Pre-launch gate. The same rule pack runs in dev, staging, and prod, so missing zone redundancy or backup configuration is caught before promotion, not after.
- Postmortem evidence. The morning's scorecard is on disk with the exact failing rules and resource IDs, ready to cite directly in the writeup.
- Cheap to extend. Adding a rule is one block of YAML (literal KQL, weight, severity, remediation hint). No agent code changes, no prompt engineering.
The full walkthrough, including the multi-step end-to-end flow from chat prompt through MCP to rendered report, is in the PoC's own README.
Conclusion
The ARM MCP Server's six tools are deliberately small. The interesting engineering is in the shape you wrap them in: how you trade off the model's flexibility against the determinism a recurring agent needs, how you gate writes, and how you compose ARG reads with ARM deploys to answer the questions a human operator actually asks.
The arm-mcp-poc-catalog is one set of answers to those questions. Twenty-four PoCs is a starting menu, not a roadmap. Pick the one closest to a problem your team has on Monday morning, read its README.md, run it against a non-prod subscription, and decide whether the shape fits before you commit to building your own.
If you build something interesting on top, please open an issue or a PR on the catalog repo.
References
- Introducing the Azure Resource Manager MCP Server, Steven Bucher, Azure Governance and Management Blog
- Azure-Resource-Manager-MCP on GitHub: official server repo and documentation
- arm-mcp-poc-catalog: the 24-PoC catalog described in this post
- ARM MCP Server install link
Microsoft