TL;DR: To review a Bicep change before deployment, compile it with az bicep build, run the Bicep linter, az deployment group validate and what-if, then review the compiled ARM JSON for design, cost and security. what-if shows what will change in Azure. It doesn't tell you whether the change is safe, affordable or exposed.

By Prateek Singh, founder of Ganak AI Labs. Updated 6 October 2026.

Your pull request touches main.bicep. CI is green, and what-if prints a tidy list of + Create and ~ Modify lines. Someone approves it.

Two weeks later you learn the "small" change opened a storage account to the internet, or doubled the bill with a new SKU.

None of the tools lied. what-if tells you what will change, not whether it's safe. Here's how to answer that second question in the same PR, plus a checklist to copy.

Disclosure: I'm the founder of Cloudeval.

Key terms used below

• Bicep: Microsoft's language for Azure infrastructure. It compiles to an ARM template.

• ARM template: the Azure Resource Manager JSON file that Azure actually deploys.

• what-if: an Azure CLI command that previews changes against what's already deployed.

• Bicep linter: the built-in checker, configured in bicepconfig.json.

What does each Bicep pre-deployment check catch?

Keep the first four. The gap is the last row.

How do I review a Bicep change before deployment?

1. Compile the Bicep file to ARM JSON with az bicep build.

2. Run the native checks: the linter, validate and what-if.

3. Review design, cost and security on the compiled ARM JSON, locally or on every pull request.

4. Read the findings in a fixed order, then re-run what-if right before you deploy.

Step 1: Compile with az bicep build

Bicep compiles to ARM JSON, and that's what Azure actually deploys.

az bicep build --file ./infra/main.bicep --outfile ./infra/main.json

Compile a .bicepparam file the same way:

az bicep build-params --file ./infra/main.bicepparam --outfile ./infra/main.parameters.json

Make this your first CI step. Skim the JSON on module changes too. A one-line version bump can change many resources, and only the compiled output shows it.

Step 2: Run the native checks (linter, validate, what-if)

The linter

Set the rules that matter for review to error in bicepconfig.json:

{
  "analyzers": {
    "core": {
      "enabled": true,
      "rules": {
        "outputs-should-not-contain-secrets": { "level": "error" },
        "secure-parameter-default": { "level": "error" },
        "use-secure-value-for-secure-inputs": { "level": "error" },
        "no-hardcoded-environment-urls": { "level": "error" },
        "use-recent-api-versions": { "level": "warning" }
      }
    }
  }
}

Then run it in CI:

az bicep lint --file ./infra/main.bicep

validate and what-if

These two need a real Azure scope:

az deployment group validate \
  --resource-group rg-app-dev \
  --template-file ./infra/main.bicep \
  --parameters ./infra/main.bicepparam

az deployment group what-if \
  --resource-group rg-app-dev \
  --template-file ./infra/main.bicep \
  --parameters ./infra/main.bicepparam

sub, mg and tenant variants cover other scopes. Keep in mind:

• what-if needs deploy permissions, including Microsoft.Resources/deployments/*. Reviewers often lack them.

• Azure-set defaults can show up as changes that won't happen.

• Resources deployed through templateLink, including template specs, aren't expanded.

For refactors, bicep snapshot (Bicep CLI 0.41.2+) diffs what a .bicepparam would deploy, without contacting Azure:

bicep snapshot --mode overwrite ./infra/main.bicepparam   # on main
bicep snapshot --mode validate  ./infra/main.bicepparam   # on the PR branch

You now know what will change. You still don't know if it's a good idea.

Step 3: Review design, cost and security

Most pipelines skip this layer because it meant reading raw JSON by hand. Use any tool your team trusts. PSRule for Azure is a solid open-source option.

I'll use Cloudeval here. It reviews the compiled ARM JSON and returns architecture and dependency diagrams with cost and security findings. It doesn't read .bicep files directly, which is why Step 1 matters.

Here's a two-minute demo:

https://www.youtube.com/watch?v=Xzt4cNKUHxU

Option A: from your terminal

Install and sign in:

npm install -g @ganakailabs/cloudeval-cli   # Node.js 20+
cloudeval login            # or: cloudeval login --headless  (SSH/containers)
cloudeval auth status

Create a project from the compiled template and run every report:

cloudeval projects create \
  --template-file ./infra/main.json \
  --parameters-file ./infra/main.parameters.json \
  --name "PR 1234 - main.bicep" \
  --provider azure \
  --format json \
  --output ./cloudeval-project.json

PROJECT_ID=$(jq -r '.data.project.id' ./cloudeval-project.json)

cloudeval reports run --project "$PROJECT_ID" --type all --wait --format json

This runs against the template, not your subscription, so you need a Cloudeval account but no Azure credentials.

Read the results:

cloudeval reports waf  --project "$PROJECT_ID" --format markdown   # architecture findings
cloudeval reports cost --project "$PROJECT_ID" --format markdown   # cost estimate

cloudeval issues list \
  --project "$PROJECT_ID" \
  --type architecture,cost \
  --severity critical,high \
  --format json

Each finding names the rule, the resource type and the pillar.

Or open the diagram:

cloudeval open project "$PROJECT_ID" \
  --view preview --layout dependency --print-url --no-open

The generated diagram sits next to your files and ARM JSON outline.

Prefer clicking? In the web app, choose Projects, then Create project, then Upload Template File, and drop in main.json (up to 2 MB). The import guide covers URLs, parameter files and linked templates.

Your template, ARM JSON outline and report history live in one workspace.

Option B: on every pull request (GitHub Action)

ganakailabs/cloudeval-action posts one result comment per PR run. It can also write SARIF output and enforce merge gates.

Setup takes three steps (see the GitHub Actions guide):

1. Link the repo to a Cloudeval project with the Cloudeval GitHub App.

2. Create a CI access key scoped to that project.

3. Add the CLOUDEVAL_ACCESS_KEY and CLOUDEVAL_PROJECT_ID repository secrets.

One Bicep detail: the action reviews the synced files at the pushed commit, and it reads ARM JSON. So commit the compiled infra/main.json and main.parameters.json, and fail CI if they're stale.

name: Bicep review
on:
  pull_request:

permissions:
  contents: read
  pull-requests: write
  issues: write

jobs:
  native-checks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: az bicep lint --file ./infra/main.bicep
      - name: Compiled ARM JSON must be up to date
        run: |
          az bicep build --file ./infra/main.bicep --outfile ./infra/main.json
          git diff --exit-code -- ./infra/main.json

  cloudeval-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: ganakailabs/cloudeval-action@v1
        with:
          access_key: ${{ secrets.CLOUDEVAL_ACCESS_KEY }}
          project_id: ${{ secrets.CLOUDEVAL_PROJECT_ID }}
          mode: review
          post_pr_comment: true
          upload_artifacts: true

Keep the jobs separate. The review job stops on a dirty working tree, and building inside it would dirty it.

Set the entry point and gates in .cloudeval/config.yaml at the root of the synced source. With a source root of infra, that's infra/.cloudeval/config.yaml:

version: 1
stacks:
  - id: main
    entry: main.json                   # relative to the source root: infra/main.json -> main.json
    parameters: main.parameters.json
resolve:
  linked_templates: true
ci:
  gates:
    enforcement: comment_only   # switch to block_pull_request once thresholds are tuned
    minimum_well_architected_score: 80   # the default once ci.gates exists; set your own floor
    fail_when_high_risk_findings_exist: true
    fail_when_validation_fails: true
    max_monthly_cost_usd: 500

Keys you leave out of ci.gates take defaults, so set the score floor on purpose. Start with comment_only. Once you trust the thresholds, switch to block_pull_request and make the job a required status check.

Step 4: Read the findings

The PR comment keeps your gate separate from what the review saw:

Overall: PASS
Well-Architected posture: 23.1/100 (critical)
Validation: 3 unit tests failed
Policy checks: good
Cost: 143.81 USD/mo (under 100K budget)

Overall reflects your thresholds. critical is the posture Cloudeval observed. A PR can pass a loose gate and still deserve a hard look.

The expanded comment shows validation results and architecture signals.

Read the findings in this order:

1. Dependency view. Does the topology match the PR description? Look for surprise public endpoints, identity or subnet changes.

2. High-severity findings. Did this PR change the affected resource?

3. Cost drivers. Should a SKU change before rollout? Numbers are estimates.

4. Gaps. "Not assessed" doesn't mean safe.

Select a resource to see its upstream and downstream paths.

Then run what-if at deploy time anyway.

What belongs in a Bicep pre-deploy checklist?

## Bicep pre-deploy review
- [ ] `az bicep build` passes, compiled ARM JSON is committed and up to date
- [ ] `az bicep lint` clean (security-relevant rules set to `error`)
- [ ] `az deployment group validate` passes at the target scope
- [ ] `what-if` diff matches the PR description (no surprise Delete/Modify)
- [ ] Linked/nested templates and template specs reviewed separately (what-if doesn't expand templateLink)
- [ ] Dependency diagram reviewed: no unintended public exposure, identity or subnet changes
- [ ] High/critical findings triaged: fixed, waived with reason, or ticketed
- [ ] Monthly cost estimate checked against budget, SKU choices justified
- [ ] "Not assessed" areas noted, not assumed safe
- [ ] what-if re-run immediately before the real deployment

What doesn't a template review catch?

Cloudeval adds diagrams, cost and security findings from 1,650+ checks, right in the PR. It covers Azure, plus AWS CloudFormation (beta).

It can't prove runtime behaviour, and it doesn't replace what-if, the only real answer to "what changes in this subscription right now". It doesn't catch live drift yet either. Drift comparison is planned, and live Azure state comes in through a separate Cloud sync.

Frequently asked questions

How do I preview Azure deployment changes before deploying?

Run az deployment group what-if with the template and parameters you'll deploy. It lists each resource that would be created, modified or deleted, and needs deploy permissions.

Why does Bicep what-if show changes that won't happen?

Properties Azure sets as defaults can show up as changes even though nothing will change. Check unexpected Delete or Modify lines against the PR description first.

Can I review a Bicep change without access to the Azure subscription?

Partly. build, the linter and bicep snapshot run locally, but validate and what-if need deploy-level access. Cloudeval works from the compiled ARM JSON, so you need a Cloudeval account, not subscription credentials.

Does Cloudeval read .bicep files directly?

No. Compile with az bicep build and review the ARM JSON. That's what Azure actually deploys anyway.

How do I block a merge on high-risk findings or cost?

Add ci.gates to .cloudeval/config.yaml, for example fail_when_high_risk_findings_exist or max_monthly_cost_usd. Set enforcement: block_pull_request and make the job a required check in branch protection.

For the longer version, read How do I review a Bicep or ARM template before deployment? Or browse a public example PR with real caveats, including failed validation tests.

Related on cloudeval.ai

• How to convert Bicep to a cloud architecture diagram

• Cloud infrastructure review in GitHub pull requests

• What is IaC review?

• Compare Cloudeval with other cloud review and diagram tools

Try it

Compile your Bicep, then review the ARM JSON before it ships. Open the Cloudeval app and follow the IaC pre-deployment review guide.

About the author

Prateek Singh is the founder of Ganak AI Labs and builds Cloudeval AI.

cloudeval.ai | Docs | YouTube | GitHub | LinkedIn

TL;DR: To give Cursor, Claude Code or Codex your Azure architecture, run the Cloudeval CLI's local MCP server (npx -y @ganakailabs/cloudeval-cli mcp serve --toolset readonly) with a project-scoped, read-only access key. The agent can then read your architecture graph and saved cost and Well-Architected reports. It can't deploy or change Azure resources.

By Prateek Singh, founder of Ganak AI Labs, the team behind Cloudeval AI. Published 2 October 2026; commands checked against @ganakailabs/cloudeval-cli 0.38.5 and each client's MCP docs that day.

Ask a coding agent "is this storage account reachable from the internet?" and it will happily read main.bicep and give you an answer. What it can't see is everything outside the file: the other resource groups, the subnet the private endpoint lands in, the cost report from last week, the Well-Architected findings nobody has triaged yet. So it guesses, confidently.

The Model Context Protocol (MCP) fixes the plumbing side of this. Instead of you pasting screenshots and JSON into chat, the agent calls a tool server and gets structured answers back. This post shows how to connect Cursor, Claude Code or Codex to an MCP server that exposes your Azure architecture graph and saved reports, with a read-only toolset and a scoped key. It finishes with prompts that actually produce useful answers.

This isn't Microsoft's Azure MCP Server, which queries live Azure resources. The two can run side by side.

Key terms used below

• MCP (Model Context Protocol): an open protocol that lets AI clients such as Cursor, Claude Code and Codex call external tool servers and get structured results.
• stdio server: an MCP server the client starts as a local process. It has no network endpoint.
• ARM / Bicep: Azure Resource Manager JSON templates, and Microsoft's Bicep language that compiles to them.

The server I'm using is the one in the Cloudeval CLI, because it's the one I know best.

Disclosure: I'm the founder of Cloudeval (Ganak AI Labs).

If you prefer to watch first, here is the 52-second version of the idea: the same review context, reachable from the terminal, the IDE, CI and your own agents.

https://www.youtube.com/watch?v=wA6poXNBlVs

What can a coding agent read over MCP, and what can't it do?

Before wiring anything up, it's worth being precise about the boundary.

The data comes from Cloudeval projects, so you need at least one: either a live Azure subscription connected through Cloud sync, or an imported template. If you write Bicep, compile it first (az bicep build) and import the ARM JSON. Cloudeval reviews the compiled output rather than parsing .bicep directly.

How do I connect Cursor, Claude Code or Codex to Azure architecture over MCP?

1. Create a scoped, read-only access key.
2. Check the server locally with mcp status and doctor --mcp.
3. Add the stdio server to your client's MCP config.
4. Verify the tool list and the project scope.
5. Keep the readonly toolset and widen access only on purpose.
6. Use Agent Profiles as reviewer lenses.
7. Use prompts that ask for cited evidence.

Each step is covered below.

Step 1: Create a scoped, read-only access key

Don't hand an agent your interactive login. Create a dedicated key:

1. In the Cloudeval app, open Developer -> API & CLI access keys.
2. Create a key from the MCP Read-only template.
3. Scope it to the one project you want the agent to see.
4. Check the expiry and capabilities. The template defaults to 30 days. It includes project, connection, report, download, diagram-export and MCP access, but not billing reads or evaluation runs.

The create-key form with the MCP Read-only template, a project scope and the 30-day default expiry (the docs example names the key for another client; name yours after the agent that uses it). (Source: Cloudeval docs)

Store it in your shell profile or secret manager as CLOUDEVAL_ACCESS_KEY. Each client config below reads it from the environment, so the secret never lands in a file you might commit.

export CLOUDEVAL_ACCESS_KEY="<your scoped key>"   # keep out of dotfiles you commit

Step 2: Check the server locally

You need Node.js 20+. The no-install form uses npx. If you'd rather install globally, run npm install -g @ganakailabs/cloudeval-cli and use cloudeval directly.

# Inspect the MCP surface and diagnose local setup before touching any client
npx -y @ganakailabs/cloudeval-cli mcp status --format json
npx -y @ganakailabs/cloudeval-cli doctor --mcp --format json

doctor --mcp --format json shows the server, toolsets, tools, resources and prompts before any client is involved (docs capture from an earlier CLI version, so your lists may be longer). (Source: Cloudeval docs)

The command every client will launch is:

npx -y @ganakailabs/cloudeval-cli mcp serve --toolset readonly

Two things that trip people up:

• Don't run login through the MCP process. mcp serve reserves stdin for protocol messages. Authenticate beforehand (stored cloudeval login, or cloudeval login --headless over SSH), or rely on the env var.
• Containers don't inherit your host login. Pass the scoped key at runtime.

The CLI can also generate the config for you. Always start with --dry-run so you can read what it would write:

cloudeval mcp setup cursor --dry-run --toolset readonly
cloudeval mcp setup codex  --dry-run --toolset readonly
cloudeval mcp setup claude --dry-run
cloudeval mcp setup generic --dry-run --toolset readonly --format json

The supported targets are codex, claude, cursor, vscode and generic. --toolset defaults to readonly. Without --dry-run, setup can write to the client's config file. Pass --config-path if you want to control where it goes.

Step 3: Wire up your client

Every client below runs the same stdio command. Only the config syntax differs.

Codex uses a registration command; Cursor, Claude Code, VS Code and generic clients share one stdio config shape. (Source: Cloudeval docs)

Cursor

Add this to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global). Cursor's ${env:NAME} interpolation keeps the key out of the file:

{
  "mcpServers": {
    "cloudeval": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@ganakailabs/cloudeval-cli", "mcp", "serve", "--toolset", "readonly"],
      "env": { "CLOUDEVAL_ACCESS_KEY": "${env:CLOUDEVAL_ACCESS_KEY}" }
    }
  }
}

If Cursor is launched from the dock and doesn't see your shell variables, Cursor also supports an envFile for stdio servers. Point it at a git-ignored file.

Claude Code

Claude Code wants its own options (like --env) before --, and the server command after it:

claude mcp add cloudeval --env CLOUDEVAL_ACCESS_KEY="$CLOUDEVAL_ACCESS_KEY" \
  -- npx -y @ganakailabs/cloudeval-cli mcp serve --toolset readonly

claude mcp get cloudeval     # confirm it registered and connected

This uses the default local scope, which is stored in ~/.claude.json. Avoid --scope project here: that writes .mcp.json into the repo, and you'd be one git add . away from committing the key.

Codex

You can register it with the documented one-liner:

codex mcp add cloudeval -- cloudeval mcp serve --toolset readonly

To forward the key from your environment instead of storing its value, edit ~/.codex/config.toml:

[mcp_servers.cloudeval]
command = "npx"
args = ["-y", "@ganakailabs/cloudeval-cli", "mcp", "serve", "--toolset", "readonly"]
env_vars = ["CLOUDEVAL_ACCESS_KEY"]

Anything else that speaks stdio

Use the generic mcpServers shape, which is the same entry published in the official MCP Registry under io.github.ganakailabs/cloudeval:

{"mcpServers":{"cloudeval":{"command":"npx","args":["-y","@ganakailabs/cloudeval-cli","mcp","serve","--toolset","readonly"],"env":{"CLOUDEVAL_ACCESS_KEY":"<your scoped key>"}}}}

Step 4: Verify before you trust it

Restart the client if it needs a restart, then:

1. Ask it to list the available Cloudeval tools.
2. Run something low-risk: capabilities_get or projects_list.
3. Check that the result shows the profile, base URL and auth mode you expect, and only the project you scoped the key to.

If billing tools return permission errors, that's expected. The MCP Read-only key doesn't grant billing read access.

Step 5: Keep it read-only and widen on purpose

readonly is the default because review agents rarely need anything else. If a job calls for more, widen deliberately with one of the focused toolsets:

Note what's not in readonly: ask, agent_profiles_run, reports_run and the template-validation calls. Those start work on the Cloudeval side and can use credits. Your key also has to allow them.

After changing toolsets, restart the client so it refreshes its tool list.

Step 6: Use Agent Profiles as reviewer lenses

Agent Profiles change how an answer is organized, not what evidence is available. The public ids are architecture, cost, triage, remediation, visual-explainer, scripter, change-reviewer, evidence-auditor and security-reviewer. There's no separate Well-Architected profile, because architecture already includes that lens.

On readonly, the agent can discover them with agent_profiles_list and agent_profiles_get. Running one is excluded from readonly, so either use a wider toolset or run it from your terminal:

cloudeval agents run change-reviewer "Review this pull request" --project <project-id>
cloudeval agents run security-reviewer "Review exposure and identity risk" --project <project-id>

The change-reviewer profile is built to return PASS/WARN/BLOCK with current, proposed and live evidence kept separate. If evidence is stale or missing, it should report an evidence gap rather than a pass.

Step 7: Prompts that work

Vague prompts get vague answers. These work better because each one names the evidence it wants:

Using the cloudeval tools, list my projects, then get the architecture graph for "<project name>".
Which resources have public network access, and which relationships connect them to data stores?
Cite the resource ID for each claim.

Read the latest Well-Architected report for project <id>. Give me the five highest-severity findings
as a table: resource, finding, pillar, and the report reference. If any pillar is "Not assessed",
list it separately. Don't fill gaps with general advice.

I'm about to change infra/main.json in this repo. Using the project graph, tell me which resources
depend on the App Service plan defined there, so I know what this PR could affect.

Get the agent profile "cost" and summarize what it emphasizes. Then, using only the latest cost
report for project <id>, name the top three cost drivers and what evidence supports each one.

The server also publishes MCP prompts (cloudeval-architecture-review, cloudeval-template-preflight, cloudeval-impact-analysis and others) and resources such as cloudeval://projects and cloudeval://reports/latest. Clients that support prompts and resources show them in their prompt or @ menus.

A useful agent answer stays tied to the project, the selected resources and the visible diagram. (Source: Cloudeval docs)

A habit worth keeping: ask the agent to name the project, resource or report behind every important claim. If it can't, treat the answer as a hypothesis.

What are the common MCP setup mistakes?

• Committing the key. Use local or user scope and ${env:...} or env_vars. Don't put it in Dockerfiles or project-scoped config you check in.
• Expecting a URL. This is a local stdio server. There's no Cloudeval-hosted remote MCP endpoint to paste into a web chat.
• Assuming it sees live state. A template-backed project describes the template you imported, not what's running. Check the sync time on live projects.
• Letting the agent apply changes. The agent can prepare a fix. A human reviews it, and the normal deployment pipeline ships it.

Frequently asked questions

Is this the same as Microsoft's Azure MCP Server?

No. Microsoft's Azure MCP Server queries live Azure resources. The Cloudeval MCP server gives the agent review context: project architecture graphs, saved cost and Well-Architected reports and the validation check catalogue. They can run side by side in the same client.

How do I add an MCP server to Claude Code?

Run claude mcp add <name>, put Claude Code's own options such as --env before --, and the server command after it. Then run claude mcp get <name> to confirm it connected. The default local scope keeps the entry out of your repo.

Does it work in VS Code?

Yes. cloudeval mcp setup vscode --dry-run prints the config for VS Code. The server is the same stdio command used by Cursor, Claude Code and Codex.

Can the agent change my Azure resources over MCP?

No. The default readonly toolset reads projects, graphs, reports and the check catalogue. It can't deploy, change or remediate Azure resources. Tools that start work, such as report runs, are only in wider toolsets that you enable on purpose.

Is there a hosted MCP URL I can paste into a web chat?

No. It's a local stdio server that your client launches as a process. There's no Cloudeval-hosted remote MCP endpoint.

Takeaway

MCP doesn't make an agent smarter about your architecture by itself. What helps is giving it scoped access to real evidence: a graph, saved reports and a check catalogue, with read-only as the default. Start with one project, one key and the readonly toolset, then make the agent cite its sources. Widen access only when a specific job needs it.

If you're choosing between MCP servers for Azure work, I wrote up which MCP tool fits which Azure review job. It covers Microsoft's Azure MCP Server for live resource queries, Bicep tooling while authoring, and project-level review context. The full client reference is in the MCP client setup docs.

Related on cloudeval.ai

• Which MCP tools help review Azure infrastructure?
• How to review a Bicep or ARM template before deployment
• Agent Profiles reference
• Compare Cloudeval with other cloud review and diagram tools

Try it

Want your own agent to answer from your architecture? Open the Cloudeval app and follow the MCP client setup guide.

About the author

Prateek Singh is the founder of Ganak AI Labs and builds Cloudeval AI.

cloudeval.ai · Docs · YouTube · GitHub · LinkedIn