Microsoft's November 13, 2026 ARM MCP update describes expanded create/update operations, resource actions, single-resource reads, deployment workflows, and cost tools. It also introduces an experimental, opt-in Skills experience. Microsoft announcement.
My proposed evaluation would follow one reviewable change from resource discovery through the final state check. Record the intended scope, expected effect, approving owner, and recovery procedure before selecting a disposable test resource.
Establish the Permission Boundary
Microsoft Learn says tool calls use the signed-in user's Azure authorization context and translate into ARM API operations. Azure permissions and policy evaluation enforce the boundary. Authentication and governance.
I would have the pilot owner record the intended tenant, subscription, resource group, and operator identity. Ask the resource owner to confirm the permitted scope and identify the operational process that governs the proposed change.
Keep the authorization decision with the pilot record. Another reviewer should be able to establish what the operator was allowed to do and which result would fall outside the approved test.
Inspect the Operation Before the Write
The update describes direct resource and resource-group create/update tools, provider-defined action operations, and schema-discovery tools for supported resource types and actions. Expanded operations.
My acceptance sheet would include the exact target identifier, selected API version, proposed operation, and payload. Have the service owner review those concrete details against the intended outcome before the approved rehearsal proceeds.
For a hypothetical configuration change, preserve the current state and the properties the team expects to change. Record how the operator will identify an unexpected difference and who owns the decision to recover the previous configuration.
Separate Deployment Preview from Execution
Microsoft documents deployment what-if, deployment creation, status retrieval, and cancellation tools as parts of the deployment workflow. Deployment controls.
I would retain the reviewed template, its preview result, and the decision that authorizes the later test deployment. The operator should be able to connect the deployed artifact to the exact proposal the owner accepted.
Define the observation window and expected completion state before starting. Rehearse the escalation process for an operation that remains incomplete and use the current documented behavior to choose the supported recovery action.
Read Back the Exact Resource
The new single-resource retrieval tool supports checking current ARM state for a known resource identifier. Resource-state verification.
My verification would compare the resulting properties with the prewritten expectations and preserve the operation identifier and observation time. Include the workload owner's functional check when a control-plane change affects application behavior.
Have a second engineer review the evidence without coaching from the original operator. Use their questions to improve the record until the team can explain both the final configuration and the effect observed by the workload.
Evaluate Experimental Skills as a Separate Choice
Microsoft labels Skills experimental, disabled by default, and subject to change. Clients opt in to receive the available workflow material. Experimental status.
I would keep that evaluation separate from the basic operation rehearsal. Record which workflow was reviewed, its retrieval date, the client configuration, and the reason the team chose to include it in the proposed test.
Review any resulting tool proposal using the same target, payload, and acceptance record. The adoption decision should establish which behavior the team demonstrated and which experimental dependency requires another review when the client or workflow changes.
Practical Cloud Engineer Takeaway
Record the signed-in context and approved Azure resource scope.
Review the concrete operation, API version, and payload.
Preserve deployment preview evidence and execution ownership.
Read back the exact resource and verify workload behavior.
Treat experimental Skills enablement as a separate adoption decision.
Who Should Care?
Azure platform engineers, infrastructure automation owners, governance teams, and developers evaluating MCP-based control-plane operations.
Bottom Line
The expanded toolset supports a more complete Azure management workflow. A useful pilot makes the proposed write reviewable, verifies the resulting state, and gives the operations team a recovery procedure grounded in the tested configuration.
No MCP connection, permission, skill setting, deployment, resource action, or Azure resource was changed for this article.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments