Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Capabilities

Features and capabilities supported by this server

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
plan_workflowA

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

run_workflowA

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

Steps run sequentially. 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.

Returns: Current workflow state, completed steps, and next action needed.

review_workflowA

[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

get_workflow_statusA

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

approveA

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

Returns: Updated workflow state after resuming execution.

rollbackA

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

list_workflowsA

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

create_workflowA

[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": {}}, ] )

get_skill_catalogA

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

design_workflowA

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

update_draftA

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

confirm_draftA

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

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/zw008/VMware-Pilot'

If you have feedback or need assistance with the MCP directory API, please join our Discord server