Skip to main content
Glama
CyberKnightLabs

vmware-knight

by CyberKnightLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

vm_rollback_plan

Destructive

Preview or execute rollback of failed VMware plans in reverse order, listing blast radius and skipping irreversible steps.

Instructions

[WRITE] Rollback executed steps of a failed plan in reverse order.

Without confirm=True this only previews: it returns blast_radius listing the rollback steps that would run (in order, with the VMs a rollback deletes) and those skipped as irreversible — and runs 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.

Only call this after vm_apply_plan returns status='failed'; check vm_list_plans first for the plan_id. Irreversible steps (delete_vm, revert_snapshot, etc.) are skipped with a warning. Each destructive rollback step (power off, delete snapshot, cluster delete, host removal) is measured as its own tool measures it, in the preview and again just before it runs; a refused check stops the rollback there and the plan stays 'failed'. Refused on a target other than the one the plan was created against.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoThe vCenter/ESXi target the plan was created against.
confirmNoFalse (default) returns the blast radius and changes nothing. True applies it.
plan_idYesThe plan ID of the failed plan.

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 mark destructiveHint=true, but the description adds preview-only mode without confirm, irreversible steps skipped with warning, per-step destructive measurement with refusal stopping the rollback, and the plan staying 'failed' on refusal. No contradiction with annotations.

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?

Dense and front-loaded, but the final sentence is a fragment and the safety warnings make it longer than strictly minimal. Still, each sentence earns its place for a destructive rollback tool.

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?

Despite no output schema, the description explains what the preview returns (blast_radius with ordered steps and skipped irreversible ones), the failure/refusal behavior, and the preconditions. An agent has enough to call it correctly.

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

Parameters5/5

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

Schema covers all three params, and the description adds critical semantics: confirm=false previews vs true applies, target must be the plan's original target, and plan_id identifies the failed plan. The warning about not setting confirm on one's own initiative is extra value beyond 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+resource: 'Rollback executed steps of a failed plan in reverse order.' This clearly distinguishes it from vm_apply_plan and vm_list_plans and scopes its role in the plan lifecycle.

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 conditions use on vm_apply_plan returning status='failed', directs the agent to check vm_list_plans for plan_id, and instructs not to auto-set confirm=True before the user sees the preview. This is actionable when-to-use 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