Skip to main content
Glama
vmware-skills

vmware-pilot

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

confirm_draft

Approve a draft workflow to set it to PENDING for execution, and optionally save it as a reusable YAML template. Confirms after review, enabling subsequent run_workflow() execution.

Instructions

[WRITE] Confirm a draft workflow — changes state from DRAFT to PENDING.

Use this once the user has approved the draft's steps; call update_draft instead if anything still needs changing. After confirmation, the workflow can be executed via run_workflow(). Optionally saves as a YAML template for future reuse. Refused — the draft stays a draft and nothing is saved — while any destructive or unclassifiable step, or any step passing confirm=True, lacks a require_approval gate before it.

Returns: Confirmed workflow summary. Call run_workflow() to execute.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
workflow_idYesThe draft workflow ID to confirm.
save_as_templateNoIf True, save to ~/.vmware/workflows/ for reuse. Refused when the draft's name is a built-in template's name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.11.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / save_as_template / description
      Added value: +"If True, save to ~/.vmware/workflows/ for reuse. Refused when the draft's name is a built-in template's name."
    • addedInput schema / properties / workflow_id / description
      Added value: +"The draft workflow ID to confirm."
  2. First observedv1.5.22

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, it discloses the DRAFT-to-PENDING state change, optional template persistence, and important refusal conditions for destructive or unclassifiable steps lacking require_approval gates. It also states that nothing is saved when confirmation is refused, which is genuinely useful behavioral context.

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 compact and front-loaded, covering action, usage, alternatives, refusal, and return value in a short space. It loses a point for the awkwardly worded 'Refused — ... while ...' sentence, which is grammatically tangled but still decipherable.

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 write operation with no output schema, it explains the return value ('Confirmed workflow summary'), the required next step, the alternative tool, and the failure/refusal semantics. The remaining details, such as built-in template conflict behavior, are covered by the schema.

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 schema already documents workflow_id and save_as_template well. The description adds small extra meaning by mentioning that the template is YAML and placing the save within the confirmation flow, which is slightly beyond 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: 'Confirm a draft workflow — changes state from DRAFT to PENDING.' This clearly names the action, the object, and the state transition, and it is immediately distinguishable from siblings like update_draft and run_workflow.

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 explicitly states the trigger condition ('once the user has approved the draft's steps'), the alternative ('call update_draft instead if anything still needs changing'), and the next step ('run_workflow()'). This gives the agent concrete routing 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