Skip to main content
Glama

Delete Virtual Machine

delete_virtual_machine
Destructive

PERMANENTLY delete a virtual machine on Cycle. This is IRREVERSIBLE: it destroys the VM and its local volumes, including the base (boot) volume and everything the guest OS wrote to them. A running VM is powered off, not shut down gracefully.

This tool is two-step by design and NOTHING is deleted on the first call:

  1. Call without confirm. The VM is resolved and the response describes exactly what would be destroyed — name, ID, identifier, state, image, when it was created, and its volumes. Present ALL of those details to the user verbatim.

  2. Only after the user explicitly approves deleting that specific VM, call again with confirm:true and virtual_machine set to the exact 24-char hex ID from step 1 (names are not accepted with confirm — the ID binds the deletion to what the user approved).

Never set confirm:true unless the user has just approved this exact deletion; a general instruction like "clean up the environment" is not sufficient. VMs with deletion protection (lock) cannot be deleted until unlocked; reconfigure_virtual_machine with lock:false lifts it, which is itself a change the user must approve. Attached EXTERNAL (SAN) volumes are detached rather than destroyed, but local volumes are gone for good — if the guest holds data worth keeping, copy it out first (run_vm_command).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNoSet true ONLY after the user has explicitly approved deleting this exact VM (shown its name, ID, state, image, creation date, and volumes). Requires virtual_machine to be the exact hex ID from the preview call.
contextNoWhy are you calling this tool? Briefly describe the user's goal.
environmentNoEnvironment the VM lives in. Required when virtual_machine is a name or identifier; ignored when an exact hex ID is given.
wait_secondsNoconfirm only: max seconds to wait for the delete job to complete (default 60). 0 returns immediately after the job is accepted.
conversation_idNoConversation tracking id. Omit on your first tool call; every result then includes a conversation_id line — pass that exact value on all later calls in this conversation.
virtual_machineYesVM to delete. With confirm:true: MUST be the exact 24-char hex ID returned by the preview call.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, but the description adds substantial beyond-annotation context: exactly what is destroyed (VM, local/boot volumes, guest OS writes), the non-graceful power-off behavior, the two-step no-op-on-first-call contract, the lock/deletion-protection block, and external SAN volumes being detached rather than destroyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the critical irreversible warning and structures the two-step flow as a clear numbered list. It is fairly long, but nearly every sentence carries safety-relevant information; minor tightening is possible but nothing is gratuitous.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent tool with no output schema and one required parameter, the description covers everything an agent needs: prerequisites (unlock), what to present to the user, what survives vs is destroyed, and cross-tool alternatives. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so baseline is 3, but the description meaningfully reinforces the most safety-critical parameter constraints: confirm must bind to the exact 24-char hex ID from the preview call, names are not accepted with confirm, and what step-1 returns. This adds operational nuance beyond the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (PERMANENTLY delete) and resource (virtual machine on Cycle) and immediately scopes it against sibling delete tools by naming exactly what gets destroyed (VM plus local/boot volumes). The irreversible power-off vs graceful shutdown distinction further disambiguates it from reconfigure or power tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly defines the two-step flow and when to proceed, including the exact trigger for confirm:true ('user has just approved this exact deletion') and an explicit exclusion ('a general instruction like clean up the environment is not sufficient'). It also routes to alternatives (reconfigure_virtual_machine for lock:false, run_vm_command to copy data out) with conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources