Skip to main content
Glama
CyberKnightLabs

vmware-knight

by CyberKnightLabs
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

vm_guest_provision

Destructive

Execute ordered guest operations to provision a VM; preview steps before applying to avoid incomplete configurations.

Instructions

[WRITE] Provision a VM by running an ordered sequence of guest operations.

Prefer this over repeated vm_guest_exec / vm_guest_upload calls when the steps form one provisioning run. Steps stop on the first failure, so a partial run leaves the guest half-configured. Requires VMware Tools running in the guest.

Without confirm=True this only previews: blast_radius names the VM (name, instance UUID), the guest account and every step it would run, in order, with counts per type, local file sizes and any blockers; nothing runs. Show it to the user. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet. Refused outright: VM not powered on, VMware Tools not running, an empty step list, a step with an unknown type or a missing key, an upload whose local file is missing or unreadable, a service step on a Windows guest, an unreadable identity or status, or a name that matches more than one VM.

Step types:

  • exec: {"type": "exec", "command": "apt-get install -y nginx"}

  • upload: {"type": "upload", "local_path": "...", "guest_path": "..."}

  • service: {"type": "service", "name": "nginx", "action": "start"}

Returns: dict with success, completed_steps, total_steps, results, error, and blast_radius.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
stepsYesOrdered list of step dicts (see Step types).
targetNoOptional vCenter/ESXi target name from config.
confirmNoFalse (default) returns the blast radius and changes nothing. True applies it.
timeoutNoPer-step timeout in seconds (default 300).
vm_nameYesTarget VM name.
passwordYesGuest OS password.
usernameYesGuest OS username.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.12.10

TDQS

A5/5.0
Behavior5/5

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

Annotations already indicate a destructive, non-read-only, non-idempotent operation. The description adds substantial behavioral context: steps stop on first failure leaving the guest half-configured, confirm=False only previews while nothing runs, and the full refusal list is disclosed. This goes well beyond what annotations convey.

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?

Though long, the description is tightly organized and every section earns its place: overview, usage guidance, preview semantics, refusal conditions, step-type examples, and return keys. The most important safety information is front-loaded, and the formatting makes it 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?

For a complex tool with no output schema, the description is remarkably complete. It explains when to use it, prerequisites, failure behavior, preview mode, all refusal conditions, step schema, and return value keys. An agent has enough information to invoke it correctly and safely.

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 coverage is 100%, so parameter names and defaults are already documented. The description adds critical extra meaning: concrete step type schemas with JSON examples, the semantics of confirm (preview vs apply), and the ordered-list behavior for steps. This meaningfully supplements 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?

The description opens with a specific verb and resource: 'Provision a VM by running an ordered sequence of guest operations.' It also distinguishes itself from sibling tools by explicitly preferring this over repeated vm_guest_exec / vm_guest_upload calls when steps form one provisioning run.

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 guidance ('Prefer this over repeated vm_guest_exec / vm_guest_upload calls when the steps form one provisioning run'), names the alternatives, and states a key prerequisite (VMware Tools running in the guest). It also explains when not to apply directly via confirm=True, since the user hasn't seen the preview yet.

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