Skip to main content
Glama
vmware-skills

vmware-pilot

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

plan_workflow

Create an execution plan for multi-step VMware workflows, adding approval gates and audit logging for safe automation. Ideal for clone-and-test, incident response, and compliance scans.

Instructions

[WRITE] Create an execution plan for a multi-step workflow.

Use this when the goal matches one of the built-in types below; use create_workflow instead when none of them fit. A custom YAML template whose destructive or unclassifiable step (or step passing confirm=True) has no require_approval gate before it is refused, naming the step and the file to fix.

Available workflow types:

  • clone_and_test: Clone VM → apply changes → monitor → approve → commit

  • incident_response: Diagnose alert → collect info → approve → remediate

  • plan_and_approve: Wrap aiops batch operations with approval gate

  • compliance_scan: Read-only health/capacity/anomaly check (no approval)

Returns: dict with workflow_id, steps summary, and plan details.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
paramsYesWorkflow-specific parameters.
workflow_typeYesOne of the available workflow types.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.11.1
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / params / description
      Added value: +"Workflow-specific parameters."
    • addedInput schema / properties / workflow_type / description
      Added value: +"One of the available workflow types."
  2. First observedv1.5.22

TDQS

A4.5/5.0
Behavior4/5

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

Beyond annotations, the description discloses a specific refusal behavior: custom YAML templates with a destructive/unclassifiable step or confirm=True without require_approval are refused with a message naming the step and file. It also distinguishes read-only compliance_scan from approval-required flows. Annotations are not contradicted.

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?

Front-loaded with the operation and usage guidance; the workflow-type list is compact and the refusal/return notes are each relevant. It is slightly dense but not bloated.

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?

The description covers purpose, when-to-use, alternatives, all built-in types, refusal behavior, and return value. The only minor gap is per-type parameter shape, but given params is an open object this is not fatal.

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?

The schema gives only 'One of the available workflow types' for workflow_type; the description supplies the actual enum values and summarizes each. For params, it stays generic, but with additionalProperties allowed and 100% schema coverage, this is acceptable.

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 states a clear action on a distinct resource: 'Create an execution plan for a multi-step workflow.' It also names the exact sibling alternative (create_workflow) in the same sentence, allowing an agent to distinguish it immediately.

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 says when to use ('when the goal matches one of the built-in types below') and when to use a different tool ('use create_workflow instead when none of them fit'). It also provides the list of built-in types and their purpose, plus a refusal condition for unsafe custom templates.

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