Skip to main content
Glama
CyberKnightLabs

vmware-knight

by CyberKnightLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

vm_apply_plan

Destructive

Preview the blast radius of a multi-step VMware change plan, then execute it step by step after explicit confirmation, stopping on failure and reporting rollback availability.

Instructions

[WRITE] Execute a previously created plan step by step.

Without confirm=True this only previews: it returns blast_radius listing every step (index, action, target object), the count and indices of the destructive ones (delete, power off, revert, guest commands...), and blockers — 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.

Each step is shown with its full parameters (passwords redacted). Each destructive step is measured as its own tool would measure it (vm_delete, vm_power_off, vm_revert_snapshot, vm_guest_exec, cluster_delete ...), and that tool's blockers refuse the plan. A step on something an earlier step creates or changes is marked check "deferred": it is measured immediately before it runs, and the plan stops there if it fails.

Refused: a target other than the one the plan was created against (no target is a target of its own), a step its tool would refuse, anything it could not read, a delete_vm step without its acknowledge_blast_radius (from a vm_delete preview), and any iscsi_* or storage_rescan step — those are gated in vmware-storage; run storage_iscsi_* / storage_rescan there.

With confirm=True steps run sequentially. On failure: stops immediately, keeps the plan file with per-step results, and returns rollback_available. On success: deletes the plan file. If a step fails and rollback_available is true, ask the user whether to rollback, then call vm_rollback_plan.

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 returned by vm_create_plan.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.12.10

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 behavioral detail: confirms are preview-only, destructive steps inherit the measuring and blocking semantics of their underlying tools, deferred steps are measured immediately before execution, the plan file is deleted on success and retained on failure, and rollback_available is returned after a failure. This is well beyond what annotations alone convey.

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?

The description is long but well-structured into preview behavior, measurement semantics, refusal cases, and execution outcomes. It is front-loaded with the central purpose and every sentence carries safety-relevant information, though a few clauses are dense enough that they could be tightened without losing clarity.

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, so the description must explain return behavior, and it does: it lists what the blast_radius contains, how destructive steps are measured, what happens on failure (stops, keeps plan file, returns rollback_available) and success (deletes plan file). Combined with the cross-tool routing and rollback guidance, nothing essential is missing for an agent to invoke this tool safely.

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 description coverage is 100%, so the baseline is 3; the schema already documents plan_id, target, and confirm. The description adds extra semantic nuance around confirm=False/True behavior, the requirement that target match the plan's original target, and refusal cases such as delete_vm requiring acknowledge_blast_radius. That pushes it above baseline but not to 5, since the schema already carries most parameter meaning.

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 action and resource: 'Execute a previously created plan step by step.' It immediately separates this tool from plan-creation and rollback siblings by naming the apply workflow and explicitly referencing vm_rollback_plan and vm_create_plan contexts.

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 is explicit about when to use the tool and what the agent must do first: show the preview and get explicit user decision, never set confirm=True on its own, and ask before rolling back. It also lists excluded step types (iscsi_*, storage_rescan) and routes the agent to the correct sibling tools, which is strong, actionable 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