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