Loading ToolBench
MCP server for managing and monitoring Proxmox VMs and nodes using stdio transport
This server defines 15 tools for Proxmox VM and container management. All tools have descriptions (10-50 chars, below the 194-char baseline), names follow verb_noun convention, and input schemas are visible with typed parameters. However, descriptions are uniformly terse and lack context around when to use each tool, parameter constraints are minimal, output schemas are not documented, and error handling is absent from tool definitions. The server exposes dangerous operations (start_vm, stop_vm, execute_vm_command, create_vm_snapshot) without confirmation patterns or permission gates. No tool annotations (readOnlyHint/destructiveHint) are present. Tools are well-composed (single responsibility) and accept appropriate parameters (node, vmid), but lack the depth of documentation and safety guardrails expected in production infrastructure tooling.
Create a VM snapshot
Execute a command in a VM via QEMU guest agent
Get container status and configuration
Get all LXC containers across the cluster
Get detailed status for a specific node
Get all nodes in the cluster
Get VM status and configuration
All tool descriptions are under 20 characters (median ~25 chars vs. 194-char baseline). Descriptions lack context around when to use each tool, prerequisites, or return value hints. E.g., 'Start a VM' does not explain whether this returns immediately or waits for startup, what happens if the VM is already running, or which tools to call next (e.g., 'Get VM status after starting').
No output schemas documented. Tools return results from Proxmox API but LLMs have no visibility into response structure. E.g., get_nodes returns 'nodes' array and 'count' field (visible in code), but this is not formally declared. Output schema documentation is required for downstream tool chaining and LLM reasoning about what data is available next.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Get all VMs across the cluster
List VM snapshots
Reboot a container
Reboot a VM
Start a container
Start a VM
Stop a container
Stop a VM
Destructive operations (start_vm, stop_vm, reboot_vm, execute_vm_command, create_vm_snapshot, and container equivalents) lack confirmation patterns. No dry-run option or two-step confirmation. An agent could stop a production VM without user consent. Pattern:confirmation-request and tool annotations (destructiveHint) are absent.
No permission gates or scope declarations. Tools do not declare what permissions they require (e.g., 'write:vm', 'read:node'). No code visible that checks whether the calling agent/user is authorized to execute these operations. Infrastructure operations demand audit trails and least-privilege enforcement.
No tool annotations. Tools like start_vm, execute_vm_command are marked with Risk: WRITE in the metadata but do not use MCP tool annotations (destructiveHint/idempotentHint). This prevents clients from surfacing warnings to users or enforcing safety policies at the transport layer.
Parameter 'command' in execute_vm_command has no constraints. It accepts arbitrary strings and executes them on the VM. No description of injection risks, shell escaping, or safe patterns. This is a command injection vulnerability waiting to happen if an LLM is tricked into passing malicious input.
No error handling guidance in tool definitions. If a VM is not found, already running, or unreachable, no recovery instructions are provided. LLMs have no way to know whether to retry, ask the user, or suggest alternatives.
Parameter descriptions are minimal (10-30 chars). E.g., 'The node name' does not explain how to discover valid node names, what format is expected (hostname, IP), or what happens if the node is offline. Descriptions should answer WHAT, WHEN, and HOW.
No pagination or result limits for list-like tools (get_nodes, get_vms, get_containers, list_vm_snapshots). If a cluster has 1000 VMs, these tools will dump all of them, exhausting context windows. Tools should accept limit/offset/cursor parameters and return pagination info.
Proxmox credentials (PROXMOX_HOST, PROXMOX_TOKEN_ID, PROXMOX_TOKEN_SECRET) are loaded from environment variables in the server constructor, which is correct. However, no audit logging is visible in the tool definitions. Who called what, when, and with what parameters should be logged for compliance and incident response.