[Microsoft Azure] Get one resource provider's registration state and the full resourceTypes list it exposes in a subscription, including each type's supported locations and apiVersions. Useful for confirming a resource type is available in the region you intend to deploy to before a create fails.

[Microsoft Azure] Get one Azure subscription's details: subscriptionId, displayName, state, tenantId, authorizationSource (the mechanism granting access, e.g. RoleBased or Legacy), managedByTenants (the partner directories with delegated access — how you confirm a GDAP relationship exists) and subscriptionPolicies including its quota id and spending limit. Requires a subscription id from azure_list_subscriptions.

[Microsoft Azure] List the Azure regions available to a subscription. Each item carries name (the value every create/update tool wants, e.g. eastus), displayName, regionalDisplayName, metadata (regionType Physical | Logical, regionCategory Recommended | Other, geographyGroup, physicalLocation, pairedRegion) and availabilityZoneMappings. Use it before creating a resource group or any regional resource — a region name that is valid in one subscription can be unavailable in another.

[Microsoft Azure] List the Azure resource providers in a subscription and their registration state. Each item carries namespace (e.g. Microsoft.Compute), registrationState (Registered | NotRegistered | Registering | Unregistered) and resourceTypes with their locations and apiVersions. This is the tool to reach for when a create call fails with NoRegisteredProviderFound or MissingSubscriptionRegistration: the provider is simply not registered in that subscription yet, and azure_register_resource_provider fixes it.

[Microsoft Azure] List the Azure subscriptions the signed-in user can see — the ENTRY POINT for this connector. Each item carries subscriptionId, displayName, state (Enabled | Warned | PastDue | Disabled | Deleted), tenantId and subscriptionPolicies. The subscriptionId returned here is required by nearly every other azure_* tool. Pass entraTenant to enumerate a CUSTOMER's subscriptions under your GDAP relationship instead of your own — CSP-provisioned customer subscriptions normally place the partner's Admin Agents group in the Owner role, so an MSP user usually has real access there. An EMPTY result is a valid answer, not an error: it means the user has consented but holds no Azure RBAC in the directory. Returns ARM's {value:[...]} envelope; up to 1000 items across 10 pages per call, with nextLink returned when more remain.

[Microsoft Azure] List the Microsoft Entra directories (tenants) the signed-in user can access — their own plus every customer directory they hold a delegated relationship with. Each item carries tenantId, displayName, domains, tenantCategory (Home | ProjectedBy | ManagedBy) and countryCode. Use this to DISCOVER the tenantId values to pass as entraTenant elsewhere; tenantCategory ManagedBy identifies a customer you administer. Pairs with graph_list_delegated_admin_customers on the Microsoft Graph connector, which reports the GDAP relationship's roles and expiry.

[Microsoft Azure] Register a resource provider in a subscription, making its resource types deployable there. This is ADDITIVE and idempotent — registering an already-registered provider is a no-op, and registration removes no resource and interrupts no workload, which is why it is not marked destructive. Registration is asynchronous: the response returns registrationState 'Registering', and azure_get_resource_provider reports when it reaches 'Registered' (usually under a minute). Use this after a deployment fails with NoRegisteredProviderFound or MissingSubscriptionRegistration.

[Microsoft Azure] Unregister a resource provider from a subscription. DESTRUCTIVE: while unregistering does not delete existing resources, it makes the provider's types UNDEPLOYABLE in the subscription and breaks any automation that creates them — and Azure refuses the call outright if resources of those types still exist. Treat it as a deliberate teardown step, not a cleanup nicety. Prefer leaving unused providers registered: registration costs nothing.

[Microsoft Azure] Get the full BEFORE and AFTER snapshots for one resource change, plus the property-level diff. This is the tool that answers "what exactly did someone change on this NSG at 03:14" — the change list from azure_query_resource_changes tells you a change happened, this tells you what it was. Requires the resourceId and the changeId from that query.

[Microsoft Azure] Run a KQL query and return FACET summaries — value counts for the columns you name — alongside the rows. Use it to profile an estate before drilling in: faceting on 'type', 'location' or 'subscriptionId' answers "what is actually deployed here and where" in one call, which is the natural first question about a customer you have just gained access to. Supply the facet columns as a comma-separated list of column names that your query projects.

[Microsoft Azure] List configuration CHANGES to Azure resources in a time window — the "what changed and when" surface, and usually the fastest route from an incident to its cause. Each change carries a changeId, the changeType (Create | Update | Delete), the timestamp, and which properties moved. Scope it to a single resource with resourceId, or to a subscription and window to sweep everything. Pass the returned changeId to azure_get_resource_change_details for the full before/after. Azure retains change history for 14 days.

[Microsoft Azure] Run a KQL query across many subscriptions at once — the most powerful read in this connector. Prefer it over fanning out per-subscription list calls: one query answers questions like "every VM without a backup", "all public IPs by region" or "resources missing an owner tag" across an entire estate, and Microsoft positions it as the mitigation for resource-provider throttling. Tables include Resources, ResourceContainers (subscriptions and resource groups), PolicyResources, SecurityResources, HealthResources and AdvisorResources. Example: "Resources | where type =~ 'microsoft.compute/virtualmachines' | project name, location, resourceGroup, subscriptionId". Pagination is BODY-level and unlike the rest of this connector: when the response carries $skipToken and resultTruncated is 'true', pass that token back as skipToken to get the next page. Scope with subscriptionIds (recommended: pass the customer's subscriptions from azure_list_subscriptions) or leave empty to query everything the user can see.

[Microsoft Azure] Run a KQL query that returns only a COUNT, across many subscriptions at once. A thin convenience over azure_query_resources: it appends a summarize to your query so you get a number rather than a truncated page of rows. Use it for "how many VMs are running across all customers" or "how many resources are missing the cost-centre tag" — questions where the rows themselves are noise and where returning them would hit the row cap and mislead. Supply the filter portion only, without a summarize of your own.

[Microsoft Azure] Check whether a resource group exists WITHOUT retrieving it, returning {"exists": true|false}. Cheaper and unambiguous compared with reading azure_get_resource_group and interpreting a 404 — use it as a precondition before a create, or to confirm a delete finished.

[Microsoft Azure] Create a resource group, or update an existing one's tags. Not destructive: creating adds an empty container, and updating an existing group changes only its tags — the resources inside are untouched, and Azure does not allow a group's location to move. Requires a region name from azure_list_locations. Tags are supplied as JSON, e.g. {"environment":"production","owner":"helpdesk"}. NOTE the tag semantics: this call REPLACES the group's tag set, so include every tag you want to keep — use azure_update_resource_group_tags for a merge instead.

[Microsoft Azure] Delete a resource group AND EVERY RESOURCE INSIDE IT. This is the single most destructive tool in the connector: Azure deletes the entire contents — virtual machines, disks, databases, storage accounts and their data — with no further confirmation and no undo. Call azure_list_resource_group_resources first and show the caller exactly what will be destroyed. The operation is ASYNCHRONOUS: this returns as soon as Azure accepts the request, the accepted response has no body and carries no tracking reference you can follow, and deletion continues for minutes afterwards; poll azure_check_resource_group_exists to confirm completion. A resource protected by a delete lock or a policy blocks the whole operation.

[Microsoft Azure] Export a resource group as an ARM template — the JSON that would recreate its resources. Read-only despite being an HTTP POST: it produces a document and changes nothing. Use it to capture a working configuration before a risky change, or to clone an environment. Pass resource ids to export a subset, or omit them to export the whole group. Note that Azure's exporter is imperfect for some resource types and may emit parameters the caller must fill in; treat the result as a strong starting point rather than a guaranteed-deployable artifact.

[Microsoft Azure] Get one resource group: id, name, location, tags, managedBy and properties.provisioningState. A 404 here is a legitimate empty answer — the group does not exist in that subscription — and is often a sign the caller meant a CUSTOMER's subscription and omitted entraTenant.

[Microsoft Azure] List every resource inside one resource group. Each item carries id, name, type, location, sku, kind, managedBy and tags. Use this before azure_delete_resource_group to show exactly what a deletion would destroy — the delete removes all of this without a further prompt from Azure. Filter with an OData expression such as "resourceType eq 'Microsoft.Compute/virtualMachines'", and expand with "createdTime,changedTime,provisioningState" for lifecycle detail.

[Microsoft Azure] List the resource groups in a subscription. Each item carries id, name, location, tags, managedBy and properties.provisioningState. Filter with an OData expression, most usefully by tag: "tagName eq 'environment' and tagValue eq 'production'". Returns ARM's {value:[...]} envelope; up to 1000 items across 10 pages per call, with nextLink returned when more remain. Requires a subscription id from azure_list_subscriptions.

[Microsoft Azure] Update a resource group's tags via PATCH, leaving everything else alone. Not destructive: tags carry no access or workload semantics, and this is a partial update — tags you omit are preserved rather than cleared, which is the difference from azure_create_resource_group. Supply tags as a JSON object, e.g. {"costCentre":"CC-1042"}.

[Microsoft Azure] Delete any Azure resource by its full ARM resource id. DESTRUCTIVE and generally irreversible: for a data-bearing resource such as a storage account or a managed disk, the data goes with it. You must supply the api-version that resource's provider expects — azure_get_resource_provider lists them. Prefer a dedicated family's delete tool where one exists: it pins the version and often surfaces type-specific safeguards. Deletion is asynchronous for most types; the 202 response carries the Location URL to poll.

[Microsoft Azure] Get any Azure resource by its full ARM resource id — the /subscriptions/... string every Azure object carries and every list tool returns. Works for resource types this connector has no dedicated family for. You must supply the api-version that resource's PROVIDER expects; azure_get_resource_provider lists the supported apiVersions for each type. If you do not know it, prefer the dedicated family's get tool, which pins the version for you.

[Microsoft Azure] Get the tags on any Azure resource, resource group or subscription by its ARM id. Returns {properties:{tags:}}. Read this before azure_set_resource_tags, which REPLACES the whole tag set — merging by hand against a stale view is how tags get silently dropped.

[Microsoft Azure] List every resource in a subscription, of any type. Each item carries id, name, type, location, sku, kind, plan, managedBy and tags. Filter with an OData expression — by type ("resourceType eq 'Microsoft.Storage/storageAccounts'"), by tag ("tagName eq 'owner'"), or by group ("resourceGroup eq 'prod-rg'") — and expand "createdTime,changedTime,provisioningState" for lifecycle detail. For questions spanning MANY subscriptions, azure_query_resources is the better tool: it answers in one call where this would need one call per subscription and can trip ARM's throttling. Up to 1000 items across 10 pages per call, with nextLink when more remain.

[Microsoft Azure] Move resources to a different resource group or subscription. DESTRUCTIVE: a move changes every resource's ARM id, which silently breaks role assignments, policy assignments, locks, alert rules, diagnostic settings and any automation or template that references the old id — and while the move runs, the SOURCE and TARGET groups are both LOCKED against other write operations. Not every resource type supports moving, and Azure validates the whole set atomically: one unmovable resource fails the entire operation. Run azure_validate_move_resources first — it performs the same validation without moving anything. The operation is asynchronous; the 202 response carries the Location URL to poll.

[Microsoft Azure] REPLACE the entire tag set on any Azure resource, resource group or subscription. Tags carry no access-control or workload semantics — nothing stops running and nothing is deleted — so this is not marked destructive, but note the replace semantics: any tag you omit is REMOVED. Read azure_get_resource_tags first and include everything you want to keep, or use azure_update_resource_tags to merge instead. Tags are a JSON object, e.g. {"environment":"production","costCentre":"CC-1042"}.

[Microsoft Azure] Merge, replace or delete tags on any Azure resource, resource group or subscription. Additive by default and not destructive — tags carry no access or workload semantics. operation controls the semantics: Merge adds or overwrites the tags you supply and PRESERVES the rest (the safe default); Replace swaps the whole set, removing omitted tags; Delete removes exactly the tags you name. Prefer Merge unless you specifically intend to clear tags.

[Microsoft Azure] Validate a resource move WITHOUT performing it — the safe preview for azure_move_resources. Runs Azure's full move validation and reports which resources would fail and why. Explicitly NOT destructive: marking a safe-preview tool destructive would defeat its purpose, since the whole point is that an agent can run it freely before asking a human about the real move. The check is asynchronous; a 202 with no errors means validation passed.

[Microsoft Azure] Assess which operating-system patches are available for a virtual machine. Not destructive: nothing is installed, nothing reboots, and the guest is only inspected — this is the safe half of the patching pair and the right thing to run before proposing azure_install_vm_patches. An assessment takes a few minutes and reports the count of patches by classification (Critical, Security, Other), the reboot requirement and the assessment's own status. The machine must be RUNNING with a healthy guest agent; a stopped or deallocated machine cannot be assessed. The operation is ASYNCHRONOUS — the result also lands on the machine's instance view, so azure_get_vm_instance_view shows the latest assessment afterwards.

[Microsoft Azure] Attach one or more EXISTING managed disks to a virtual machine as data disks. Not destructive: it only adds storage, and nothing already on the machine is changed or removed. The disks must already exist in the same region as the machine — this does not create them — and each LUN must be unique on the machine; omit lun to let Azure assign one. Read azure_get_vm first to see the LUNs already in use and the machine's maxDataDiskCount for its size (azure_list_vm_sizes reports that limit). Attaching makes the volume visible to Azure; the guest OS still has to initialise, partition and mount it. Set deleteOption to "Delete" only when the disk should be destroyed along with the machine — the default "Detach" leaves it behind. The operation is ASYNCHRONOUS and returns immediately with the machine's updated storage profile.

[Microsoft Azure] Convert a legacy virtual machine's unmanaged (page-blob) disks to managed disks. Destructive and IRREVERSIBLE: there is no supported conversion back, the machine's disk resource ids all change — breaking any script, backup policy, role assignment or template that referenced the old blob URIs — and the source VHD blobs are left behind in their storage account still costing money. The machine MUST already be stop-deallocated (azure_deallocate_vm) or the call fails, so this is inherently an outage. Snapshot the disks first. The operation is ASYNCHRONOUS and can run for a long time on large disks; poll azure_get_vm for the new managedDisk ids.

[Microsoft Azure] Create a virtual machine, or replace an existing one's model wholesale. Not marked destructive because the normal use is additive — it stands a new machine up — but read the replace semantics before pointing it at a name that already exists: this is a PUT, so the properties document you send REPLACES the stored one, and a data disk, NIC or extension setting you leave out is removed from the machine. For a change to an existing machine prefer azure_update_vm, which patches. Before creating: pick a region with azure_list_locations, a size with azure_list_vm_sizes, and a publisher/offer/SKU/version with the azure_list_vm_image_* tools; the network interface must already exist, since ARM will not create one for you. The operation is ASYNCHRONOUS — this returns as soon as ARM accepts the request, the accepted response has no body and carries no tracking reference you can follow, and provisioning continues for several minutes; poll azure_get_vm_instance_view for the outcome. Costs begin as soon as the machine allocates.

[Microsoft Azure] Install an extension on a virtual machine, or update one already installed. Not marked destructive: installing an agent is additive and Azure does not restart the machine to do it. Note two real consequences anyway — an extension runs code in the guest with high privilege, so it deserves the same scrutiny as a script; and because this is a PUT, reusing an EXISTING instance name replaces that extension's settings wholesale rather than merging them, which for an agent like the Monitor agent can change what it collects. Read azure_list_vm_extensions first to see what is installed and under which instance names. Secrets belong in properties.protectedSettings, which Azure encrypts and never returns on a read. The operation is ASYNCHRONOUS — this returns immediately and installation continues for a few minutes; poll azure_get_vm_extension with expand="instanceView" for the outcome.

[Microsoft Azure] Deallocate a virtual machine — shut it down AND release its compute resources, which is what stops the compute bill. Destructive: the machine stops serving, sessions drop, in-memory work is lost, the contents of the temporary/resource disk (D: on Windows, /mnt on Linux) are DISCARDED, and because the machine leaves its host a dynamically-assigned public IP is released and will differ on next start. Managed OS and data disks and their data survive and continue to be billed for storage. This is the correct tool for "stop this VM to save money"; azure_power_off_vm keeps billing it. Set hibernate=true to preserve the running memory state instead of discarding it — the machine must have been created with hibernation enabled. The operation is ASYNCHRONOUS and returns immediately.

[Microsoft Azure] DELETE a virtual machine. What is lost depends on each attached resource's deleteOption, which the caller should read from azure_get_vm BEFORE calling this: a disk, NIC or public IP marked "Delete" is destroyed with the machine and its data is unrecoverable, while one marked "Detach" is left behind in the resource group still costing money. There is no recycle bin and no undo — a machine without a backup or a snapshot cannot be brought back. Confirm the identity of the machine with azure_get_vm first; a name is easy to mistake between environments. Set forceDeletion only for a machine that is already broken: it skips Azure's graceful shutdown, so in-flight guest writes are lost. The operation is ASYNCHRONOUS — this returns immediately with a 202 and deletion continues for minutes; a delete lock or a policy on the machine blocks it outright.

[Microsoft Azure] Uninstall an extension from a virtual machine. Destructive: the in-guest agent is removed and whatever it was doing stops — removing the Monitor agent blindly ends log and metric collection for that machine, removing an antimalware or backup extension ends protection, and removing a domain-join or disk-encryption extension can leave the machine in a state that needs manual repair. The extension's own configuration is gone with it and would have to be redeployed from scratch. Read azure_get_vm_extension first and tell the caller what the extension is before removing it. Some extensions run an uninstall script in the guest, so a brief disruption is possible. The operation is ASYNCHRONOUS and returns immediately.

[Microsoft Azure] Detach one or more data disks from a virtual machine. Destructive: the volume disappears from a running guest, so anything reading or writing it fails immediately, and an application or database whose files live on that disk will break until the disk is reattached. The disk resource itself SURVIVES with its data intact and keeps costing storage — this removes the attachment, not the disk. Dismount the volume inside the guest before calling. detachOption="ForceDetach" is a last resort for a disk a previous detach left stuck: it does not wait for outstanding writes to flush, so data in flight IS lost. Read azure_get_vm first to confirm which diskId sits on which LUN. The operation is ASYNCHRONOUS and returns immediately with the machine's updated storage profile.

[Microsoft Azure] Get one virtual machine's full model: size, OS profile, image reference, OS and data disks with their LUNs and managed-disk ids, network interface ids, boot-diagnostics settings, identity, zones and tags. Pass expand="instanceView" to append the runtime view (power state, extension health, disk status) in the same call, or expand="userData" to include the base64 user-data blob. A 404 is a legitimate empty answer — no such machine in that group — and is frequently a sign the caller meant a CUSTOMER's subscription and omitted entraTenant. A 403 means the signed-in user's Azure RBAC does not grant read on this machine; StackJack cannot widen that.

[Microsoft Azure] Mint time-limited SAS URIs for a virtual machine's boot diagnostics — consoleScreenshotBlobUri (a bitmap of the console at the moment of capture) and serialConsoleLogBlobUri (the boot serial log). TREAT THE RESPONSE AS A CREDENTIAL: whoever holds either URL can fetch that content from anywhere on the internet, with no Entra sign-in and no conditional access, until it expires — and a console screenshot can show whatever was on screen, including an unlocked session or an error dump. This is the first thing to fetch for a machine that reports PowerState/running but is unreachable: the screenshot usually shows the blue screen, the fsck prompt or the GRUB menu that explains it. Marked destructive despite changing nothing on the machine, because it DISCLOSES access (the disk-grant rule, one family over). Boot diagnostics must already be ENABLED on the machine (properties.diagnosticsProfile.bootDiagnostics.enabled on azure_get_vm); if it is not, expect a 409 rather than empty URIs. The URIs expire, by default after 120 minutes; choose the shortest expiry that can possibly work.

[Microsoft Azure] Get one extension on one virtual machine by its instance name — the name the extension was DEPLOYED under, which is often not the same as its publisher type (azure_list_vm_extensions returns both). Returns publisher, type, typeHandlerVersion, settings and provisioningState; pass expand="instanceView" for the live status and the substatuses that carry an extension's own stdout/stderr. Protected settings are never returned by Azure — a secret passed to an extension cannot be read back through this tool or any other. A 404 means no extension with that instance name is deployed on the machine.

[Microsoft Azure] Get a virtual machine's RUNTIME state — this is the tool that answers "is this machine on?". Returns the statuses array whose PowerState/* code is one of PowerState/running, PowerState/stopped (still allocated and still billed), PowerState/deallocated (compute released, not billed) or PowerState/starting|stopping|deallocating, alongside per-extension health, per-disk status, the OS name and version, the hypervisor generation and any boot-diagnostics blob URIs. Do NOT read properties.provisioningState from azure_get_vm for this — that field describes the last ARM write, not the power state. This is also the tool to poll after any of the asynchronous power actions to confirm the outcome.

[Microsoft Azure] Get one managed run command on a virtual machine, and with expand="instanceView" its RESULT — executionState (Running, Succeeded, Failed, TimedOut), exitCode, startTime, endTime, and the captured standard output and standard error. This is how the outcome of a long-running managed command is collected: the deployment returns as soon as Azure accepts it, and the output lands here afterwards. Where a command was configured with outputBlobUri the large output goes to that blob instead and only a summary appears here. A 404 means no managed run command with that name exists on the machine — check azure_list_vm_run_commands for the deployed names.

[Microsoft Azure] Get one built-in run command document by its command id — the full definition, including the script Azure will execute and the parameters array naming every value the command expects and which of them are required. This is the tool to call BEFORE azure_run_vm_command with a built-in id: it turns a guessed parameter set into a checked one, and the resulting script text is exactly what the caller can be shown before they approve running it on a customer machine. Requires a command id and region from azure_list_vm_run_command_documents; a 404 means no such id in that region.

[Microsoft Azure] Install operating-system patches on a virtual machine now. Destructive: patching changes the guest, cannot be rolled back through this API, and with rebootSetting "IfRequired" or "Always" it REBOOTS the machine — dropping every session and interrupting the service on it. Run azure_assess_vm_patches first and show the caller what would be installed. rebootSetting must be one of "IfRequired", "Never" or "Always"; choosing "Never" leaves the machine in a pending-reboot state that some patches need before they take effect. maximumDuration is an ISO-8601 duration (for example PT4H) after which Azure stops starting new patch installs. Supply windowsParametersJson OR linuxParametersJson to match the guest OS — classificationsToInclude, kbNumbersToExclude and the like. The operation is ASYNCHRONOUS and can run for hours; the outcome lands on the machine's instance view.

[Microsoft Azure] List the extensions installed on one virtual machine — the in-guest agents Azure manages, such as the Monitor agent, the Dependency agent, Custom Script, the antimalware extension and the domain-join extension. Each item carries publisher, type, typeHandlerVersion, autoUpgradeMinorVersion, settings and provisioningState. Pass expand="instanceView" to include each extension's live status and its last message, which is where an agent that installed but failed to run reports why. This is the inventory to read before azure_delete_vm_extension so the caller sees exactly what is installed.

[Microsoft Azure] List one publisher's image offers in a region — the second rung of the image coordinate. Under MicrosoftWindowsServer the offer is WindowsServer; under Canonical it is one of the ubuntu-* offers. Requires an exact publisher name from azure_list_vm_image_publishers: the value is case-sensitive and a near-miss returns a 404 rather than a suggestion. Returns a bare JSON array, not the {value:[...]} envelope.

[Microsoft Azure] List the image publishers available in one region — the first rung of the four-part image coordinate (publisher, offer, SKU, version) that azure_create_or_update_vm needs. Familiar values are MicrosoftWindowsServer, Canonical, RedHat and MicrosoftWindowsDesktop. Note that publishers are REGIONAL: an image present in one region may be absent from another, so always ask for the region the machine will be created in. Returns a bare JSON array, not the usual {value:[...]} envelope, and it is a long list — narrow it by name rather than reading it all back to the caller.

[Microsoft Azure] List the SKUs under one publisher/offer in a region — the third rung of the image coordinate, and the one that names the actual edition: 2022-datacenter-azure-edition, 22_04-lts-gen2, and so on. The gen1/gen2 distinction lives here and matters, because a gen2 image will not boot on a VM size that only supports gen1. Requires exact publisher and offer names from azure_list_vm_image_publishers and azure_list_vm_image_offers. Returns a bare JSON array, not the {value:[...]} envelope.

[Microsoft Azure] List the published versions of one publisher/offer/SKU image in a region — the fourth and last rung of the image coordinate. Versions are Major.Minor.Build strings and are ordered by Azure, not by the array position, so pass orderby="name desc" with top=1 when you only want the newest. When creating a machine you can usually skip this and set version to "latest" in the image reference, but note that "latest" is resolved once at deployment time and the machine does NOT track later releases. Returns a bare JSON array, not the {value:[...]} envelope.

[Microsoft Azure] List the sizes THIS virtual machine can actually be resized to. The answer is narrower than azure_list_vm_sizes because Azure only offers sizes supported by the physical cluster the machine is currently allocated on. A size missing from this list is not necessarily unavailable in the region — deallocating the machine first (azure_deallocate_vm) frees it from its cluster and usually widens the set. Read this before issuing a size change through azure_update_vm, so the update does not fail after the machine has already been taken down.

[Microsoft Azure] List the BUILT-IN run command documents Azure publishes for a region — the vetted scripts an agent can invoke by id instead of writing its own. Each item carries $schema, id (e.g. RunPowerShellScript, RunShellScript, EnableRemotePS, IPConfig, ifconfig), osType, label and description. Prefer one of these over an ad-hoc script wherever it fits: a named document is auditable and its behaviour is fixed, where free-form script text is not. Read azure_get_vm_run_command_document next to learn what parameters an id takes before calling azure_run_vm_command.

[Microsoft Azure] List the MANAGED run commands deployed on one virtual machine. These are persistent child resources (created by a template, the portal, the CLI or PowerShell) and are a different thing from the one-shot azure_run_vm_command action: each has a name, a source script, a timeout and a provisioningState, and it survives until it is deleted. Pass expand="instanceView" to include each one's execution state, exit code and captured output. This is the tool that answers "what has been scheduled to run on this machine?". Returns ARM's {value:[...]} envelope, paged.

[Microsoft Azure] List every virtual machine size Azure offers in one region, with each size's numberOfCores, memoryInMB, maxDataDiskCount, osDiskSizeInMB and resourceDiskSizeInMB. Use this when CHOOSING a size for a new machine. It is NOT the right tool for resizing an existing one — availability there is constrained by the cluster the machine already sits on, which is what azure_list_vm_resize_options answers. Requires a region name from azure_list_locations. Note this reports capability, not price or current regional capacity: a size listed here can still fail to allocate.

[Microsoft Azure] List every virtual machine in a subscription, across all resource groups. Each item carries id, name, location, zones, tags, properties.hardwareProfile.vmSize, properties.storageProfile (OS and data disks), properties.networkProfile and properties.provisioningState. Note that provisioningState describes the last ARM write, NOT whether the machine is powered on — pass expand="instanceView" to get the PowerState/* status codes inline, or call azure_get_vm_instance_view for one machine. Requires a subscription id from azure_list_subscriptions. Returns ARM's {value:[...]} envelope; up to 1000 items across 10 pages per call, with nextLink returned when more remain.

[Microsoft Azure] List the virtual machines inside one resource group. Same item shape as azure_list_vms but scoped to a single group, which is the cheaper call when the caller already knows where the machines live. Pass expand="instanceView" to include runtime power state. A 404 here means the resource GROUP does not exist in that subscription; an empty {"value":[]} means the group exists and holds no virtual machines — the two are different answers and worth distinguishing for the caller.

[Microsoft Azure] Trigger Azure's pending host maintenance on a virtual machine NOW, instead of waiting for the platform's self-service window to close and the maintenance to be applied automatically. Destructive: applying maintenance interrupts the machine — expect a reboot or a live migration pause — and in-memory work is lost. The point of running it deliberately is to choose WHEN that interruption happens. It fails with a 409 on a machine that has no maintenance pending, which is a legitimate answer rather than a fault; check maintenanceRedeployStatus in azure_get_vm_instance_view first. The operation is ASYNCHRONOUS and returns immediately.

[Microsoft Azure] Power off (stop) a virtual machine, leaving it ALLOCATED. Destructive: the machine stops serving, every session drops and in-memory work is lost. Understand the billing difference before choosing this over azure_deallocate_vm — a powered-off machine keeps its host reservation and its dynamic IP, and you are STILL CHARGED for its compute. Choose this when the machine must keep its IP or must be able to start again immediately; choose deallocate to stop the compute bill. skipShutdown issues a hard power cut with no guest shutdown at all, which risks filesystem corruption and unflushed application writes — reserve it for a machine that is already hung. The operation is ASYNCHRONOUS and returns immediately.

[Microsoft Azure] Reapply a virtual machine's ARM model to the platform — Azure re-pushes the stored configuration to the machine's host. This is the remedy for a machine stuck in a failed provisioningState after an update that Azure recorded but never finished applying. Marked destructive out of caution rather than certainty: the operation is a platform-level re-application whose effect can include a service interruption on a running machine, and the safe assumption for an agent is that the machine may bounce. It changes no stored configuration of its own — whatever is in the model is simply applied again. The operation is ASYNCHRONOUS and returns immediately.

[Microsoft Azure] Redeploy a virtual machine — shut it down, MOVE it to a new Azure host, and power it back on. This is the standard remedy for a machine that is unreachable for reasons on the platform side rather than in the guest. Destructive: it is a full outage of several minutes, in-memory work is lost, and the contents of the temporary/resource disk are DISCARDED because the machine lands on different hardware. Managed disks and their data follow the machine. Try azure_restart_vm first — it is the cheaper interruption — and reach for this only when a restart has not helped. The operation is ASYNCHRONOUS and returns immediately; confirm with azure_get_vm_instance_view.

[Microsoft Azure] Reimage a virtual machine — reset its OS disk back to the original image. THIS IS DATA LOSS BY DESIGN: every change made to the operating system disk since the machine was created is destroyed, including installed software, configuration, local user profiles and anything an application wrote outside a data disk. Attached DATA disks are not touched. On a machine with an ephemeral OS disk the reset is the only way to recover it; on an ordinary machine treat this as a last resort and confirm with a human first. Set tempDisk=true to also reset the temporary/resource disk (ephemeral OS disks only). The operation is ASYNCHRONOUS — this returns immediately and the machine is unavailable for several minutes.

[Microsoft Azure] Restart a virtual machine. Destructive because it is a service interruption on a live customer machine: every session on it drops, anything running in memory is lost, and an application that does not survive a reboot cleanly may not come back. Confirm with a human before restarting production. The machine's disks, IP configuration and identity are unaffected. The operation is ASYNCHRONOUS — this returns immediately and the machine is unavailable for a minute or more; poll azure_get_vm_instance_view for PowerState/running.

[Microsoft Azure] Run a command INSIDE a customer's virtual machine, through the Azure guest agent. The script executes as SYSTEM on Windows and as root on Linux, with no prompt, no sandbox and no review by Azure — this is arbitrary code execution on a live machine, which is why it is marked destructive regardless of what the script happens to do. Always show the caller the exact script text and get explicit approval before calling. Prefer a built-in commandId from azure_list_vm_run_command_documents over free-form script where one fits, and read azure_get_vm_run_command_document first to learn which parameters it takes. The machine must be running with a healthy guest agent, output is truncated by Azure at roughly 4096 bytes per stream, and the call can take up to 90 minutes — use a managed run command instead for anything long. Returns ARM's value array of statuses carrying the combined stdout/stderr.

[Microsoft Azure] Set the tags on a virtual machine, leaving every other property untouched. Not destructive: tags carry no access-control or workload semantics, nothing stops running and no data is lost. Note the REPLACE semantics — Microsoft.Compute treats the tags map as a single value, so any tag you omit is removed. Read the machine with azure_get_vm first and include everything you want to keep, or use the provider-agnostic azure_update_resource_tags with operation="Merge" when you only want to add one tag without knowing the rest.

[Microsoft Azure] Simulate the eviction of a SPOT virtual machine, so an owner can test that their workload survives being evicted. Destructive: this is not a dry run — the machine is really evicted, which means it is deallocated or deleted according to its own evictionPolicy, and in-memory work and temporary-disk contents are lost. Only valid on a spot machine (properties.priority == "Spot" on azure_get_vm); a regular machine returns an error. Check the machine's evictionPolicy before calling: an evictionPolicy of "Delete" means the simulated eviction DELETES it. The operation is ASYNCHRONOUS and returns immediately.

[Microsoft Azure] Start (power on) a stopped or deallocated virtual machine. Not destructive — starting is purely additive: nothing on the machine is lost and no in-flight work is interrupted. The one consequence worth telling a caller about is cost: a deallocated machine is not billed for compute, and starting it resumes that billing. Starting a deallocated machine also reallocates it on a fresh host, so a dynamically-assigned public IP normally CHANGES; a static IP does not. The operation is ASYNCHRONOUS — this returns immediately and the machine takes up to a few minutes to reach PowerState/running; confirm with azure_get_vm_instance_view.

[Microsoft Azure] Update an existing virtual machine with a PATCH — the tool to use for a resize, a boot-diagnostics change, an identity change or a licence-type change. Not marked destructive: a property you omit at the TOP level is left alone, so this cannot silently wipe a machine's configuration the way a full replace can. Be aware that ARM merges only at the top level — a nested COLLECTION you do send, such as storageProfile.dataDisks, replaces the stored one entirely, so use azure_attach_vm_data_disks rather than patching the disk list by hand. A resize is the common case and has a real side effect: changing hardwareProfile.vmSize RESTARTS the machine, and if the new size is not on the current cluster Azure deallocates and reallocates it, which changes the dynamic IP. Confirm the size is offered by azure_list_vm_resize_options first. The operation is ASYNCHRONOUS: it returns immediately and continues in the background.

[Microsoft Azure] Check whether a storage account name is free BEFORE trying to create it. Returns or {nameAvailable:false, reason, message} — reason is AccountNameInvalid for a name that breaks the rules (3-24 characters, lower-case letters and digits only, no hyphens) or AlreadyExists for a name someone else has already taken. Storage account names are globally unique across ALL of Azure, not just the tenant, so a perfectly reasonable name is often taken by a stranger. Read-only despite being an HTTP POST: it reserves nothing and changes nothing. Run this before azure_create_storage_account so a name clash is a clean answer rather than a failed create.

[Microsoft Azure] Create a blob container in a storage account. Not destructive: it adds an empty container and cannot overwrite an existing one — ARM answers 409 if the name is taken. Container names are 3-63 characters, lower-case letters, digits and hyphens, and must start with a letter or digit. publicAccess controls ANONYMOUS internet access and defaults to None, which is the safe value: "Blob" lets anyone who knows a blob's URL read that blob without credentials, and "Container" additionally lets anyone LIST the container's contents. Only choose either deliberately, and note they are ignored anyway if the account has allowBlobPublicAccess set to false. metadataJson attaches user-defined name/value pairs, e.g. {"owner":"helpdesk"}.

[Microsoft Azure] Create an Azure Files share in a storage account. Not destructive: it adds an empty share and cannot overwrite an existing one — ARM answers 409 if the name is taken. Share names are 3-63 characters, lower-case letters, digits and hyphens. quotaGiB is the share's maximum size in GiB: up to 5120 on a standard account (or up to 102400 if the account has large file shares enabled), and on a premium FileStorage account it is the PROVISIONED size that you are billed for whether or not it is used, so pick it deliberately. accessTier applies to standard accounts and trades cost against transaction price: TransactionOptimized, Hot or Cool. enabledProtocols is SMB (the default) or NFS; NFS requires a premium FileStorage account and cannot be changed after creation.

[Microsoft Azure] Create a new storage account. Not destructive: it adds an empty account and cannot overwrite an existing one's data — ARM answers 409 if the name is taken. Check the name with azure_check_storage_account_name_availability first (names are globally unique across all of Azure, 3-24 lower-case letters and digits) and the sku/region pairing with azure_list_storage_skus. skuName is the redundancy setting and is the decision that matters most: Standard_LRS keeps three copies in one datacentre, Standard_ZRS spreads them across availability zones, Standard_GRS and Standard_RAGRS replicate to a paired region. kind should almost always be StorageV2. propertiesJson passes advanced settings through verbatim, e.g. {"minimumTlsVersion":"TLS1_2","allowBlobPublicAccess":false,"supportsHttpsTrafficOnly":true}. The create is ASYNCHRONOUS: this returns as soon as ARM accepts the request, the accepted response has no body and carries no tracking reference you can follow, and the account takes up to a minute to appear — confirm it with azure_get_storage_account.

[Microsoft Azure] Create a Storage queue in an account. Not destructive: it adds an empty queue and cannot overwrite an existing one — ARM answers 409 if the name is taken. Queue names are 3-63 characters, lower-case letters, digits and hyphens, and must start and end with a letter or digit. This creates the queue only; sending and receiving MESSAGES is a data-plane operation and is deliberately outside this connector, so an application still needs its own credentials to use the queue. metadataJson attaches user-defined name/value pairs.

[Microsoft Azure] Create a Storage table in an account. Not destructive: it adds an empty table and cannot overwrite an existing one — ARM answers 409 if the name is taken. Table names are 3-63 alphanumeric characters and must start with a letter; hyphens are NOT allowed, which is the usual reason a name that works for a container is rejected here. This creates the table only; reading and writing ROWS is a data-plane operation and is deliberately outside this connector.

[Microsoft Azure] Delete a blob container AND EVERY BLOB INSIDE IT. DESTRUCTIVE: the whole container's contents go at once, and this connector cannot show you what they were — blob listing is on the data plane and deliberately out of scope, so nothing here can tell you how many blobs or how many gigabytes are about to be lost. Whether the deletion is recoverable depends entirely on the account: check azure_get_blob_service_properties, and if containerDeleteRetentionPolicy.enabled is false the delete is PERMANENT the moment it succeeds. A container under a legal hold or a locked immutability policy cannot be deleted at all and the call fails — azure_get_blob_container reports both flags. Ask a human before calling this on any container you did not just create.

[Microsoft Azure] Delete an Azure Files share AND EVERY FILE AND FOLDER INSIDE IT. DESTRUCTIVE: a share is usually a mapped network drive somebody depends on, so this both destroys data and breaks users mid-session, and this connector cannot show you what is inside — file listing is on the data plane and deliberately out of scope. Whether it is recoverable depends on the account: check azure_get_file_service_properties, and if shareDeleteRetentionPolicy.enabled is false the delete is PERMANENT immediately. azure_get_file_share with includeUsage true reports shareUsageBytes, which is the best available signal of how much data is at stake. Ask a human before calling this on any share you did not just create.

[Microsoft Azure] Delete a storage account AND EVERYTHING INSIDE IT. DESTRUCTIVE and normally irreversible: every blob, every file share and its files, every queue and its messages, and every table and its rows go with the account, and account-level soft delete is OFF unless someone explicitly enabled it. Container and blob soft-delete policies do NOT protect you here — they only cover deletions inside a surviving account. Before calling this, show the caller what will be lost: azure_list_blob_containers, azure_list_file_shares, azure_list_storage_queues and azure_list_storage_tables together enumerate the account's top-level contents, though none of them can see the data inside. The delete is asynchronous; a resource lock or an Azure Policy deny assignment blocks it outright.

[Microsoft Azure] Delete a Storage queue AND EVERY MESSAGE STILL IN IT. DESTRUCTIVE and irreversible: queues have no soft delete, so the messages are gone the moment the call succeeds, and any application still writing to the queue starts failing. This connector CANNOT SEE the messages — queue contents are on the data plane and deliberately out of scope — so it cannot tell you whether the queue is empty or holds a backlog of unprocessed work. That blindness is the reason to be careful: confirm with whoever owns the application before deleting a queue you did not just create.

[Microsoft Azure] Delete a Storage table AND EVERY ROW IN IT. DESTRUCTIVE and irreversible: tables have no soft delete, so every entity is gone the moment the call succeeds. This connector CANNOT SEE the rows — table contents are on the data plane and deliberately out of scope — so it cannot tell you whether the table is empty or holds years of application records, and azure_list_storage_tables reports names only. Storage tables are frequently used as an application's primary datastore, so treat a delete here as equivalent to dropping a database table in production: confirm with whoever owns the application first.

[Microsoft Azure] Get one blob container's ARM properties: publicAccess (None, Blob or Container — anything other than None means anonymous internet reads are possible), metadata, leaseStatus/leaseState/leaseDuration, hasImmutabilityPolicy, hasLegalHold, immutableStorageWithVersioning, lastModifiedTime and etag. Returns no blobs and no blob content. Read this before azure_delete_blob_container: a container carrying a legal hold or a locked immutability policy cannot be deleted at all, and the delete will fail rather than partially succeed. A 404 means either the account or the container does not exist.

[Microsoft Azure] Get the account-wide Blob service settings: deleteRetentionPolicy (blob soft delete and its retention in days), containerDeleteRetentionPolicy (container soft delete — this is what decides whether azure_delete_blob_container is recoverable), isVersioningEnabled, changeFeed, restorePolicy (point-in-time restore), cors and defaultServiceVersion. Read this BEFORE deleting a container or a blob-bearing account: if containerDeleteRetentionPolicy.enabled is false, a delete is permanent immediately. These are settings only — no blob content is returned or reachable from this connector.

[Microsoft Azure] Get the account-wide Azure Files settings: shareDeleteRetentionPolicy (share soft delete and its retention in days — this decides whether azure_delete_file_share is recoverable), protocolSettings.smb (the SMB versions, authentication methods, kerberos ticket encryption and channel encryption the account will accept) and cors. The SMB protocol settings are the usual cause of a client that can mount a share from one machine but not another. Settings only — no file content is returned or reachable from this connector.

[Microsoft Azure] Get one Azure Files share's ARM properties: shareQuota (provisioned GiB), accessTier, enabledProtocols, rootSquash, leaseStatus, metadata, lastModifiedTime and etag. Set includeUsage to true to also return shareUsageBytes — the actual consumed capacity, which is the number you need before shrinking a quota, because Azure refuses a quota below current usage. Returns no files and no file content. A 404 means either the account or the share does not exist; a soft-deleted share is not returned here at all — use azure_list_file_shares with expand "deleted" to see it.

[Microsoft Azure] Get one storage account's full configuration: kind, sku, location, tags, accessTier, primaryEndpoints, encryption, minimumTlsVersion, allowBlobPublicAccess, allowSharedKeyAccess, publicNetworkAccess and the networkAcls firewall rules. This is also how you READ the account's network rules — there is no separate get-network-rules tool, because ARM returns them inside properties.networkAcls here. Set expand to geoReplicationStats for the geo-redundancy lag of a GRS account, or blobRestoreStatus for an in-flight point-in-time restore. Returns NO keys and NO account contents. A 404 means no account of that name exists in that resource group; storage account names are globally unique, lower-case letters and digits only, 3-24 characters.

[Microsoft Azure] Get the account's lifecycle management policy — the rule set that automatically tiers blobs to Cool or Archive and DELETES them after an age threshold. Returns properties.policy.rules, each with a filter (blob prefixes and blob types) and actions (tierToCool, tierToArchive, delete, with daysAfterModificationGreaterThan / daysAfterLastAccessTimeGreaterThan). Read this before investigating "our files vanished": a delete action here removes data on a schedule with no further prompt, and it is the single most common cause of unexplained blob loss in a healthy account. A 404 is a legitimate empty answer meaning no policy is configured, not an error.

[Microsoft Azure] Acquire, renew, change, release or break a LEASE on a blob container. A lease is an exclusive write lock: while one is held, only the holder of the lease id may delete the container, and Acquire will fail for anyone else. Marked DESTRUCTIVE because two of its actions interfere with something already running — Break forcibly ends a lease another process is holding, and Release drops it — which can let a delete or a reconfiguration through that the lease existed precisely to prevent, or make the holder's next operation fail. action must be Acquire, Renew, Change, Release or Break. Acquire returns the leaseId you must supply for Renew, Change and Release; leaseDuration is 15-60 seconds, or -1 for an infinite lease. Break takes an optional breakPeriod in seconds. Note this is the CONTAINER lease, not a blob lease — blob leases live on the data plane and are out of scope here.

[Microsoft Azure] List the blob containers in a storage account, as ARM resources. Each item carries name, etag and a properties block with publicAccess, lastModifiedTime, leaseStatus, leaseState, leaseDuration, hasImmutabilityPolicy, hasLegalHold and metadata. It does NOT list the blobs inside a container — blob content is on the data plane and is deliberately outside this connector. namePrefix filters to containers whose name starts with that string (it is a prefix match, not a substring search); set includeDeleted to true to also see soft-deleted containers still inside their retention window, which is how you confirm whether a deleted container can still be restored. A 404 means the storage account does not exist; an empty {value:[]} means it has no containers.

[Microsoft Azure] List the Azure Files shares in a storage account, as ARM resources. Each item carries name, etag and a properties block with shareQuota (the provisioned size in GiB), accessTier, enabledProtocols (SMB or NFS), leaseStatus, lastModifiedTime and metadata. It does NOT list the files inside a share — file content is on the data plane and is deliberately outside this connector. namePrefix is a prefix match on the share name. Set expand to "deleted" to include soft-deleted shares still inside their retention window, "snapshots" to include share snapshots, or "deleted,snapshots" for both. An empty {value:[]} on a real account simply means it has no file shares — many blob-only accounts do not.

[Microsoft Azure] Return the storage account's ROOT ACCESS KEYS in plain text. Understand exactly what this hands the caller: each key grants FULL read, write and delete access to every blob, every file, every queue and every table in the account, from anywhere the account firewall allows, with no Microsoft Entra sign-in, no role assignment, no MFA and no per-user audit trail. A leaked key is equivalent to handing over the whole account, and it stays valid until someone regenerates it. Marked DESTRUCTIVE even though it mutates nothing, because it DISCLOSES a credential — that classification is deliberate and must not be "fixed" to read-only. Do not include the key in a chat transcript, a ticket or a log. Prefer Entra-based access (a role assignment) wherever the consumer supports it; if a key really must be shared, plan the rotation before you disclose it. Set includeKerberosKeys to also return kerb1/kerb2 on an account with Active Directory authentication enabled.

[Microsoft Azure] Report how many storage accounts the subscription has used against its per-region quota, as {value:[{unit, currentValue, limit, name:{value, localizedValue}}]}. This is the QUOTA surface, not a consumption or capacity report — it answers "can we still create a storage account in this region?", not "how many gigabytes are stored". Check it when azure_create_storage_account fails with a SubscriptionMaximumStorageAccountsExceeded-style error. Requires a region name from azure_list_locations.

[Microsoft Azure] List every storage account in a subscription. Each item carries id, name, location, kind (StorageV2, BlobStorage, FileStorage), sku.name (the redundancy setting, e.g. Standard_LRS or Standard_GRS), tags and a properties block with primaryEndpoints, accessTier, provisioningState, allowBlobPublicAccess, minimumTlsVersion, supportsHttpsTrafficOnly and networkAcls. This is the account INVENTORY — it never touches account contents. Requires a subscription id from azure_list_subscriptions; a 403 means the signed-in user has no Reader role on that subscription. Returns ARM's {value:[...]} envelope, up to 1000 accounts across 10 pages per call, with nextLink when more remain.

[Microsoft Azure] List the storage accounts inside ONE resource group, with the same fields as azure_list_storage_accounts. Prefer this when the caller already knows the group — it is a single narrow call, where the subscription-wide list can return hundreds of accounts. A 404 means the resource group itself does not exist in that subscription (often a sign the caller meant a CUSTOMER's directory and omitted entraTenant); an empty {value:[]} means the group exists but holds no storage accounts.

[Microsoft Azure] List the Storage queues in an account. METADATA ONLY: each item carries the queue's name, ARM id and user-defined metadata key/value pairs. It does NOT return queue MESSAGES, message counts or message content — those are on the data plane and are deliberately outside this connector, so this tool cannot tell you whether a queue is backed up. Use it to inventory queues, to find one an application is misconfigured against, or to identify orphaned queues before deleting them. namePrefix is a prefix match on the queue name.

[Microsoft Azure] List the storage SKUs the subscription may deploy: each item carries name (Standard_LRS, Standard_GRS, Standard_ZRS, Premium_LRS, ...), tier, kind, the locations it is offered in, and a restrictions array explaining any region or quota block. Read this before azure_create_storage_account so the sku and region you pick are actually available to this subscription — a wrong pairing fails the create with an unhelpful 400. The list runs to several hundred entries; lower maxItems when you only need to confirm one SKU.

[Microsoft Azure] List the Storage tables in an account. METADATA ONLY: each item carries the table's name, ARM id and any stored access policies (signedIdentifiers). It does NOT return table ROWS, entities, row counts or any customer data — those are on the data plane and are deliberately outside this connector. Use it to inventory tables and to identify orphaned ones before deleting them; note that this tool cannot tell you whether a table still holds data, so confirm with the owning application before calling azure_delete_storage_table.

[Microsoft Azure] Regenerate one of the storage account's root access keys. DESTRUCTIVE on two counts. First, it BREAKS every existing consumer of that key IMMEDIATELY and without warning — applications, backup jobs, Functions and Logic Apps holding connection strings, mounted SMB drives, and every shared access signature that was signed with it. Failures appear as 403 AuthenticationFailed from that moment, and there is no undo: the old key value is gone for good. Second, the response CONTAINS both keys in plain text, so this discloses a credential exactly as azure_list_storage_account_keys does. The safe procedure is the two-key rotation: confirm every consumer is using key1, regenerate key2, move the consumers to key2, then regenerate key1. Inventory the consumers before you call this — Azure will not tell you who was using the key. keyName must be key1, key2, kerb1 or kerb2; kerb1/kerb2 exist only on an account with Active Directory authentication enabled.

[Microsoft Azure] Revoke ALL of the account's user delegation keys, invalidating every Microsoft Entra-signed shared access signature issued against it. DESTRUCTIVE: this is a blunt, account-wide instrument with no way to revoke a single SAS — every identity-based SAS anyone has handed out for this account stops working at once, and any application or partner relying on one starts failing with 403. It is the correct emergency response to a leaked user delegation SAS, and the wrong tool for routine cleanup. Note what it does NOT do: account-key-signed SAS tokens are unaffected, because they derive from the root keys — for those, use azure_regenerate_storage_account_key instead. Returns an empty body on success.

[Microsoft Azure] Set the account-wide Blob service settings — soft delete, container soft delete, versioning, change feed, point-in-time restore and CORS. Not destructive: this is a settings change and deletes no data. It is normally used to make an account SAFER, by turning soft delete on. Read the current settings with azure_get_blob_service_properties first, because this PUT replaces the properties object: omitting deleteRetentionPolicy on an account that had soft delete enabled TURNS IT OFF, which quietly removes the safety net protecting future deletions. Example propertiesJson: {"deleteRetentionPolicy":{"enabled":true,"days":30},"containerDeleteRetentionPolicy":{"enabled":true,"days":30},"isVersioningEnabled":true}.

[Microsoft Azure] Set the account-wide Azure Files settings — share soft delete and its retention, the SMB protocol settings (accepted versions, authentication methods, kerberos ticket encryption, channel encryption) and CORS. Not destructive: this is a settings change and deletes no file data. It is normally used to make an account SAFER, by turning share soft delete on. Read the current settings with azure_get_file_service_properties first, because this PUT replaces the properties object: omitting shareDeleteRetentionPolicy on an account that had share soft delete enabled TURNS IT OFF, which is what decides whether a later azure_delete_file_share is recoverable — the safety net disappears silently and nothing reports it. Be equally careful with protocolSettings.smb: narrowing the accepted SMB versions or authentication methods can disconnect clients that mount these shares today, which looks like an outage rather than a settings change. Example propertiesJson: {"shareDeleteRetentionPolicy":{"enabled":true,"days":30}}.

[Microsoft Azure] Replace the storage account's firewall (networkAcls) via PATCH. Not destructive — nothing is deleted and no data is touched — but treat it with the same care as one: a wrong rule set CUTS OFF ACCESS to a live account for every application, backup job and user outside the addresses you allow, and it takes effect within a minute. The most common way to lock yourself out is setting defaultAction to Deny without listing the caller's own public IP, or without bypass "AzureServices" for the Azure platform services that need in. Read the current rules with azure_get_storage_account (properties.networkAcls) first: this call REPLACES the whole networkAcls object, so any ipRules or virtualNetworkRules you omit are removed. Example networkAclsJson: {"defaultAction":"Deny","bypass":"AzureServices,Logging,Metrics","ipRules":[{"value":"203.0.113.4","action":"Allow"}],"virtualNetworkRules":[]}.

[Microsoft Azure] Set the account's lifecycle management policy — the rules that automatically tier blobs to Cool or Archive and delete them past an age threshold. The call itself is a settings write and deletes nothing, so it is not marked destructive, but READ THE CONSEQUENCE: a rule containing a delete action will permanently remove matching blobs on Azure's schedule, starting within about 24 hours, with no further prompt and no per-blob confirmation. Get the current policy with azure_get_storage_lifecycle_policy first — this PUT REPLACES the entire rule set. Confirm the account's soft-delete settings with azure_get_blob_service_properties before adding any delete action, so a mistaken filter is recoverable. Example policyJson: {"rules":[{"enabled":true,"name":"archive-logs","type":"Lifecycle","definition":{"filters":{"blobTypes":["blockBlob"],"prefixMatch":["logs/"]},"actions":{"baseBlob":{"tierToCool":{"daysAfterModificationGreaterThan":30}}}}}]}.

[Microsoft Azure] Update an existing blob container's anonymous-access level or metadata via PATCH. Not destructive: no blobs are touched and the container is not replaced. The common and important use is REMEDIATION — setting publicAccess to None on a container that was left open to anonymous internet reads. Going the other way (None to Blob or Container) exposes the container's blobs to anyone on the internet who knows or can guess the URL, so make that change only on explicit instruction. Supplying metadataJson replaces the container's metadata set; omit it to leave metadata alone.

[Microsoft Azure] Update an existing Azure Files share's quota, access tier or metadata via PATCH. Not destructive: it is a partial update, no files are touched, and the share is not replaced. Growing a quota is safe and takes effect immediately. SHRINKING one is where care is needed: Azure refuses a quota below the share's current usage, so read shareUsageBytes with azure_get_file_share (includeUsage true) first — and a quota set just above current usage will start failing writes for users as soon as the share grows into it. Changing accessTier on a standard account re-rates both storage and transaction costs and can trigger a one-off charge. enabledProtocols cannot be changed after creation.

[Microsoft Azure] Update an existing storage account's SKU, tags or settings via PATCH. Not destructive: it is a partial update — anything you omit is left alone, no data is touched, and an account's location and name can never change. Common uses are retiering (accessTier Hot to Cool via propertiesJson), tightening TLS, or turning off anonymous blob access. Be aware that some settings have real blast radius even though nothing is deleted: setting allowSharedKeyAccess to false immediately breaks every application authenticating with an account key, and lowering minimumTlsVersion requirements can break older clients. Pass propertiesJson verbatim, e.g. {"accessTier":"Cool","allowBlobPublicAccess":false}. To change the firewall specifically, prefer azure_set_storage_account_network_rules.

[Microsoft Azure] Check whether a specific private IP address is free in a virtual network, and get suggested alternatives when it is not. Returns {available:true|false, availableIPAddresses:[...]}. Use it before pinning a static IP on a NIC or a load balancer front end — Azure rejects a duplicate at write time with an error that does not say which resource already holds the address, and this call answers that question in advance. Note it reports availability within the VNET's address space, so an address outside every subnet prefix reports unavailable rather than raising an error.

[Microsoft Azure] Create an empty network security group, or update its tags. Not destructive as used here: a new NSG carries only Azure's default rules and is attached to nothing, so it filters no traffic until a subnet or NIC is pointed at it. Deliberately does NOT take a rules array — rules are managed one at a time through azure_create_nsg_rule so that each security-boundary change is an explicit, individually-reviewable call rather than a bulk replace that could silently drop existing rules. Creating an NSG changes nothing on its own; attaching it does, via azure_create_subnet.

[Microsoft Azure] Create or replace a security rule in a network security group. DESTRUCTIVE DESPITE CREATING NOTHING DESTRUCTIVE-SOUNDING: this is a security-boundary change that takes effect within seconds across every subnet and NIC the NSG is attached to, and Azure raises no alert about it. An Allow rule with sourceAddressPrefix "*" or "Internet" on port 3389 or 22 exposes every machine in scope to the whole internet — the single most damaging call in this family. It is also a PUT: replacing an existing rule name discards every field you do not send, so read azure_get_nsg_rule first. Priority is 100-4096 and lower wins; a new rule at a lower priority than an existing deny silently overrides it. Confirm the intent with a human before opening anything inbound from outside the customer's own address space.

[Microsoft Azure] Create a public IP address resource, or replace an existing one's definition. Not destructive when creating: a new address is attached to nothing and routes no traffic until something references it. Two constraints Azure enforces and reports badly: a Standard-SKU address MUST be Static (Dynamic is rejected), and the dnsSettings label must be globally unique within the region, so a taken label fails with a conflict rather than a name suggestion. Standard is the right default — it is zone-redundant and Basic is retired for new deployments. This is a PUT, so replacing an existing resource discards fields you do not send, and changing the allocation method of an in-use address is what actually releases and reassigns it.

[Microsoft Azure] Create or replace a route in a route table. DESTRUCTIVE DESPITE CREATING SOMETHING, for the same reason an NSG rule write is: this redirects live traffic across every subnet the table is attached to, within seconds, with no alert anywhere in Azure. A 0.0.0.0/0 route with nextHopType "None" black-holes ALL outbound traffic from those subnets — including the management path you are using — and one pointing at a virtual appliance that is down does the same thing less obviously. Adding a route that covers the subnet you are connected from can lock you out of the machines in it. nextHopIpAddress is only valid, and is required, when nextHopType is VirtualAppliance. Azure matches the longest prefix, so a /32 overrides a broader route regardless of order.

[Microsoft Azure] Create an empty route table, or update its tags and BGP setting. Not destructive as used here: a new table holds no routes and is attached to no subnet, so it changes nothing until azure_create_route adds an entry and a subnet is pointed at it through azure_create_subnet. Deliberately does NOT take a routes array — routes are added one at a time so each traffic-path change is individually reviewable rather than hidden inside a bulk replace. Setting disableBgpRoutePropagation to true on an EXISTING table is the one sharp edge here: it immediately stops every attached subnet from learning on-premises routes over VPN or ExpressRoute.

[Microsoft Azure] Create a subnet in a virtual network, or replace an existing one. Not destructive when CREATING: it carves an unused range out of the network's address space. UPDATING carries the connector's sharpest silent trap and is why azure_get_subnet exists — this is a PUT that REPLACES the properties object, so omitting networkSecurityGroupId DETACHES the NSG and leaves the subnet with no filtering, and omitting routeTableId removes forced tunnelling, sending traffic that was going through a firewall straight out instead. Neither raises an error; both take effect immediately. Always read the subnet first and pass back every value you are not deliberately changing. The address prefix must sit inside the virtual network's address space and must not overlap another subnet.

[Microsoft Azure] Create a virtual network, or replace an existing one's definition. Not destructive when CREATING: a new network is an empty container. UPDATING is a different matter and the reason to read azure_get_virtual_network first — this is a PUT with no partial-update option, so the properties object you send REPLACES what is there. Omitting the subnets array from an existing network is rejected while resources occupy it, but omitting a subnet's networkSecurityGroup or routeTable silently DETACHES them, removing a firewall or a forced-tunnel route without any error. Supply addressPrefixes as a JSON array, e.g. ["10.0.0.0/16"], and subnets as a JSON array, e.g. [{"name":"web","properties":{"addressPrefix":"10.0.1.0/24"}}]. Address space cannot overlap a network this one is peered with.

[Microsoft Azure] Create a peering from this virtual network to another. Not destructive: it adds a route between two networks and removes nothing. THE CRITICAL DETAIL — a peering is ONE-DIRECTIONAL as an object and must be created on BOTH networks before any traffic flows. Creating only this side leaves peeringState=Initiated and nothing works, which reads like a broken peering rather than a half-finished one, so plan the second call before making the first. The two address spaces must NOT overlap; Azure rejects an overlapping peering. allowGatewayTransit belongs on the HUB side and useRemoteGateways on the SPOKE side — setting both on one side is a common misconfiguration that Azure accepts and that then fails to route.

[Microsoft Azure] Delete a network interface. Azure refuses while the NIC is attached to a virtual machine, so this only succeeds on an interface that is already detached — which is exactly the case where it is easy to delete the wrong one, because a detached NIC gives no hint of what it used to serve. Deleting it RELEASES its private IP address: a machine rebuilt later gets a different address unless the configuration was static and is recreated by hand, and anything pinned to the old address (firewall rules, DNS records, application config) silently points at nothing. Read azure_get_network_interface first and keep the ipConfigurations block if the address matters.

[Microsoft Azure] Delete a network security group and every rule in it. Destructive: this REMOVES FILTERING. Azure refuses while the NSG is still attached to a subnet or NIC, so a success means it was already detached — but that is exactly the dangerous case to think about, because whatever it used to protect has been running unfiltered since it was detached. The rules are not recoverable; read azure_get_network_security_group first if there is any chance the caller wants them rebuilt. Deleting an NSG never blocks traffic — it can only ever allow more.

[Microsoft Azure] Delete a security rule from a network security group. Destructive in BOTH directions, which is why it is flagged regardless of what the rule did: removing a Deny rule OPENS whatever it was blocking, and removing an Allow rule BREAKS an application that was depending on it. The change is live within seconds and nothing in Azure announces it. There is no undo — read azure_get_nsg_rule first and keep the definition if there is any chance it needs rebuilding. Note that deleting a rule does not restore a "default" for that traffic: evaluation simply falls through to the next matching rule, which may be one of Azure's built-in defaults.

[Microsoft Azure] Delete a public IP address resource. THE ADDRESS ITSELF IS LOST, not just the resource: a static address goes back into Azure's regional pool the moment this succeeds and cannot be reclaimed, so anything the customer's partners, firewalls or DNS records pinned to it breaks permanently. That is the whole risk here, and it is invisible in the API's response. Azure refuses while the address is attached to a NIC, load balancer or gateway, so success means it was already detached — which is also when its history is least obvious. Confirm with a human before deleting any static address that has ever been published.

[Microsoft Azure] Delete a route from a route table. Destructive in both directions, like deleting an NSG rule: removing a route does not restore a neutral state, it falls back to Azure's system route or a BGP-learned one for that prefix — so deleting a route that forced traffic through a firewall appliance sends that traffic STRAIGHT OUT to the internet instead, unfiltered and unlogged, which is the opposite of an outage and much harder to notice. The change is live within seconds across every subnet the table is attached to. Read azure_list_routes first and keep the definition if there is any chance it needs rebuilding.

[Microsoft Azure] Delete a subnet from a virtual network. Destructive: it removes an address range that live workloads may be addressed within, and recreating it does NOT restore what was there — the subnet's resource id changes, so NSG associations, route tables, private endpoints and any template referencing the old id break. Azure refuses while a NIC, gateway, private endpoint or delegated service still occupies it, so read azure_get_subnet with expand="ipConfigurations" first and show the caller what is in the way rather than letting the call fail. An emptied subnet that was carrying a delegation for a managed service is the case to be most careful with: the service can recreate resources into it at any moment.

[Microsoft Azure] Delete a virtual network and every subnet inside it. Destructive and not undoable: recreating the network does NOT restore anything that referenced it, because every resource is bound to a subnet by resource id and those ids change. Azure refuses while any NIC, gateway, private endpoint or delegated service still occupies a subnet, so a success here means the network was already empty — but peerings from OTHER networks are removed with it, silently severing traffic those networks were relying on. Read azure_get_virtual_network with expand="subnets/ipConfigurations" and azure_list_vnet_peerings first, and show the caller both. The operation is ASYNCHRONOUS: this returns a 202 immediately and deletion continues afterwards.