Skip to main content
Glama
vmware-skills

vmware-pilot

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

rollback

Destructive

Abort a failed workflow and undo completed steps in reverse order. Preview impact before applying to avoid unintended changes.

Instructions

[WRITE] Abort a workflow and rollback completed steps in reverse order.

Without confirm=True this only previews: it returns blast_radius — the workflow's id, type and state, the executed steps whose rollback_tool would run with its rollback_params, secrets redacted (would_roll_back — these often carry confirm=True, and this call's confirm=True is the decision to run them), the executed steps that have none and stay applied (left_in_place), steps you performed from pending_dispatch that Pilot will not reverse (not_reversed_by_pilot), steps with unknown effects, and 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 for a rollback earlier — the user has not seen the preview yet.

Nothing rolls back automatically: a failed step leaves the workflow 'failed' and stops. This tool is the explicit, best-effort undo, and it only reverses steps pilot itself recorded as 'success' — which, on this server (no dispatcher), are approval gates only. Steps YOU performed from pending_dispatch are still 'not_executed' here, so to undo them call each one's rollback_tool with its rollback_params yourself, last step first. Embedders that pass a dispatcher to WorkflowExecutor get those calls made for them. Steps without a rollback_tool are skipped; a failed undo does not stop the rest. The workflow state is set to 'failed' afterwards.

Refused with confirm=True: a workflow in draft, completed, rolling_back or cancelled state, a step whose status Pilot does not recognise, a workflow record that cannot be read, and — unless acknowledge_unknown_effects=True — a step left 'running' or 'interrupted' by a Pilot process that stopped mid-dispatch (listed in unknown_effects).

Returns: Preview: {"action": "preview", "blast_radius", "hint"}. Acting: the workflow state with "action": "rolled_back", rollback_results for each step pilot recorded as succeeded, and blast_radius. Check get_workflow_status afterwards to see which steps were actually reversed and which were skipped.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
confirmNoFalse (default) returns the blast radius and changes nothing. True applies it.
workflow_idYesThe workflow ID to rollback.
acknowledge_unknown_effectsNoSet True only after the user has checked, in the target system, whether each unknown_effects step took effect. Covers only those steps; every other refusal still applies.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.12.0
    • addedInput schema / properties / acknowledge_unknown_effects
      Added value: +{
+  "default": false,
+  "description": "Set True only after the user has checked, in the target system, whether each unknown_effects step took effect. Covers only those steps; every other refusal still applies.",
+  "title": "Acknowledge Unknown Effects",
+  "type": "boolean"
+}
    • addedInput schema / properties / confirm
      Added value: +{
+  "default": false,
+  "description": "False (default) returns the blast radius and changes nothing. True applies it.",
+  "title": "Confirm",
+  "type": "boolean"
+}
  2. Changed2 schema fields changedv1.11.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / workflow_id / description
      Added value: +"The workflow ID to rollback."
  3. First observedv1.5.22

TDQS

A5/5.0
Behavior5/5

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

It discloses critical behavior beyond annotations: confirm changes effect, nothing rolls back automatically, only 'success' steps are undone, failed undo doesn't stop the rest, state is set to 'failed', refusal conditions, and redaction of secrets. This is exactly the contextual depth an agent needs for a destructive, non-idempotent operation.

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 long but tightly organized: primary action, preview behavior, execution semantics, refusals, return shape. Each paragraph adds distinct operational guidance and the opening sentence front-loads the purpose.

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, it fully covers return shapes, error/refusal cases, side effects on workflow state, and follow-up verification via get_workflow_status. No critical operational gap remains.

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?

Though schema coverage is 100%, the description adds substantial meaning: confirm=False is a preview, confirm=True applies rollback and is the actual decision to run rollback_tool calls, and acknowledge_unknown_effects only covers listed unknown steps. This goes well beyond the schema's terse field descriptions.

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 first sentence names a specific verb and resource ('Abort a workflow and rollback completed steps in reverse order') and the rest clarifies that it is a best-effort undo for Pilot-recorded successes, which sets it apart from sibling cancellation and workflow-status tools. An agent can identify what action this performs without inspecting the schema.

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 usage rules: preview first with confirm=False, show the user, require explicit decision, and never self-confirm just because the user asked earlier. It also specifies alternatives for steps the tool will not reverse (call each rollback_tool with rollback_params yourself) and notes the dispatcher variant.

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