[WRITE] Create a custom workflow dynamically from a step list.

Use this when none of the built-in templates match. Describe what you need and the AI will design the steps using available skills.

Available skills and their key tools:

• aiops: vm_power_on, vm_power_off, deploy_linked_clone, vm_create_plan, vm_apply_plan, vm_rollback_plan, vm_guest_exec, batch_clone_vms

• monitor: get_alarms, get_events, list_virtual_machines, vm_info

• nsx: create_segment, delete_segment, create_tier1_gateway, list_segments

• nsx-security: create_dfw_rule, delete_dfw_rule, create_group

• aria: get_capacity_overview, list_anomalies, list_alerts, get_remaining_capacity

• vks: create_tkc_cluster, scale_tkc_cluster, delete_tkc_cluster

• storage: storage_iscsi_enable, storage_iscsi_add_target, vsan_health

Special step actions:

• require_approval: Pauses workflow for human confirmation

Each step dict must have: action, skill, tool, params. Optional: rollback_tool, rollback_params.

Args: name: Workflow name (used as workflow_type). description: Human-readable description. steps: List of step dicts, each with action/skill/tool/params. save_as_template: If True, save as YAML to ~/.vmware/workflows/ for reuse.

Returns: dict with workflow_id and plan summary. Call run_workflow to execute.

Example: create_workflow( name="network_segment_setup", description="Create segment with NAT and verify", steps=[ {"action": "create_segment", "skill": "nsx", "tool": "create_segment", "params": {"segment_id": "app-seg", "display_name": "App Segment", ...}}, {"action": "create_nat", "skill": "nsx", "tool": "create_nat_rule", "params": {"tier1_id": "app-t1", "rule_id": "snat-1", ...}}, {"action": "verify", "skill": "nsx", "tool": "list_segments", "params": {}}, ] )

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

1. AI calls design_workflow(goal="...") → returns draft with proposed steps

2. User reviews: "step 3 should use vm_power_off instead" or "add an approval before step 4"

3. AI calls update_draft(workflow_id, ...) to modify

4. User confirms: "looks good"

5. AI calls confirm_draft(workflow_id) → state changes to PENDING

6. AI calls run_workflow(workflow_id) → execute

The AI should use get_skill_catalog() first to understand available tools, then propose steps based on the user's goal.

Args: goal: Natural language description of what the user wants to accomplish. constraints: Optional constraints (e.g. "must have approval before any destructive step", "use NSX for networking", "target is vcenter-prod").

Returns: dict with workflow_id (state=DRAFT), proposed steps placeholder, and instructions for the AI to fill in steps via 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.

Each step dict: {action, skill, tool, params, rollback_tool?, rollback_params?} Use action="require_approval" for approval gates.

Args: workflow_id: The draft workflow ID. name: Workflow name (optional, updates workflow_type). description: Human-readable description. steps: Complete list of steps (replaces all existing steps).

Returns: Updated workflow summary for user review.

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

After confirmation, the workflow can be executed via run_workflow(). Optionally saves as a YAML template for future reuse.

Args: workflow_id: The draft workflow ID to confirm. save_as_template: If True, save to ~/.vmware/workflows/ for reuse.

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

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

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)

Args: workflow_type: One of the available workflow types. params: Workflow-specific parameters. clone_and_test: target_vm (str), change_spec (dict), monitor_minutes (int), target (str). incident_response: alert_entity (str), alert_name (str), target (str). plan_and_approve: operations (list[dict]), target (str), description (str). compliance_scan: target (str), check_alarms (bool), check_capacity (bool).

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

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

IMPORTANT — this MCP server has no dispatcher and cannot call other skills' MCP tools itself. Steps are recorded as 'not_executed' and the run finishes with outcome='dispatch_required' (NOT 'completed'), returning each pending step's skill/tool/params. YOU (the calling agent) must then perform those skill/tool calls in order. A workflow only reaches 'completed' when every step genuinely executed via a real dispatcher (embedders supplying one to WorkflowExecutor).

Safety: the workflow is structurally reviewed before each run. Runs are REFUSED if review finds ungated destructive steps or destructive steps inside a parallel group, unless force=True (forced runs are written to the workflow audit log).

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

Args: workflow_id: The workflow ID from plan_workflow. force: Bypass blocking review findings (ungated_destructive, destructive_in_parallel_group). Use only with explicit human consent; the bypass is audited.

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.

[WRITE] Approve a workflow that is waiting for human confirmation.

Only works when workflow state is 'awaiting_approval'. After approval, execution continues to the next steps.

Args: workflow_id: The workflow ID to approve. approver: Name of the person approving (for audit trail).

Note: this server has no dispatcher — after approval, remaining steps are recorded as 'not_executed' and the result carries outcome='dispatch_required' with a 'pending_dispatch' list for the calling agent to perform (see run_workflow).

Returns: Updated workflow state after resuming.

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

Works in any state except 'completed'. Irreversible steps are skipped. The workflow state is set to 'failed' after rollback.

Args: workflow_id: The workflow ID to rollback.

Returns: Rollback results for each step.

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

Cancel only stops FUTURE steps. It does NOT undo already-completed steps — use rollback() to reverse those. Cancel is valid only from a non-terminal state; cancelling an already completed/failed/cancelled workflow returns a teaching error. The cancellation is written to the workflow audit log.

Args: workflow_id: The workflow ID to cancel. reason: Optional human-readable reason (e.g. "approval rejected by on-call"), recorded in the audit log.

Returns: Updated workflow state (state='cancelled', outcome='cancelled'), or an error if the workflow is already terminal.

[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 vs. read-only steps

• Approval coverage: are all destructive ops gated behind a require_approval?

Args: workflow_id: The workflow ID returned by plan_workflow.

Returns: Dict with keys: - verdict: "approved" if no structural issues, otherwise "needs_revision" - findings: list of {severity, kind, message, step_index} - summary: counts (steps, gather/destructive/approval), groups, est_duration_min

[READ] Get current workflow state, diff report, and audit log.

Args: workflow_id: The workflow ID to query.

Returns: Full workflow state including steps, audit log, and diff report.

[READ] List all available workflow templates (built-in + custom).

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.

[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. Each skill lists its key tools with risk level and description.

Returns: dict mapping skill name → {description, tools: {tool_name: {risk, desc}}}.