The Bicep MCP server: stopping Copilot from guessing at your Azure resources

Every time I have asked an AI assistant to “write me a Bicep file for a storage account with private endpoints,” I have gotten something that looks right and compiles wrong: a property that moved to a nested object two API versions ago, an apiVersion that was never actually published, or a resource type spelled with the confidence of something that exists and the accuracy of something that doesn’t. The model isn’t being careless — it just has no way to check its work against the actual Azure Resource Manager schema. Microsoft’s answer to that gap, shipped with the Bicep VS Code extension, is the Bicep MCP server: a set of tools that give the model real Azure and Bicep context instead of asking it to recall schemas from training data.

What it actually exposes

The Bicep MCP server is available starting with Bicep extension version 0.40.2 for Visual Studio Code, which installs it automatically. It exposes ten tools an agent can call during a chat session:

• get_az_resource_type_schema — the schema for a specific Azure resource type and API version, so the model can check a property actually exists before writing it.
• list_az_resource_types_for_provider — all resource types under a provider (for example Microsoft.Storage), useful when the model needs to pick the right type instead of guessing at a name.
• get_bicep_best_practices — Microsoft’s own Bicep authoring guidelines, so the generated file follows conventions instead of whatever pattern happened to dominate the training set.
• get_bicep_file_diagnostics — runs the same compiler diagnostics you’d get in the editor against a file, so the model can catch its own errors before handing you the result.
• list_avm_metadata — metadata for Azure Verified Modules, so the model can reach for a maintained AVM module instead of hand-rolling a resource block AVM already covers.
• get_file_references — walks a Bicep file’s referenced modules, parameter files, and other dependencies.
• get_deployment_snapshot — builds a snapshot from a .bicepparam file so you can preview what a deployment would actually produce.
• decompile_arm_template_file / decompile_arm_parameters_file — convert existing ARM JSON templates and parameter files into Bicep and .bicepparam syntax.
• format_bicep_file — applies the standard Bicep formatting rules.

None of this makes the model omniscient, but it changes the failure mode. Instead of hallucinating a schema, the model can look one up; instead of guessing whether a module exists in the AVM registry, it can list what’s actually published there.

Setting it up

If you already have VS Code and the Bicep extension 0.40.2 or later, the MCP server is installed alongside it — you just need to start it and enable the tools in a Copilot Chat session:

1. Open the Command Palette, or use the chat pane’s Configure tools icon, and confirm the Bicep MCP server is listed and enabled.
2. Open Copilot Chat with your .bicep file as the active context.
3. Prompt normally — the agent decides when to call a Bicep tool, though nothing guarantees it will. Microsoft’s own workaround, if you want to force it, is to say so explicitly: “For this conversation, only use tools from the bicep-mcp MCP server” and then something like “Add a storage account resource with only the required properties using Bicep best practices.”

Outside VS Code, the server runs as a standalone process any MCP-compatible client can attach to — Microsoft names Claude Desktop and Claude Code, OpenAI’s Codex CLI, and LM Studio as supported integrations. With the .NET 10 SDK installed, dnx pulls the latest version straight from NuGet without a manual build:

dnx -y Azure.Bicep.McpServer

For VS Code, the equivalent server entry looks like this:

"Bicep": {
  "type": "stdio",
  "command": "dnx",
  "args": [
    "-y",
    "Azure.Bicep.McpServer"
  ]
}

A realistic session

The Microsoft quickstart walks through a sequence worth internalizing, because it’s the same loop I’d want a junior engineer to follow by hand: generate a resource, then ask the model to check its own API version is current, then ask it to fill in parameter defaults, then explicitly run diagnostics, then generate a matching .bicepparam file, then pull a deployment snapshot before ever touching az deployment for real. Each of those is a separate MCP tool call, and each one is a place where a wrong guess gets caught before it reaches a resource group instead of after.

That last step — the deployment snapshot — is the one I’d push teams to actually use. It’s the difference between “the file compiles” and “I know what this will create,” without spending an actual deployment (or a what-if run against a real subscription) to find out.

Where it still needs a human

Microsoft is explicit about the boundary here, and it’s worth repeating to anyone tempted to skip review because “the AI used the MCP tools”: you’re responsible for reviewing all generated code, and you deploy at your own risk. These tools improve the odds that the generated Bicep is syntactically and semantically correct — they don’t deploy anything themselves, and there’s no guarantee the orchestrating model calls the right tool, or any tool, for a given prompt. If you need it to use a specific tool, you have to say so.

For a solo engineer or a small team, that mostly means: keep the habit of reading the diff before you git commit, same as you would with any other AI-generated code. For a platform team building shared modules, it’s a stronger argument for still gating merges to your Bicep or AVM module repos behind the same PR review and what-if checks you’d run regardless of who — or what — wrote the file.

The takeaway

The Bicep MCP server doesn’t change what Bicep is; it changes what the model writing it knows. Schema lookups, best-practice guidance, real diagnostics, and a look at what AVM already provides turn “plausible-looking IaC” into IaC that’s actually been checked against the platform it targets. That’s a meaningfully better starting point than a raw chat completion — but it’s still a starting point. The review step doesn’t go away; it just starts from a file that’s far less likely to be wrong for a reason the model could have checked itself.

---

Sources & further reading: Bicep MCP server, Quickstart: Create Bicep files with Visual Studio Code and Bicep MCP server.