Azure MCP Server 3.0 goes stable: operations toolsets, opt-in structured output, stricter defaults for new resources
Microsoft's Azure MCP Server reached a stable 3.0 on October 12 after fifty beta iterations: backup, resilience and SRE toolsets, Terraform and Advisor helpers, opt-in structured output, and security defaults that apply to resources you create, not ones you have. MIT license. I read the announcement and the LICENSE; I did not install or run it.
Facts checked October 17, 2026
Azure MCP Server 3.0 became stable on October 12, 2026, announced October 14 on the Azure SDK Blog after fifty beta iterations. It is Microsoft's open-source MCP server for letting agents discover and call Azure tools, MIT-licensed in the microsoft/mcp repository. New: operational toolsets for Backup, Resilience Management and the SRE Agent, Terraform and Advisor tooling, opt-in structured responses, and tighter security defaults for newly created resources. I read the blog, the repo and the LICENSE file; I ran nothing. Announcement
What 3.0 adds
The release moves everyday Azure operations into agent reach. Backup tools inspect vaults, policies, protected items, jobs and recovery points, and manage soft delete, immutability and Resource Guards. Resilience Management covers recovery plans, readiness checks, failover validation and drills. The SRE Agent toolset exposes 55 commands around investigations, incidents and remediation plans, and it depends on the Microsoft.App/SREAgentPreview resource provider, a preview dependency worth knowing before you wire it into production.
Terraform tools fetch provider documentation, explore Verified Modules, export existing resources with aztfexport and validate plans with conftest. Advisor surfaces recommendations with cost-impact ranking and remediation guidance; its apply tool returns rules for preparing infrastructure-as-code changes rather than touching live resources. Monitor, Cosmos DB, IoT, Compute, App Service and Managed Lustre round out the new coverage.
Contracts your client will notice
Tool descriptions and input schemas were rebuilt for LLM tool selection, unknown parameters now error instead of being ignored, and a --learn flag lets a client explore commands without executing Azure operations. Structured responses are opt-in: pass --structured-output-mode duplicated or compact to get advertised outputSchema and structuredContent. New operationPlane metadata marks tools as data, control, both or not-applicable.
Reported startup gains are about 39% for targeted CLI command invocations only, Microsoft's own measurement, explicitly not server-wide startup or throughput. Missing resources now return HTTP 404 instead of 500, and logs go to stderr so stdout stays clean JSON-RPC.
Security defaults, scoped honestly
The new defaults apply to resources created through the server, not to anything you already run: new Storage accounts disable Shared Key authentication, new Event Hubs namespaces disable local authentication, new Recovery Services vaults disable public networking, and new NFS shares use RootSquash with encryption in transit. Existing resources are not reconfigured on upgrade.
Endpoint validation through Microsoft.Security.AntiSSRF now covers more cloud-specific endpoints, with namespace-scoped overrides. Communication Services email and SMS send tools are excluded in read-only mode, and validation-failure telemetry omits option values.
The breaking-change list is the real cost
Upgrade notes run long. Resilience commands rename from resilience_ to resiliency_. Advisor listings switch to ARM-style properties wrappers. MySQL and PostgreSQL query tools are documented as destructive, non-idempotent and non-read-only; SQL-verb filtering is removed and in consolidated mode they move to execute_azure_database_query, so your signed-in database permissions are the whole boundary. Namespaces move from Azure.Mcp.Core to Microsoft.Mcp.Core. VM creation now requires an explicit --image. Clients on the 2026-07-28 protocol must send Mcp-Method and Mcp-Name headers on every POST.
If you run 2.0 in a shared deployment, the blog's own advice is to read the full 3.x changelog and test your client before updating. That is correct advice, not boilerplate.
License, maintenance, popularity
MIT, read from the LICENSE file in the microsoft/mcp repository, copyright Microsoft. The repo catalogs Microsoft's official MCP servers and shows steady maintenance: 3,773 stars and 646 forks as I checked on October 17, with hundreds of contributors and recent commits. Popularity is not a quality signal; it is a maintenance signal here. LICENSE file
Why it matters
MCP servers are becoming the control plane between agents and cloud accounts, so their defaults and breaking changes matter more than their feature lists. This one ships defensible defaults for new resources and documents its sharp edges, including which tools can delete data. If your agents touch Azure, the migration notes are the section to read first, and the destructive database tools are the line to highlight for whoever owns permissions.
What I could not confirm
I did not install or run the server, and I did not test any toolset against a live Azure account. The 39% startup figure is Microsoft's own measurement of targeted CLI invocations. SRE Agent tooling depends on a preview resource provider whose availability I did not verify. All tool counts and behaviors come from the announcement and repository documentation.
Explore without executing, from the announcement
# From the announcement: --learn explores commands without executing Azure operations.
azmcp --learn # list toolsets and commands, no Azure calls
azmcp backup vault get --learn # inspect one command's parameters safely
# Structured responses are opt-in at server start:
azmcp server start --structured-output-mode compact
# Read-only mode excludes the Communication Services email/SMS send tools.
# The MySQL/PostgreSQL query tools are destructive and non-read-only:
# your signed-in database permissions are the whole boundary.