Skip to main content
Glama
CyberKnightLabs

vmware-knight

by CyberKnightLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

vm_delete_snapshot

Destructive

Delete a VMware snapshot permanently, previewing its blast radius first unless confirmed. Consolidates delta disks and frees space without changing the VM's current state.

Instructions

[WRITE] Permanently delete a named snapshot, consolidating its delta disk into the parent.

Without confirm=True this only previews: it returns blast_radius (VM and instance UUID, the snapshot's name, id and creation time, remove_children, how many child snapshots sit below it and how many snapshots would be removed) and deletes nothing. Show it to the user and get their decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet.

Frees disk space and does NOT change the VM's current state (unlike vm_revert_snapshot). Works while the VM is powered on. Refused: a snapshot name that is not found, a name that matches more than one snapshot on the VM (vSphere allows duplicates; rename one first), and a snapshot tree that cannot be read. Run vm_list_snapshots first for exact names.

Consolidation is slow for old/large deltas (often minutes). By default (wait=False) this returns a task id immediately so it does not block your context — poll it with vm_task_status. Set wait=True only for small snapshots (blocks up to 30 min).

Returns: Dict with action (preview, snapshot_delete_started, snapshot_deleted), blast_radius, and result (carries the task id to poll via vm_task_status).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
waitNoFalse (default) = async, return task id at once; True = block.
targetNovCenter/ESXi target from config.yaml; omit for the default target.
confirmNoFalse (default) returns the blast radius and changes nothing. True applies it.
vm_nameYesExact name of the VM owning the snapshot.
snapshot_nameYesExact snapshot name from vm_list_snapshots output.
remove_childrenNoFalse (default) = children are kept and consolidated; True = delete the entire snapshot subtree below this one as well.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.12.10

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already flag destructiveHint=true, but the description adds crucial behavioral detail: confirm=False only previews, confirm=True actually deletes, the VM state is not changed, deletion works while powered on, and refusal cases are enumerated. It also warns that consolidation is slow and that wait=False returns a task id immediately. No contradiction with annotations exists.

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

Conciseness5/5

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

The description is longer than average, but every paragraph earns its place: safe preview behavior, error conditions, performance warning, and return value mapping. It is front-loaded with the critical [WRITE] marker and the 'do not confirm without showing preview' directive, and the structure makes the information scannable.

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?

There is no output schema, yet the description compensates by stating the action values (preview, snapshot_delete_started, snapshot_deleted), the blast_radius contents, and how to poll the result. It also covers failure modesamentations and performance expectations. An agent has everything needed to call this safely and correctly.

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 the baseline is 3, but the description clearly adds value beyond the schema: it explains the consequence of confirm=False (preview with blast_radius), the meaning of wait=False (async task id), and the effect of remove_children on the snapshot tree. This elevates the parameter understanding beyond raw field descriptions.

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?

The description opens with a specific verb and resource: 'Permanently delete a named snapshot, consolidating its delta disk into the parent.' It also distinguishes itself from vm_revert_snapshot, making its purpose and scope immediately clear. An agent can confidently separate this from sibling tools like vm_create_snapshot and vm_list_snapshots.

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?

The description gives explicit when-to-use and when-not-to-use guidance: run vm_list_snapshots first for exact names, never set confirm=True before the user has seen the preview, and prefer vm_task_status polling over blocking. It even names the sibling that behaves differently (vm_revert_snapshot). This is exemplary usage guidance.

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

Deploy Server

Other Tools