Skip to main content
Glama
CyberKnightLabs

vmware-knight

by CyberKnightLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

vm_clean_slate

Destructive

Revert a VM to its baseline snapshot to reset it to a clean state. Previews the blast radius before making any changes, then powers off and restores the snapshot.

Instructions

[WRITE] Revert a VM to its baseline snapshot (Clean Slate).

Without confirm=True this only previews: it returns blast_radius (VM identity, power state and whether it is powered off first, the snapshot and when it was taken, snapshot count, blockers) and changes nothing. Show that to the user and get their explicit decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet.

With confirm=True: powers off the VM first if it is running, then reverts to the named snapshot. Use this to reset a lab/dev VM to a clean starting state after a task completes. Irreversible — everything written since the snapshot is lost. Refused: no snapshot of that name, more than one, or a VM whose state cannot be read. Returns a dict (action, blast_radius).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoOptional vCenter/ESXi target name from config.
confirmNoFalse (default) returns the blast radius and changes nothing. True applies it.
vm_nameYesName of the VM to revert.
snapshot_nameNoSnapshot name to revert to (default: "baseline").baseline

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.12.10

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations by explaining the preview-only mode, blast_radius contents, automatic power-off behavior, irreversibility, refusal conditions, and the return dict. An agent knows exactly what will happen in each confirm mode and what can go wrong.

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?

Four short, dense paragraphs front-load the action and then walk through preview, apply, irreversibility, and refusal cases. Every sentence earns its place; the length is justified by the destructive and guarded nature of the operation.

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 tool with no output schema, the description supplies everything needed: mode semantics, side effects, failure conditions, and return shape. The remaining parameter details are already covered by the input schema, so there is no essential gap.

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 descriptions already cover all parameters, so the baseline is 3. The description adds meaningful value by explaining the safety-critical semantic difference between confirm=False and confirm=True, including the power-off side effect and the named snapshot default. This reinforces rather than merely repeats the schema.

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?

Opens with a specific verb and resource: 'Revert a VM to its baseline snapshot (Clean Slate).' This clearly scopes the tool to baseline reset rather than generic snapshot operations, and the [WRITE] marker matches the mutating nature. The purpose is immediately distinguishable from siblings like vm_revert_snapshot.

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

Usage Guidelines4/5

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

Provides clear guidance on when to use it ('reset a lab/dev VM... after a task completes') and strong guardrail behavior ('Do not set confirm=True on your own... Show that to the user'). It does not explicitly name the alternative tool for arbitrary snapshot reverts, so it misses the highest bar, but the usage context is otherwise explicit.

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