DEV Community: Prateek Singh

Cloudcraft vs Hava vs Cloudeval AI: which diagram tool, when?

Prateek Singh — Tue, 20 Oct 2026 15:07:52 +0000

TL;DR: Cloudcraft, Hava and Cloudeval AI all draw cloud diagrams, but they answer different questions. Cloudcraft designs diagrams and, inside Datadog, shows live infrastructure with ops overlays. Hava auto-documents connected AWS, GCP and Azure accounts with version history and change alerts. Cloudeval AI reviews an Azure ARM or compiled Bicep change in the pull request, before deployment.

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

"Which cloud diagram tool should we use?" usually gets answered with a feature checklist. That's the wrong frame. Tools that all draw a nice picture often solve different problems.

A better split is the three questions teams ask, at three different times:

"What does it look like?" You're designing, presenting or onboarding someone.
"What's running, and what changed?" You're documenting, auditing or debugging the live estate.
"Is this change safe to ship?" A pull request is open and nothing is deployed yet.

That third job is pre-deployment review: checking a change's design, cost and security before it ships. Cloudcraft, Hava and Cloudeval each lean toward a different question.

Disclosure: I'm the founder of Cloudeval. The Cloudcraft and Hava sections stick to what their own sites say, with links. Prices change, so check before you buy.

What is Cloudcraft best for? Design and live diagrams in Datadog

Cloudcraft is now part of Datadog and comes in two forms.

Cloudcraft in Datadog is a live, read-only view of AWS, Azure, GCP, OCI and vSphere resources (Datadog docs). You can switch overlays for infrastructure, observability, security, cloud cost and APM (AWS only, preview).

The Cloudcraft homepage pitches alerts, logs, security findings and costs on a diagram that updates as your infrastructure changes. Some overlays need other Datadog products, such as Cloud Security for the security overlay. It's free with any Datadog subscription (pricing).

Cloudcraft (Standalone) is a diagramming tool for AWS and Azure, with 3D views of your environments (docs). Two features stand out for design work:

Live and snapshot diagrams. A live diagram updates from your account. A snapshot is static and fully editable, and you can add components from the Design tab (docs).
Blueprints, which hold "your diagram, a budget, and all the documentation you attach to individual components" (docs).

Connecting an Azure account to standalone Cloudcraft needs a Pro subscription (docs).

Where it shines: whiteboard-quality design diagrams, budgeting a proposed architecture and, on Datadog, ops context on the live picture during incidents.

What is Hava best for? Auto-generated diagrams and drift alerts

Hava connects to your AWS, GCP and Azure accounts and generates interactive diagrams "grouped by VPCs or resource zones." Its homepage lists:

A security view of security groups, route tables and connections, to help catch public access to internal services and overly permissive rules.
Cost forecasts by VPC, region, instance, tag or project. Hava says plainly that it "isn't a replacement for billing platforms."
Versioning. Hava polls your cloud config, archives old diagram versions and lets you compare them over time.
Alerts when infrastructure changes.
Exports to Visio, PNG, CSV or JSON, embeddable diagrams and a self-hosted option.

For automation, Hava publishes a GitHub Action, teamhava/hava-sync-action, to "synchronize and export a diagram after you have deployed changes to your environment". It writes a PNG to your repo.

Every Hava plan includes unlimited diagrams, daily sync and 3, 6 or 12 months of history. The two-week trial includes Teams features, with exports off.

Where it shines: always-current documentation of what's deployed across several clouds, with history and drift alerts.

What is Cloudeval AI best for? Reviewing a change before deploy

Cloudeval can start from the template in your pull request instead of a connected account, before anything is deployed.

Importing a GitHub-hosted ARM template into a project.

Inputs: ARM JSON, Bicep compiled to ARM JSON, and AWS CloudFormation JSON or YAML as a static beta. For what's already running, live Azure comes in through Cloud sync with a least-privilege, resource-group-scoped custom role (support matrix). There's no live AWS or GCP connection.
Output: architecture and dependency views, cost estimates, Well-Architected and validation results, and findings tied to the affected resource. Findings draw on 1,650+ checks. Not every project runs every check, and unsupported areas show as Not assessed instead of passing silently.
In the PR: a GitHub Action posts one result comment. It can fail the job on thresholds you set for Well-Architected score, high-risk findings, validation and monthly cost.
Handoff: the CLI exports diagrams as PNG, JPEG or SVG, which also works for CI or agents.

Posture, critical issues, cost and priorities on one screen.

It isn't a freeform design canvas, an observability overlay or a multi-cloud live inventory. PR diagram diffs and snapshot drift comparison are planned, not shipped yet (interfaces and workflows).

Where it shines: the gap between "the template is valid" and "the template is deployed", when a reviewer wants the shape, cost and risk of a change.

Architecture view with issue badges, dependency labels and cost status.

The difference is the link from a finding to what it affects. This 48-second clip shows it:

How do Cloudcraft, Hava and Cloudeval AI compare?

This maps what each tool is built for, from each vendor's own description. It's not a scorecard.

	Cloudcraft	Hava	Cloudeval
Primary question	What does it look like? What's happening now (in Datadog)?	What's deployed, and what changed?	Is this change safe to ship?
Starts from	Connected accounts (live) or a hand-built design (snapshot)	Connected cloud accounts	A template in a PR, or a live Azure sync
Providers (per vendor)	In Datadog: AWS, Azure, GCP, OCI, vSphere. Standalone: AWS, Azure	AWS, GCP, Azure	Azure, plus AWS CloudFormation (beta)
Design and editing	Snapshot diagrams, Design tab, blueprints with budget	Not the focus of its main pages	Markup on generated diagrams, not a freeform canvas
Change over time	Diagram version history	Version history, diagram comparison, change alerts	Per-commit PR reviews. Drift and graph diff are planned
Cost	Blueprint budgets, Cloud Cost overlay in Datadog	Cost forecasts	Monthly cost estimate and an optional budget gate in the PR
Security signal	Security overlay (needs Datadog Cloud Security)	Security view of groups, routes and exposure	Findings with evidence from 1,650+ checks
CI/CD	Not covered here	GitHub Action and CLI to sync and export after deploy	GitHub Action that comments and gates before merge
Pricing (per vendor page)	Free with any Datadog subscription	From $59/month	Free 7-day trial (150 credits), Basic $19/month, Pro $49/month

The treemap shows where findings cluster by resource type.

Can you use Cloudcraft or Hava with Cloudeval AI?

Yes, and that's often the most practical setup. This pipeline reviews on the pull request, then refreshes documentation diagrams after deploy.

# .github/workflows/infra.yml (sketch: wire in your own deploy job)
on:
  pull_request:
  push:
    branches: [main]

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

jobs:
  pre-deploy-review:            # Question 3: is this change safe to ship?
    if: github.event_name == 'pull_request'
    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

  # deploy: ...                 # your existing deployment job

  refresh-docs-diagram:         # Question 2: what's deployed now?
    if: github.event_name == 'push'
    # needs: deploy
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: teamhava/hava-sync-action@v1
        with:
          source_id: ${{ secrets.HAVA_SOURCE_ID }}
          hava_token: ${{ secrets.HAVA_TOKEN }}
          environment_id: ${{ secrets.HAVA_ENVIRONMENT_ID }}
          view_type: infrastructure
          image_path: docs/architecture.png
      # commit docs/architecture.png in a follow-up step if you want it in the repo

The Cloudeval job needs the repo linked through the Cloudeval GitHub App. The Hava job needs a connected Hava source. On Datadog, Cloudcraft's live diagram replaces the second job, outside CI entirely.

Which cloud diagram tool should you choose?

Ask these in order:

Designing something new and presenting it? Cloudcraft's snapshot diagrams and blueprints.
Already paying for Datadog? Cloudcraft in Datadog is included.
Need always-current docs and change history across AWS, GCP and Azure? That's Hava's core pitch.
Changes reach production through pull requests, and nobody checks design, cost and exposure there? That's the gap Cloudeval targets.

Some teams answer "yes" to two. That's fine, because the tools mostly don't compete for the same moment.

Frequently asked questions

What is a good Cloudcraft alternative for Azure?

It depends on the job. Hava is built for always-current documentation and change history of deployed Azure, AWS and GCP accounts. Cloudeval AI reviews an Azure ARM or compiled Bicep change in a pull request before it ships. See the longer Cloudcraft alternative for Azure pre-deployment review.

Does Cloudcraft support Azure?

Yes. Per Datadog's docs, Cloudcraft (Standalone) covers AWS and Azure, and connecting an Azure account needs a Pro subscription. Cloudcraft in Datadog covers AWS, Azure, GCP, OCI and vSphere.

Is Cloudcraft free?

Cloudcraft's pricing page says it's free with any Datadog subscription, with unlimited users and diagrams. Standalone Cloudcraft has Free, Pro and Enterprise plans, and connecting Azure needs Pro.

How much does Hava cost?

Hava's pricing page lists Professional at $59/month (3 cloud accounts, 1 user), Teams at $249/month (10 accounts, unlimited users) and custom Enterprise pricing. Check the page before you buy, because pricing changes.

Can you use a diagram tool and a pre-deployment review tool together?

Yes. They run at different moments: review the change on the pull request, then refresh documentation diagrams after deploy. The workflow sketch above runs both from one GitHub Actions file.

Takeaway

"Cloud diagram tool" covers at least three jobs: designing, documenting what's live and reviewing a change before it ships. Pick the tool by the question you need answered, and when.

A diagram of production won't warn you a PR is about to double the bill. A PR gate won't help you whiteboard next quarter.

If pre-deployment review is the missing piece, read the criterion-by-criterion comparison of Cloudcraft and Cloudeval for Azure pre-deployment review.

Related on cloudeval.ai

Try it

Want to see a template as a reviewed diagram before it ships? Open the Cloudeval app and follow the diagrams and workspace views guide.

About the author

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

cloudeval.ai | Docs | YouTube | GitHub | LinkedIn

GitHub Actions architecture review gate for Azure pull requests

Prateek Singh — Tue, 13 Oct 2026 09:30:11 +0000

TL;DR: An architecture review gate is a GitHub Actions job that checks every pull request against thresholds you set for Well-Architected score, high-risk findings, validation and monthly cost. Run ganakailabs/cloudeval-action with mode: review, start with enforcement: comment_only, then switch to block_pull_request and make the job a required status check.

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

Your infrastructure pipeline is green. That still doesn't tell you whether the change is a good idea.

Does it push the bill past budget? Does it open a high-risk exposure? Does it drag the project's Well-Architected score down?

Usually a busy reviewer answers those questions, if they have time. This guide turns them into a CI step that runs on every pull request, posts one comment and fails when your thresholds aren't met.

Disclosure: I'm the founder of Cloudeval.

The example uses ganakailabs/cloudeval-action. The rollout pattern (comment first, block later, require the check) works with any review tool.

What will you build?

A linked repository that syncs every pushed commit into a review project.
A workflow that reviews each pull request and posts one result comment.
Gates for Well-Architected score, high-risk findings, validation and monthly cost.
A downloadable review artifact for every run, pass or fail.
A required status check that blocks merges once you trust the thresholds.

Which terms do you need to know?

Term	Meaning
GitHub Actions	GitHub's built-in CI/CD. A workflow job can run on every pull request.
Required status check	A branch protection or ruleset setting that blocks a merge until a named job passes.
Well-Architected score	A project score against Azure Well-Architected Framework pillars such as security and reliability.

Here's the whole flow in under a minute:

How does an architecture review gate work in GitHub?

Two separate GitHub integrations do the work. Mixing them up is the most common setup mistake.

Piece	What it does	Where it runs
Cloudeval GitHub App	Imports a branch into a project, records the commit SHA and refreshes on push	Cloudeval
GitHub Action	Runs the CI review with a scoped access key, applies gates, posts the comment and uploads artifacts	Your runner

On each pull request push, the sequence is:

The GitHub App syncs the commit.
The project refreshes its graph, cost, Well-Architected and validation results.
The workflow runs cloudeval-action in mode: review and waits for that commit.
The gates run, then the action posts the PR comment and uploads artifacts.

Coverage is Azure, plus AWS CloudFormation (beta). On Azure it reads ARM JSON (including nested templates through templateLink) and Bicep compiled to ARM JSON. CloudFormation JSON or YAML is reviewed as a static beta.

Tip: If you write Bicep, commit the compiled main.json and fail CI when it's stale. The Bicep pre-deployment review answer shows the full pattern.

How do I add an architecture review gate to GitHub pull requests?

Link the repository with the Cloudeval GitHub App.
Create a project-scoped CI access key and add it as repository secrets.
Add a workflow that runs ganakailabs/cloudeval-action in mode: review.
Define gates in .cloudeval/config.yaml, starting with comment_only.
Read the PR comment and keep the review artifact.
Switch to block_pull_request and make the job a required status check.

Step 1: Link the repository

In Cloudeval, create an Infrastructure-as-code project from GitHub. Install the Cloudeval GitHub App on the repo and pick a branch.

If your templates live in a subfolder, set a source root such as infra. Then infra/azuredeploy.json appears as azuredeploy.json in the project.

Put .cloudeval/config.yaml in the source root. This names the entry template:

version: 1
stacks:
  - id: primary-architecture
    name: Primary architecture
    entry: azuredeploy.json
    parameters: azuredeploy.parameters.json
resolve:
  linked_templates: true   # follow relative ARM templateLink files

After import, the project should show the repo, branch, commit SHA and source root. Fix that first if it doesn't.

After import, files, validation, cost and Well-Architected status share one project.

Step 2: Create a CI access key and add secrets

In the app, open Developer, then API & CLI access keys. Create a GitHub Actions CI key scoped to that one project. Include:

Project and report review access (part of the template).
review:summary, if you want the AI-written summary in the comment.
github:comment, if the comment should come from the Cloudeval GitHub App. Without it, the action falls back to github-actions[bot].

Or create one from your terminal and store it in GitHub with this script:

cloudeval credentials create \
  --name "GitHub Actions CI - owner/repo" \
  --template ci \
  --project "$CLOUDEVAL_PROJECT_ID" \
  --expires 90d \
  --show-secret \
  --format json

gh secret set CLOUDEVAL_ACCESS_KEY --repo owner/repo
gh secret set CLOUDEVAL_PROJECT_ID --repo owner/repo

Warning: Run that on your own machine, never in CI logs.

Keys expire and aren't renewed in place, so put the expiry date on the team calendar.

Step 3: Add the workflow

Create .github/workflows/cloudeval-review.yml with this content:

name: Cloudeval review
on:
  pull_request:

permissions:
  contents: read
  pull-requests: write   # PR comment
  issues: write          # PR lifecycle reactions and the bot-comment fallback

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

Note: Set those three inputs explicitly. By default mode is ask, and post_pr_comment and upload_artifacts are false. Leave them out and the workflow runs but gates nothing.

The review waits for the GitHub sync of that commit, then writes review.json and review.md. It reviews pushed commits only. If an earlier step changes the working tree, it stops with this message:

Reviews pushed commits only. Add --ignore-dirty to review HEAD anyway.

So put steps that generate files, like az bicep build, in a separate job.

Two optional inputs are worth knowing:

ai_summary: "false" gives you gate and report data with no model-written prose.
sarif: true writes review.sarif.json from source-mapped findings, ready for GitHub's SARIF upload action.

The optional AI summary. Turn it off with ai_summary: "false".

Step 4: Define the gates, in comment-only mode first

Gates live in .cloudeval/config.yaml under ci.gates. Without that block, review mode warns instead of failing, so a fresh setup never blocks anyone by surprise.

Once the block exists, keys you leave out take defaults: a minimum Well-Architected score of 80, with the high-risk and validation checks on. Set each one on purpose.

This starter block publishes results without failing anything yet:

ci:
  gates:
    enforcement: comment_only          # publish results, don't fail the job (yet)

    minimum_well_architected_score: 85 # overall, out of 100
    minimum_pillar_score: 80           # default floor for every pillar
    pillars:
      security: 90
      reliability: 85

    fail_when_high_risk_findings_exist: true
    fail_when_validation_fails: true   # policy checks or unit tests
    max_monthly_cost_usd: 500          # omit to report cost without gating it

  review:
    outputs:
      pdf:
        enabled: true                  # attach review/review.pdf to the artifact
        report_type: all
        verbosity: evidence
        fail_on_error: false

Tip: Don't copy these numbers blindly. Run a week of PRs in comment_only, see where your projects score, and set thresholds just below that.

A gate that fails on day one gets disabled on day two.

Step 5: Read the PR comment and keep the evidence

With post_pr_comment: true, the action reacts when the review starts and finishes. It keeps one result comment per run instead of adding one on every push.

A typical comment starts like this:

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)

Read it as two signals. Overall is your gate: did the PR meet your thresholds? The posture line is what the review observed.

A PR can pass a loose gate and still show critical posture. That isn't a bug. It means your thresholds are looser than your architecture deserves.

The gate result sits above what the review observed.

Below that sit the source details and expandable sections for pillar scores, cost by service, test failures and the AI summary.

Pillar scores and the monthly cost breakdown expand in place.

With upload_artifacts: true, each run uploads a cloudeval-output artifact, kept for 14 days by default (artifact_retention_days). It holds the review JSON, Markdown and, if enabled, PDF.

It uploads even when the gate fails, which is exactly when you need it.

The run summary carries the result and a downloadable artifact.

Step 6: Turn it into a real gate

Once the thresholds stop surprising people:

Change enforcement: comment_only to enforcement: block_pull_request.
In branch protection or a ruleset, mark the review job's check as required.

Important: A workflow can't stop someone clicking Approve. The required status check is what blocks the merge.

Should you use comment_only or block_pull_request?

	`comment_only`	`block_pull_request`
Job result when a gate fails	Passes, results are published	Fails
Blocks the merge	No	Yes, once the job is a required status check
Best for	The first week, while you calibrate thresholds	Steady state, once thresholds stop surprising people
PR comment and artifact	Yes	Yes

Why is my review gate failing?

Match the symptom to the fix:

Symptom	Likely cause	Fix
`credential_expired`	The access key expired	Create a new GitHub Actions CI key and replace `CLOUDEVAL_ACCESS_KEY`
"Missing project" style failure	`CLOUDEVAL_PROJECT_ID` not set	Add the secret and pass `project_id`
Review can't match repo or ref	Project not linked to this repo	Reconnect through GitHub repository sync
Stops with "Reviews pushed commits only"	An earlier step changed files	Move generation to another job, or set `ignore_dirty: "true"`
Comment is from `github-actions[bot]`	Key lacks `github:comment`, or the project isn't App-linked	Add the capability or relink

What should you check before you enforce the gate?

Copy this checklist into the rollout PR:

- [ ] GitHub App installed, project shows repo, branch, commit SHA, source root
- [ ] .cloudeval/config.yaml has the correct stack entry (relative to the source root)
- [ ] GitHub Actions CI key scoped to one project, expiry on the team calendar
- [ ] Workflow sets mode: review, post_pr_comment: true, upload_artifacts: true explicitly
- [ ] One week in comment_only, thresholds set from observed scores
- [ ] enforcement: block_pull_request and a required status check in branch protection

Note: PR reviews refresh reports and, by default, generate an AI summary. Both use Cloudeval credits, so budget for them on busy repos.

Frequently asked questions

How do I review infrastructure changes in a GitHub pull request?

Run a review job on the pull_request event and post the result to the PR. With Cloudeval, the GitHub App syncs the commit, and ganakailabs/cloudeval-action in mode: review applies your gates and posts one result comment.

How do I make a GitHub Actions job block a merge?

Make the job fail when the gate isn't met (enforcement: block_pull_request), then mark it as a required status check in branch protection or a ruleset.

Does the review gate work with Bicep?

Yes, through compiled ARM JSON. Commit the main.json that az bicep build produces and fail CI when it's stale. Cloudeval doesn't parse .bicep files directly.

Why is the PR comment posted by github-actions[bot]?

The comment uses the Cloudeval GitHub App identity only when the project is linked to the same repo, the key has github:comment, and the job has pull-requests: write and issues: write. Otherwise it falls back to github-actions[bot].

Does it comment on pull requests from forks?

Often not. GitHub usually gives fork PRs a read-only workflow token, so the comment is skipped. That's GitHub's restriction, not the action's.

What is the takeaway?

A review gate is a policy decision more than a tooling one. Decide what "safe to merge" means, write it down as thresholds, and publish results before you enforce them.

Want to see it first? The public Azure ARM review example has demo PRs that pass, fail on cost and fail on risk.

For the overview, read Cloud infrastructure review in GitHub pull requests. The full input reference is in the GitHub Actions guide.

Related on cloudeval.ai

Next step: Ready to gate your own pull requests? Open the Cloudeval app and follow the GitHub Actions guide.

About the author

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

cloudeval.ai | Docs | YouTube | GitHub | LinkedIn

Review Bicep before deployment: what-if, linter and cost

Prateek Singh — Tue, 06 Oct 2026 09:30:35 +0000

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?

Check	Catches	Needs Azure access?	Misses
`az bicep build`	Syntax and type errors	No	Intent and design
Bicep linter	Hard-coded URLs, secrets in outputs, insecure defaults, old API versions	No	Topology, cost, cross-resource risk
`az deployment group validate`	Whether Resource Manager accepts the template at a real scope	Yes	Whether you should deploy it
what-if	The resource-level diff against current Azure state	Yes, deploy-level	Whether that diff is safe or affordable
Design, cost and security review	Public exposure, dependency shape, cost drivers	Not for template review	Runtime behaviour, live drift

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

How do I review a Bicep change before deployment?

Compile the Bicep file to ARM JSON with az bicep build.
Run the native checks: the linter, validate and what-if.
Review design, cost and security on the compiled ARM JSON, locally or on every pull request.
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:

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):

Link the repo to a Cloudeval project with the Cloudeval GitHub App.
Create a CI access key scoped to that project.
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:

Dependency view. Does the topology match the PR description? Look for surprise public endpoints, identity or subnet changes.
High-severity findings. Did this PR change the affected resource?
Cost drivers. Should a SKU change before rollout? Numbers are estimates.
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

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

Give Cursor, Claude Code or Codex your Azure architecture over MCP

Prateek Singh — Fri, 02 Oct 2026 08:00:33 +0000

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.

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 agent can read (default `readonly` toolset)	The agent can't do
Projects your key can see, plus details and overview	Deploy, change or remediate Azure resources
Architecture graph nodes and relationships	See anything outside the projects the key is scoped to
Saved cost and Well-Architected reports and rule results	Run reports or AI answers (those need an explicit, wider toolset)
The validation check catalogue	Reach a hosted endpoint: the server runs locally over stdio
Agent Profile definitions (`architecture`, `cost`, `security-reviewer`, ...)	Read live AWS or GCP. Inputs are live Azure (Cloud sync), ARM JSON, Bicep compiled to ARM, and AWS CloudFormation as a static beta

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?

Create a scoped, read-only access key.
Check the server locally with mcp status and doctor --mcp.
Add the stdio server to your client's MCP config.
Verify the tool list and the project scope.
Keep the readonly toolset and widen access only on purpose.
Use Agent Profiles as reviewer lenses.
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:

In the Cloudeval app, open Developer → API & CLI access keys.
Create a key from the MCP Read-only template.
Scope it to the one project you want the agent to see.
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:

Ask it to list the available Cloudeval tools.
Run something low-risk: capabilities_get or projects_list.
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:

Toolset	Use it for
`readonly`	Project, graph, report and capability reads (the default)
`graph`	Graph, timeline, diff, sync-run and insight reads
`validation`	`template_validate`, `template_test`, `template_parse` and rule-catalogue reads
`reports`	Report runs, downloads and deeplinks
`billing`	Billing inspection, invoices and explicit checkout tools
`all`	The full surface

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

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

DEV Community: Prateek Singh

Cloudcraft vs Hava vs Cloudeval AI: which diagram tool, when?

What is Cloudcraft best for? Design and live diagrams in Datadog

What is Hava best for? Auto-generated diagrams and drift alerts

What is Cloudeval AI best for? Reviewing a change before deploy

How do Cloudcraft, Hava and Cloudeval AI compare?

Can you use Cloudcraft or Hava with Cloudeval AI?

Which cloud diagram tool should you choose?

Frequently asked questions

What is a good Cloudcraft alternative for Azure?

Does Cloudcraft support Azure?

Is Cloudcraft free?

How much does Hava cost?

Can you use a diagram tool and a pre-deployment review tool together?

Takeaway

GitHub Actions architecture review gate for Azure pull requests

What will you build?

Which terms do you need to know?

How does an architecture review gate work in GitHub?

How do I add an architecture review gate to GitHub pull requests?

Step 1: Link the repository

Step 2: Create a CI access key and add secrets

Step 3: Add the workflow

Step 4: Define the gates, in comment-only mode first

Step 5: Read the PR comment and keep the evidence

Step 6: Turn it into a real gate

Should you use comment_only or block_pull_request?

Why is my review gate failing?

What should you check before you enforce the gate?

Frequently asked questions

How do I review infrastructure changes in a GitHub pull request?

How do I make a GitHub Actions job block a merge?

Does the review gate work with Bicep?

Why is the PR comment posted by github-actions[bot]?

Does it comment on pull requests from forks?

What is the takeaway?

Review Bicep before deployment: what-if, linter and cost

What does each Bicep pre-deployment check catch?

How do I review a Bicep change before deployment?

Step 1: Compile with az bicep build

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

The linter

validate and what-if

Step 3: Review design, cost and security

Option A: from your terminal

Option B: on every pull request (GitHub Action)

Step 4: Read the findings

What belongs in a Bicep pre-deploy checklist?

What doesn't a template review catch?

Frequently asked questions

How do I preview Azure deployment changes before deploying?

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

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

Does Cloudeval read .bicep files directly?

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

Give Cursor, Claude Code or Codex your Azure architecture over MCP

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

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

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

Step 2: Check the server locally

Step 3: Wire up your client

Cursor

Claude Code

Codex

Anything else that speaks stdio

Step 4: Verify before you trust it

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

Step 6: Use Agent Profiles as reviewer lenses

Step 7: Prompts that work

What are the common MCP setup mistakes?

Frequently asked questions

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

How do I add an MCP server to Claude Code?

Does it work in VS Code?

Can the agent change my Azure resources over MCP?

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

Takeaway

Step 1: Compile with `az bicep build`

Does Cloudeval read `.bicep` files directly?