Skip to main content
Glama
Sign In
vmware-pilot

vmware-pilot

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

run_workflow

Advance a planned VMware workflow, pause at approval gates, and return state plus pending steps for the calling agent to execute.

Instructions

[WRITE] Advance a planned workflow. Pauses at approval gates.

Who runs the steps depends on how this server was started:

  • with --dispatch (or VMWARE_PILOT_DISPATCH=stdio): Pilot runs each step itself in that skill's own MCP server, stops at each approval gate, and the workflow can reach 'completed'. This call takes as long as the steps it runs. If it times out in your client, Pilot carries on (and answers nothing else until the step ends); afterwards get_workflow_status shows the outcome. NEVER perform the steps yourself.

  • without it (the default): Pilot runs nothing. Steps are recorded as 'not_executed' and the run ends with outcome='dispatch_required' (NOT 'completed'), listing each step in 'pending_dispatch'. YOU (the calling agent) must perform those skill/tool calls in order. The result says which: a 'pending_dispatch' list means you run them.

Safety: the workflow is structurally reviewed before each run. Runs are REFUSED if review finds ungated destructive or unclassifiable steps, or destructive steps inside a parallel group. For a built-in template, force=True overrides that (forced runs are written to the workflow audit log). For a custom workflow (create_workflow, design_workflow, or a YAML template) an ungated step is refused even with force=True: add a require_approval step before it instead.

When an approval gate is reached, the workflow pauses with state 'awaiting_approval'. Call approve() to continue.

Returns: Current workflow state with 'outcome' (completed | awaiting_approval | dispatch_required | failed) and, when dispatch is required, a 'pending_dispatch' list of steps for the agent to perform.

Input Schema

NameRequiredDescriptionDefault
forceNoBypass blocking review findings on a built-in template. Use only with explicit human consent; the bypass is audited. Has no effect on a custom workflow's missing approval gate.
workflow_idYesThe workflow ID from create_workflow_from_template.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv2.3.0
    • changedInput schema / properties / workflow_id / description
      Previous value: -"The workflow ID from plan_workflow."New value: +"The workflow ID from create_workflow_from_template."
  2. Changed3 schema fields changedv1.11.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / force / description
      Added value: +"Bypass blocking review findings on a built-in template. Use only with explicit human consent; the bypass is audited. Has no effect on a custom workflow's missing approval gate."
    • addedInput schema / properties / workflow_id / description
      Added value: +"The workflow ID from plan_workflow."
  3. Changed1 schema field changedv1.5.38
    • addedInput schema / properties / force
      Added value: +{
+  "default": false,
+  "title": "Force",
+  "type": "boolean"
+}
  4. First observedv1.5.22

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the safety profile (not read-only, not idempotent, not destructive, open-world); the description goes far beyond by disclosing refusal conditions, the structural review gate, audit logging of forced runs, the distinction between dispatch_required and completed, and the 'NEVER perform the steps yourself' constraint. This is exactly the kind of context annotations cannot carry.

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 [WRITE] tag and lead sentence front-load the operation, and the dispatch branches and safety rules are clearly delineated. It is long, but nearly every sentence carries decision-relevant information; the Returns section is slightly redundant given the outcome values are already stated.

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, stateful tool with no output schema and only two parameters, the description supplies the missing return semantics ('outcome' values and 'pending_dispatch'), the caller obligations, and the failure/refusal model. An agent has everything needed to invoke and interpret this tool correctly.

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 coverage is 100%, so the baseline is 3, but the description adds real semantic depth to force: it overrides review findings only on built-in templates, requires human consent, is audited, and has no effect on a custom workflow's missing gate. It does not extend workflow_id beyond the schema, which is already documented.

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?

States a specific verb and resource ('[WRITE] Advance a planned workflow') plus a behavioral trait ('Pauses at approval gates'). It distinguishes itself from siblings by naming approve() for continuation and get_workflow_status for outcomes, so the agent can separate it from cancel/rollback/status tools without opening schemas.

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 covers the two dispatch modes, states what happens on timeout, when force=True is permitted (and when it is not), and when to call approve(). It effectively tells the agent whether it must perform steps itself or whether Pilot will, which is the key selection/usage question.

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