Skip to content
Agentmart
Submit a tool

VMware Pilot

Multi-step workflow orchestration for VMware MCP skills with approval gates and rollback.

Connector by vmware-skills · GitHub account verified by the MCP Registry

IndexedMITLocal (stdio)★ 4
Write a review

Install

Works with Claude Code, Codex, VS Code, Cursor, Windsurf, Claude Desktop. Read the repository before you give any tool access to your data.

npx agentmarket install connector/vmware-skills-vmware-pilot

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

Multi-step workflow orchestration for VMware MCP skills with approval gates and rollback.

Use cases: workflow-automation, cloud-management

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this server can do and what it asks for, from its tool list, install config and code. Checked Oct 25, 2026.

Tools
4 read · 7 write · 2 delete
Secrets
None asked for
Install scripts
None found
Runs as
Python package

Tools by what they do 13

Read from the source code; the running server may list different tools.

Read 4 · Look things up without changing anything.

  • get_skill_catalog
  • get_workflow_status
  • list_workflows
  • review_workflow

Write 7 · Create, change, send or run things.

  • approve
  • confirm_draft
  • create_workflow
  • create_workflow_from_template
  • design_workflow
  • run_workflow
  • update_draft

Delete 2 · Delete, drop, revoke or wipe things.

  • cancel_workflow
  • rollback

Network hosts it talks to 2

  • anthropic.com · found in code
  • github.com · found in code

Files it touches

  • Your home directory (~)
  • ~/.vmware/workflows
  • ~/.vmware/workflows.db
  • ~/.vmware/workflows/restart_db_cluster.yaml

Tools (13)

Read from the source code; the running server may differ. Descriptions are the server’s own words; hidden characters are shown as [U+…].

  • approve

    [WRITE] Approve a workflow that is waiting for human confirmation. Use this only after showing the user the pending step and getting explicit human consent; use cancel_workflow instead when the approval is rejected. Only works when workflow state is 'awaiting_approval'. After approval, execution continues to the next steps. Without --dispatch, the steps before the gate are 'not_executed': Pilot has no record that they ran, whatever the gate's message says. approve refuses (listing them in not_executed_before_gate) until acknowledge_not_executed=True — set it only after you performed each of …

  • cancel_workflowcan change or delete data

    [WRITE] Cancel a workflow — move it to the terminal CANCELLED state. Use this when an approval is REJECTED, a review flags the plan as unsafe, or an operator decides the workflow must never run. A cancelled workflow is dead: run_workflow and approve refuse to execute it. Without this, an approval-rejected PENDING workflow could still be picked up and run. Without confirm=True this only previews: it returns blast_radius — the workflow's id, type and state, the executed steps that stay applied (left_in_place: cancelling part-way leaves a half-applied change), steps performed outside Pilot (per…

  • confirm_draft

    [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. Args: workflow_id: The draft workflow ID to confirm. save_as_template: If True, save to ~/.vmware/work…

  • create_workflow

    [WRITE] Create a custom workflow dynamically from a step list. Use this when you already know the steps and no built-in template matches; prefer create_workflow_from_template when one does, and design_workflow when the user gave a goal rather than steps. Call get_skill_catalog first for the skill and tool names a step may target. Each step dict must have: action, skill, tool, params. Optional: rollback_tool, rollback_params. action="require_approval" (skill "pilot", tool "approve") inserts a human approval gate. A workflow whose destructive or unclassifiable step, or a step passing confirm=T…

  • create_workflow_from_template

    [WRITE] Create and save a workflow from a template, ready for run_workflow. Takes a template name (workflow_type) plus its params, builds the steps the template defines, and persists the workflow in state "pending" — it is not a dry run. Templates are the built-in types below plus custom YAML templates (list_workflows shows both). Use this when the goal matches a template; use create_workflow instead to save your own step list 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,…

  • design_workflow

    [WRITE] Start designing a workflow from a natural language description. Call this when the user describes a complex operation and you need to design a multi-step workflow. Returns a DRAFT workflow with proposed steps for the user to review and edit before execution. Design flow: design_workflow → update_draft (add steps, then iterate on user feedback) → confirm_draft (state becomes PENDING) → run_workflow. Use get_skill_catalog() first to see which tools the steps may target. Args: goal: Natural language description of what the user wants to accomplish. constraints: Optional constr…

  • get_skill_catalogread-only

    [READ] Get the complete catalog of available skills and tools for workflow design. Use this to understand what building blocks are available when designing a custom workflow, then feed the skill and tool names into create_workflow or update_draft steps. Note this is a static curated catalog, not a live query of each skill's registry, so it may lag a skill's actual tool list; pilot cannot call these tools itself — the calling agent does. Returns: dict mapping skill name → {description, tools: {tool_name: {risk, desc}}}.

  • get_workflow_statusread-only

    [READ] Get current workflow state, diff report, and audit log. Use this to poll a workflow after run_workflow and to find out why one stopped: steps with status 'not_executed' are yours to perform (the server runs without --dispatch), state 'awaiting_approval' means call approve. Returns a point-in-time snapshot and does not advance the workflow. Args: workflow_id: The workflow ID to query. Returns: Full workflow state including steps, audit log, and diff report.

  • list_workflowsread-only

    [READ] List all available workflow templates (built-in + custom). Use this first to see whether a template already covers the goal, then pass its name to create_workflow_from_template; if none fit, use create_workflow instead. Built-in templates are always available. Custom templates are loaded from ~/.vmware/workflows/*.yaml — drop a YAML file there to add your own workflows. Returns: dict with builtin and custom workflow lists, each with name, description, steps count, plus active_workflows — the IDs of in-flight runs to pass to get_workflow_status.

  • review_workflowread-only

    [READ] Sanity-check a planned workflow before execution. Performs structural validation only — does NOT call into other skills. Catches the common authoring errors before they hit production: - Delete-then-use: a step deletes resource X, a later step references X - Missing required params: a step has empty params or placeholder values - Cross-skill order issues: surfacing the cross-skill dispatch sequence - Risk profile: count of destructive / write / read-only / unclassified steps - Approval coverage: is every destructive OR unclassifiable step gated behind a preceding require…

  • rollbackcan change or delete data

    [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: they have an undo you must call; not_reversible_outside_pilot…

  • run_workflow

    [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…

  • update_draft

    [WRITE] Update a DRAFT workflow's name, description, or steps. Call this after design_workflow() to fill in the actual steps, or to modify steps based on user feedback. Use it only while the workflow is still DRAFT — after confirm_draft the steps are frozen and you must create_workflow a new one instead. Each step dict: {action, skill, tool, params, rollback_tool?, rollback_params?} Use action="require_approval" for approval gates. A draft may be saved without them while it is being designed; the result lists every step that still needs one, and confirm_draft refuses until none are left. Ar…

Signals

Stars
4
Forks
0
Open issues
0
Weekly downloads
420
Last commit
Oct 24, 2026 (5 days ago)
Last release
Oct 18, 2026 (10 days ago)
Last package publish
Oct 18, 2026 (10 days ago)

From GitHub (fetched Oct 24, 2026) and the package registry.

Details

Registry name
io.github.vmware-skills/vmware-pilot
Version
2.4.0
Auth
No auth
Packages
pypi vmware-pilot
License
MIT
First seen
Oct 24, 2026
Last checked
Oct 24, 2026

More from vmware-skills

Cite this page

VMware Pilot MCP server. Agent Mart. https://agentmart.dev/connectors/vmware-skills-vmware-pilot (last updated 2026-10-24)