Skip to main content
Glama
vmware-skills

vmware-vdi

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

pool_push_image

Destructive

Apply a pending image to an instant-clone pool after reviewing the blast radius. Shows affected desktops and in-session counts, then schedules the push upon confirmation.

Instructions

[WRITE] Apply the pending image to an instant-clone pool — RECREATES EVERY DESKTOP in it.

Highest blast radius in the family: the preview states affected-desktop and in-session counts before you confirm, plus blast_radius.occupancy — "determined" when those counts can be believed, "unknown" when sessions exist that cannot be attributed to any pool or farm. confirm=True schedules the apply. Show blast_radius to the user and wait for their decision. Do not set confirm=True on your own because the user asked for this earlier: they have not seen the blast radius yet. Audited.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoHorizon target from config.yaml; omit to use the default.
confirmNoFalse (default) returns the blast radius and changes nothing. True schedules the push.
pool_idYesThe pool id (from pool_list).
logoff_policyNoWAIT_FOR_LOGOFF (default) or FORCE_LOGOFF.WAIT_FOR_LOGOFF
stop_on_errorNoHalt the rolling push on the first machine error (default True).
acknowledge_unknown_occupancyNoOnly consulted when the preview reports blast_radius.occupancy == "unknown", where in_session_count is a lower bound rather than a count and confirm=True is refused. Setting it True pushes on an unverified occupancy — check session_list first; the acknowledgement is recorded in the audit row. Ignored when occupancy is "determined".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.2.0
    • changedInput schema / properties / confirm / description
      Previous value: -"False previews the blast radius; True schedules the push."New value: +"False (default) returns the blast radius and changes nothing. True schedules the push."
  2. Changed7 schema fields changedv1.1.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / acknowledge_unknown_occupancy
      Added value: +{
+  "default": false,
+  "description": "Only consulted when the preview reports blast_radius.occupancy == \"unknown\", where in_session_count is a lower bound rather than a count and confirm=True is refused. Setting it True pushes on an unverified occupancy — check session_list first; the acknowledgement is recorded in the audit row. Ignored when occupancy is \"determined\".",
+  "title": "Acknowledge Unknown Occupancy",
+  "type": "boolean"
+}
    • addedInput schema / properties / confirm / description
      Added value: +"False previews the blast radius; True schedules the push."
    • addedInput schema / properties / logoff_policy / description
      Added value: +"WAIT_FOR_LOGOFF (default) or FORCE_LOGOFF."
    • addedInput schema / properties / pool_id / description
      Added value: +"The pool id (from pool_list)."
    • addedInput schema / properties / stop_on_error / description
      Added value: +"Halt the rolling push on the first machine error (default True)."
    • addedInput schema / properties / target / description
      Added value: +"Horizon target from config.yaml; omit to use the default."
  3. First observedv1.0.1

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 and readOnlyHint=false, but the description adds critical behavioral detail: every desktop is recreated, confirm=False is a no-op preview, confirm=True schedules the destructive action, occupancy can be 'determined' or 'unknown', and the operation is audited. No contradiction with the annotations.

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 dense but every sentence earns its place: the destructive warning is front-loaded, the preview/confirm protocol is explicit, and the closing 'Audited.' adds useful context without padding. It is appropriately sized for a high-risk operation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema, the description does a good job explaining preview fields, occupancy semantics, and the confirmation flow. It is slightly incomplete in that it does not state what confirm=True returns after scheduling, such as a task identifier or how the agent should monitor the resulting operation.

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 description adds value beyond the schema by tying confirm and acknowledge_unknown_occupancy to the blast_radius occupancy states and the required user-decision protocol, which clarifies their real-world semantics. The remaining parameters are adequately explained by 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 states a specific verb and resource ('Apply the pending image to an instant-clone pool') and immediately escalates the risk with 'RECREATES EVERY DESKTOP' and 'Highest blast radius in the family.' This makes the tool's purpose and scope unmistakable and separates it from lower-impact pool or machine operations.

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?

It gives an explicit workflow: call with confirm=False to preview, show blast_radius to the user, wait for their decision, and only then set confirm=True. It also explicitly warns not to confirm autonomously because the user has not yet seen the blast radius, which is exactly the kind of when-not-to-use guidance an agent needs.

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