Loading ToolBench
A Model Context Protocol server for interacting with Proxmox hypervisors
The server defines 36 tools with substantial schema coverage but significant quality gaps. 20+ tools (55%) have complete input schemas with parameter descriptions, ranging from 2-10 parameters each. However, descriptions are inconsistent in depth and actionability. Many parameter descriptions lack specificity about ranges, formats, and constraints. Duplicate tools (get_nodes, get_node_status, get_vms, get_containers, get_storage, get_cluster_status appear twice) suggest incomplete refactoring between server_v2.py and server.py. Error handling guidance is absent from descriptions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) present despite many destructive/reversible operations. The tool definitions are visible in source (server_v2.py, server.py) but descriptions in the source code are not fully provided, limiting verification of description quality beyond what's in the rubric summary.
Create a backup of a VM or container.
Create a new LXC container.
Create a snapshot of a VM or container.
Create a new virtual machine on a specified node.
Delete one or more LXC containers.
Delete an ISO file from Proxmox storage.
Delete a snapshot of a VM or container.
Duplicate tool definitions: get_nodes, get_node_status, get_vms, get_containers, get_storage, and get_cluster_status are defined twice (once in server_v2.py, once in server.py). This violates the composition pattern (tool:avoid-multiple-tools-same-thing) and forces LLMs to decide which version to call, wasting reasoning cycles.
Missing tool annotations (readOnlyHint, destructiveHint, idempotentHint) on 36 tools. The schema includes risk classifications (READ_ONLY, WRITE, DESTRUCTIVE, REVERSIBLE) in the rubric summary but no evidence these are exposed as tool annotations in the MCP protocol. This prevents agents from understanding consequence severity without parsing descriptions.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Delete a virtual machine.
Download an ISO file to Proxmox storage.
Execute a shell command inside a virtual machine.
Get overall Proxmox cluster health and status.
Get overall Proxmox cluster health and status.
List all LXC containers across the cluster.
List all LXC containers across the cluster.
Get detailed status of a specific Proxmox node.
Get detailed status of a specific Proxmox node.
List all nodes in the Proxmox cluster.
List all nodes in the Proxmox cluster.
List storage pools across the cluster.
List storage pools across the cluster.
List all virtual machines across the cluster.
List all virtual machines across the cluster.
List all backups for VMs and containers.
List all ISO files available in storage.
List all snapshots for a VM or container.
List all container templates available in storage.
Reset a virtual machine.
Restart one or more LXC containers.
Restore a VM or container from a backup.
Rollback a VM or container to a previous snapshot.
Shut down a virtual machine gracefully.
Start one or more LXC containers.
Start a virtual machine.
Stop one or more LXC containers.
Stop a virtual machine immediately.
Update resource allocations for an LXC container.
Parameter descriptions lack constraint specifications. Examples: create_vm cpus has min=1, max=32 in schema but description does not state this range. Similarly, memory (512-131072 MB), disk_size (5-1000 GB), and timeout_seconds (1-600) have ranges in schema but descriptions don't call them out explicitly. LLMs cannot read JSON Schema constraints, they rely on description text.
No error handling guidance in tool descriptions. Destructive operations (delete_vm, delete_container, delete_iso, delete_snapshot) lack descriptions of what happens on failure (e.g., 'If VM is running and force=false, returns error. Set force=true to override.'). Recovery patterns are absent.
Generic descriptions on discovery tools. get_containers, get_storage, get_cluster_status lack context on when to call them relative to other tools. E.g., 'List all LXC containers across the cluster' does not explain the difference from list_containers or suggest 'call this first to enumerate available resources before filtering.'
No output schema documentation. Tool descriptions do not state what fields are returned. E.g., create_vm says 'Create a new virtual machine' but does not document that the response includes vmid, node, status, and other fields that downstream tools need. LLMs cannot chain tools without knowing the output shape.
Parameter selector for containers (start_container, stop_container, etc.) uses a complex, under-documented format: '123 | pve1:123 | pve1/name | name | comma list'. The description mentions this but does not clearly explain when to use each variant or how to handle ambiguity (e.g., if container name 'web' exists on multiple nodes, which does selector='web' target?). This invites malformed calls.
Nullable optional parameters not clearly documented. create_vm storage, ostype, network_bridge are nullable with defaults ('will auto-detect', 'default: l26', 'default: vmbr0'), but descriptions do not state what happens if omitted. Auto-detection behavior is implementation detail, LLMs need explicit defaults in descriptions.
No pagination guidance for list operations. get_containers, list_backups, list_snapshots, list_isos, list_templates, list_templates return potentially large result sets but descriptions do not mention limits, pagination, or offset/limit parameters. LLMs may request enormous result sets that blow context windows.
Ambiguous node/vmid parameter documentation. Tools like get_node_status expect node name ('pve', 'pve1', 'proxmox-node2') but the description lists examples without stating the exact format. Are node names DNS names, hostnames, or identifiers? Does 'pve1' match 'pve-1' or 'pve_1'? Ambiguity forces trial-and-error or extra lookup calls.