mrkeyoor.com_
Tue 01 Sept 16:16 UTC
CloudMCP servermeasured 19 Aug 2026

Azure MCP

Azure MCP is Microsoft's Model Context Protocol server for Azure, published on npm as @azure/mcp. It gives an agent tools for Azure services such as storage, Cosmos DB, Kusto and resource groups. It ships as a multi-command CLI rather than a bare stdio server, so the bare package name alone is not a runnable command.

BootDID NOT BOOTWe started it and it never completed initialize: exited with code 1 before initialize completed
Tools0tools/list payload 0 bytes
Context tax~0estimated tokens for the whole tools/list, chars/4 estimate
Resources / prompts / counts returned by resources/list and prompts/list
Measured19 Aug 2026one run of the harness, clean environment, no credentials · how we test

How we started it

npx -y @azure/mcp
Verdict

We could not start it the way every other server in this batch starts, and that is the whole story: `npx -y @azure/mcp` exits immediately with `Required command was not provided.` because the binary wants a subcommand before it will speak stdio. Add the subcommand its docs give you and it should come up, but you are also signing up for an Azure identity that the process can actually use, which is the real cost here. Use it if your agent already lives inside an Azure tenant and you are comfortable handing it a credential; skip it if you wanted a read-only peek at your cloud.

Use it if

Your team is already on Azure and signed in with the Azure CLI on the same machine, so the server can borrow that identity instead of you minting a new secret.
You want one server covering several Azure services rather than bolting together separate storage, Cosmos DB and Kusto integrations.
You are fine reading the docs before the first run, because the launch command is not the one-liner the npm page shape suggests.
Microsoft being the publisher matters to your security review more than the setup friction costs you.

Skip it if

You wanted a server that boots from a clean environment with no arguments, the way most of the ones we measured do.
You have no Azure credential you are willing to expose to an agent process, since without one the tools have nothing to talk to.
You only need a single Azure service, where a narrower client or a plain CLI call in a shell tool is less machinery.
Your agent runtime only lets you configure a package name and no extra arguments.
You are cost-sensitive about what an agent can do unsupervised, because cloud control-plane tools change real infrastructure.

The bill for your context window

There is no Context Tax to report, because nothing ever reached tools/list. Our record shows a tools count of 0 and a tools payload of 0 bytes, which is what a pre-initialize exit looks like and not a claim that the server is small. Expect the opposite once it starts: a multi-service cloud server with a tool per operation tends to sit at the heavy end, and every one of those descriptions rides in your context on every turn. When it does boot for you, check the token weight of the tools/list payload before you leave it enabled in a long session.

Setup reality

Our harness runs every server as an unprivileged user with a clean environment and no secrets, then speaks JSON-RPC over stdio. Azure MCP exited with code 1 before initialize, and the only thing on stderr was `Required command was not provided.` Notably it scraped no env-var names at all, so there was no hint list to work from: the failure is argument shape, not a missing variable. In practice you launch it with the subcommand from the Azure MCP docs, and separately you arrange an Azure identity, usually an existing `az login` session or a service principal in the environment. Neither of those is something we will do inside a probe sandbox.

Questions people ask

Why did Azure MCP fail to start in your test?

We ran `npx -y @azure/mcp` with a clean environment on 2026-08-19. It printed `Required command was not provided.` and exited with code 1 before the initialize handshake. The package's entry point is a CLI that expects a subcommand, so the plain package invocation never becomes an MCP server.

Does that mean the Azure MCP server is broken?

No. It means the launch line most directories copy is wrong for this one. Use the exact command from Microsoft's docs in your client config, and give the process an Azure identity it can use. Our result is about the default invocation, not the server's quality.

What credentials does it need?

Our probe scraped no environment variable names from stderr, because it died before it looked for any. The docs point at the standard Azure identity chain, which in practice means an existing `az login` session or service principal variables in the process environment.

Is there a lighter option for one Azure service?

Often yes. If you only touch blob storage or one Kusto cluster, a narrow tool or a shell command through an existing exec tool costs you a fraction of the tool descriptions a whole-cloud server keeps loaded, and it is far easier to scope the credential.

Other cloud servers we started

ServerVendorBootsContext tax
HerokuHeroku~0 tokens
Kubernetescommunity (Flux159)~5,964 tokens
NetlifyNetlify~3,083 tokens

How this page is made: the server is spawned as an unprivileged user with a clean environment and no credentials, then asked for its tools, resources and prompts over stdio. Token figures are estimates at four characters per token, not a tokenizer count. One run, one machine. Corrections: contact the desk.

← All measured MCP servers