A comprehensive MCP server for VMware vCenter and ESXi management with support for VM operations, host operations, snapshot management, resource allocation, and AI-powered analysis
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
The VMware MCP server defines 25 tools with explicit schemas and descriptions visible in src/mcp_server.py. Strengths: all tools have descriptions (50-60 chars each), all parameters are typed with descriptions, and the server implements RBAC with role-based authorization across all operations. Weaknesses: (1) descriptions are minimal and lack context on WHEN to use each tool or what downstream effects occur, e.g., 'Start a virtual machine' does not explain prerequisites, time to completion, or whether agents should wait for the VM to be fully online; (2) no output schemas are documented, the code calls register_tool() but never shows what get_vm_details() returns or how list_vms() structures results; (3) error handling and recovery guidance are absent, no indication of retryable vs. fatal errors or what to do if a VM is already running when start_vm is called; (4) composition is poor, the server exposes low-level operations (enter_maintenance_mode, exit_maintenance_mode, migrate_vm) that agents may chain incorrectly; (5) parameter names like 'user_role' are duplicated across all 25 tools as a pass-through, suggesting weak RBAC integration (roles should be authenticated server-side, not passed by agents); (6) two AI tools (analyze_vm_performance, suggest_vm_sizing) mention Ollama integration but lack schema details on what those AI responses contain. Average tool definition score is ~58 across the 25 tools.
No output schemas documented. Code calls register_tool() but never declares what get_vm_details(), list_vms(), or other tools return. LLMs cannot plan downstream tool calls or extract fields without knowing response structure.
Descriptions are minimal (35-50 chars). They state WHAT the tool does but lack WHEN to use it, prerequisites, or side effects. E.g., 'Start a virtual machine' does not explain whether the tool waits for boot completion, whether the VM must be powered off first, or what happens if it is already running.
Document output schemas for all tools. For list_vms, document: {vms: [{vm_id, vm_name, power_state, cpu_count, memory_mb, host_name}], total_count, has_more}. Include field types, required/optional, and meanings.
Expand descriptions from 50 chars to 100-150 chars. For start_vm: 'Start a powered-off virtual machine. Waits for VMware Tools to report boot completion (~30 sec typical). Returns error if VM is already powered on. Use this before operations requiring the guest OS (e.g., adding NIC).'
Remove user_role from tool parameters. Implement server-side authentication: extract the calling user's identity and roles from the request context (e.g., MCP session metadata or JWT bearer token), then validate permissions server-side before executing. Log all role-based decisions for audit.
Add confirmation_required field to destructive tools (delete_vm, delete_all_snapshots). Example schema: {name: 'delete_vm', inputSchema: {properties: {vm_name: {...}, require_confirmation: {type: 'boolean', description: 'If true, first call returns confirmation token; second call with token actually deletes.', default: true}}}. Return {status: 'confirmation_required', token: 'xyz'} on first call.
user_role parameter passed by agents on every tool call (25 tools). This suggests RBAC is not server-side authenticated. Agents should never pass role parameters, roles must be derived from the authenticated caller's identity server-side. Exposing role as a parameter violates the permission-gate pattern.
No error handling guidance. Tools like delete_vm, delete_snapshot, delete_all_snapshots, and reboot_host are destructive but lack any dry-run, confirmation-request, or recovery guidance. Agents have no way to understand whether they should retry or ask the user.
Two AI tools (analyze_vm_performance, suggest_vm_sizing) reference Ollama integration but expose no schema for AI responses. What fields does analyze_vm_performance return? Is it free text, structured JSON, or a confidence score? Without schema, LLMs cannot reason about the output or chain calls.
Tools that accept optional parameters (e.g., datastore_name in clone_vm, target_host and target_datastore in migrate_vm) lack guidance on what happens when omitted. Does the system choose defaults? Does it fail? Without this, agents must guess or make trial calls.
No pagination declared for list tools (list_vms, list_hosts, list_snapshots, get_cluster_resources, get_datastore_usage). If a cluster has 10,000 VMs, what does list_vms return? All of them (blowing context)? The first 20? If limited, how does an agent get the rest? Pagination parameters and limits must be explicit.
Composition weakness: low-level host operations (enter_maintenance_mode, exit_maintenance_mode, reboot_host, migrate_vm) are exposed separately, but no higher-level tools wrap common sequences (e.g., drain_host_for_maintenance could atomically enter maintenance, migrate all VMs, and confirm readiness). Agents may chain these incorrectly, leaving hosts in inconsistent states.
Add explicit pagination to list_vms, list_hosts, list_snapshots. Add parameters: limit (1-100, default 20) and offset (default 0). Return {items: [...], total_count: number, offset: number, limit: number, has_more: boolean}. Document in description: 'Returns up to 20 VMs; call again with offset=20 to fetch the next page.'
For clone_vm and migrate_vm, clarify optional parameters. Example: 'datastore_name: Target datastore. If omitted, system selects the datastore with most free space. Returns error if no datastore has sufficient space.'
Create a higher-level drain_host tool that atomically: (1) enters maintenance mode, (2) migrates all powered-on VMs to other hosts, (3) confirms all migrations succeeded. This prevents agents from leaving VMs stranded.
Add error recovery hints to tool descriptions. For start_vm: 'If this fails with "VM already powered on", the VM is running; skip this call.' For delete_vm: 'Cannot delete a powered-on VM; call stop_vm first, or set force=true (not recommended in production).'
Implement structured error responses. Instead of generic failure, return {error: 'vm_already_running', message: 'VM is already powered on.', recovery: 'This is not an error; the VM is ready. Proceed with your task.'} so agents can distinguish transient errors (retry) from expected states (continue).