Loading ToolBench
A Model Context Protocol server for interacting with Proxmox hypervisors, providing tools for node management, VM operations, storage management, and cluster status monitoring
This server has significant quality gaps despite reasonable tool coverage (13 tools across node, VM, storage, and cluster management). The core issues are: (1) tool descriptions are minimal (mostly 2-4 words like 'Get Nodes', 'Get VMs'), falling far below the 10-1024 char baseline and 194-char average for production tools; (2) parameter descriptions are present but often generic ('Name/ID of node to query') without explaining WHY the agent should call this tool or WHEN to use it instead of similar ones; (3) no visible output schema documentation, the server exposes Proxmox API responses but does not declare what fields agents should expect; (4) no tool annotations (readOnlyHint, destructiveHint) despite clear risk levels being tracked internally; (5) error handling strategy is invisible, no recovery guidance, no indication whether errors are retryable. The naming conventions ARE good (verb-noun: get_nodes, create_vm, delete_vm), and parameter schemas exist and have type constraints (e.g. cpus 1-32, memory 512-131072 MB), which saves this from a lower score. However, the descriptions fail the 'WHAT/WHEN/HOW' test needed for LLM tool selection, and the absence of output documentation and error guidance makes chaining unreliable.
Create VM
Delete VM
Execute VM Command
Get Cluster Status
Get Containers
Get Node Status
Get Nodes
Tool descriptions are critically short (2-4 words), far below the 10-1024 char baseline and 194-char production average. Examples: 'Get Nodes' (9 chars), 'Get VMs' (7 chars), 'Get Cluster Status' (18 chars). These do not answer WHAT the tool does, WHEN to use it, or what it returns. LLMs cannot differentiate between similar discovery tools.
No output schema documentation visible. The server does not declare what fields agents will receive from tools. For example, get_nodes likely returns a list of node objects, but the schema (node names? statuses? CPU counts? storage?) is undocumented. This forces LLMs to guess at response structure and breaks tool chaining (e.g. if get_vms returns vm_id but create_vm expects vmid, the mismatch is undetected).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Get Storage
Get VMs
Reset VM
Shutdown VM
Start VM
Stop VM
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) visible in the server code, despite internal Risk tracking (READ_ONLY, WRITE, DESTRUCTIVE). These annotations are part of the current 2026-07-28 MCP spec and help agents understand operation safety at a glance. All tools should declare their risk profile.
Error handling strategy is not visible in tool definitions. No indication of: (1) whether errors are retryable, (2) what an agent should do on failure, (3) recovery guidance. For destructive tools like delete_vm, there is no confirmation/dry-run pattern or rollback capability visible.
Parameter description quality is uneven. Many params have minimal guidance. Example: 'node' param in get_node_status has description 'Name/ID of node to query (e.g. pve1, proxmox-node2)', this explains WHAT but not WHEN to use this tool (should you call it before create_vm? After get_nodes?). Production baseline is 72 chars average; many here fall short of explaining dependencies and prerequisite calls.
Discovery tools (get_nodes, get_vms, get_containers, get_storage) lack pagination parameters (limit, offset, cursor) and do not document result caps. If a cluster has hundreds of nodes/VMs, the server may return all at once, bloating the context window. Production baseline requires pagination with limit and total count.
execute_vm_command accepts a free-form 'command' string parameter with no validation hints. This is a prompt-injection and command-injection risk. The description should state format constraints (e.g., 'no pipes or semicolons without escaping') or the server should validate/sanitize the command server-side to prevent agent-injected malicious payloads.
Parameter naming inconsistency: 'node' is used in many tools, but it is sometimes a 'Name/ID' (accept both forms) and sometimes not documented which format is expected. Similarly, 'vmid' is a string in some tools (e.g., create_vm) but the description does not clarify whether it is auto-assigned or user-provided. The rubric requires suffix typing: node_name vs node_id, or explicit docs on both being accepted.