The server can now change Azure state
Microsoft has expanded the Azure Resource Manager Model Context Protocol server from a mainly exploratory interface into a toolset that can create, update, act on and verify Azure resources. New operations cover individual resources and resource groups, provider-defined actions, deployment lifecycle controls, exact-resource reads and cost analysis. Microsoft describes the pattern as query, plan, act and verify within one MCP-driven workflow. That progression is useful, but it also moves the server firmly into privileged infrastructure automation.
Create and update support uses Azure Resource Manager PUT patterns through tools for an individual resource or a resource group. An agent can establish a group, deploy into it and apply a targeted update without switching to a separate console. The convenience should not blur authorisation. Organisations need role assignments that limit which subscriptions, resource types and regions an MCP caller can change, with policy and budget controls applied independently of the model’s interpretation of a request.
The execute_resource_action tool exposes provider-defined POST operations such as restart, start, validation or key retrieval. Schema discovery helps a client identify available actions and construct the expected payload. This is powerful because provider actions are not uniform, and some have consequences beyond an ordinary configuration update. Security teams should treat discovery as information, not permission: an agent learning that an operation exists must not automatically gain authority to invoke it.
Planning and verification surround deployment
Deployment controls now include what-if analysis, creation, status inspection and cancellation. The server can also work with the Bicep MCP server, allowing an agent to author infrastructure as code, compile it to an ARM template and manage the resulting deployment. A what-if result gives reviewers a chance to inspect proposed changes before execution. High-risk workflows should require explicit approval after the preview and should invalidate that approval if the template changes before deployment.
The new get_resource operation retrieves authoritative current state when a client already knows a resource ID. Combined with Resource Graph discovery, it creates a tighter verification loop: find resources at scale, change a selected object and confirm its exact post-action state. Verification must include more than an HTTP success response. Agents should compare the intended properties, policy compliance and service health, then surface any difference rather than declaring completion because ARM accepted the request.
Microsoft has added cost tools for general analysis, AKS-specific costs, public retail prices and negotiated price-sheet downloads. Query grouping can show what is driving month-to-date spend by service or resource group. Bringing cost into the same workflow is sensible because an infrastructure recommendation is incomplete without commercial context. Agents should distinguish public list prices from an organisation’s effective rates and include expected duration, storage, network and licence costs when comparing alternatives.
FinOps enters the same conversational workflow
Cost visibility can also act as a pre-deployment guardrail. A workflow might query current spend, estimate the proposed resource and require approval when the change exceeds a threshold. The MCP server does not replace Azure Policy, budgets or finance controls, which should remain deterministic enforcement layers. Natural-language cost questions are useful for exploration, but the figures behind an approval need a reproducible query and timestamp because cloud prices, discounts and consumption change.
An experimental skills feature can return SKILL.md workflows from the remote server. Clients opt in with an x-mcp-toolset header, then list and retrieve skills for tasks such as VM recommendation, Azure optimisation, AKS cost analysis, policy authoring and ARM template deployment. Skills can make operating procedures easier to discover and reuse. Because the interface is experimental, organisations should pin reviewed versions or copy approved procedures into their own controlled repository before relying on them for production change.
The expanded server illustrates a broader shift in MCP implementations from read-only context towards state-changing enterprise tools. That creates a larger prompt-injection surface. Instructions found in logs, resource names or documentation should never override the user’s stated objective or platform policy. Tool results need provenance, and agents should not expose retrieved keys or negotiated billing data in conversation history. Least privilege, isolated testing and audit logs are prerequisites, not later hardening tasks.
Experimental skills encode repeatable procedures
Azure Resource Manager MCP can now support a coherent operational loop for experienced teams that already understand Azure governance. Its value is reducing context switching and making complex APIs accessible through structured tools. Australian customers should confirm regional service availability and ensure that logs, billing records and any retrieved configuration remain within approved data boundaries. They should also rehearse rollback from an incorrect agent action before granting broad production write access to agents. The product should not be judged by whether an agent can restart or deploy a resource in a demonstration. The real test is whether every proposed action is constrained, previewed, approved where necessary and verified against an independently enforced desired state.