This server has 15 tools with READ_ONLY operations, all explicitly registered in src/proxmox_mcp/server.py using the @server.tool() decorator from fastmcp. However, critical quality gaps significantly limit usability. Tool names follow verb_noun convention (list_, get_, proxmox-*), which is correct. Descriptions are present for all tools but are often terse (averaging ~80-120 chars) and lack context about when to use each tool vs. similar alternatives. Most critically, input schemas are incomplete: many tools declare parameters but fail to provide full JSON Schema with explicit type definitions visible in the source. For example, proxmox-list-vms has 'node', 'status', and 'search' parameters with descriptions, but the schema structure is not fully explicit in the provided code excerpt. Several tools like proxmox-list-all-clusters and proxmox-list-all-nodes-from-all-clusters have empty input schemas ({}), which is appropriate for their use cases. Output schemas are not documented in the visible source, we see descriptions of what tools return (e.g., 'Returns dict with cluster names as keys'), but no formal structured output schema. Error handling is minimal; no recovery guidance, no categorization of errors, and no examples of what happens on invalid input. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) are present, even though all 15 are marked risk=READ_ONLY in the spec. The codebase is large and includes enterprise features (Security, Infrastructure, Network, Monitoring, AI Optimization, Integrations), but only basic listing and status-checking tools are exposed; the advanced capabilities are imported but not verified as registered or properly described. Baseline comparison: production tools average 194 chars for descriptions and 72 chars for param annotations, this server's descriptions are roughly 40% shorter, and parameter annotations are sparse.
Get comprehensive status of ALL configured clusters. Returns detailed information including: - Cluster connectivity - Node status - Resource counts (VMs, containers, storage) - Health metrics Returns: Dict with cluster names as keys and status info as values
List all configured Proxmox clusters. Returns empty list in single-cluster mode.
List ALL nodes from ALL configured clusters. This is a convenience tool that aggregates nodes from all clusters. In single-cluster mode, returns nodes from the single cluster. Returns: Dict with cluster names as keys and node lists as values
List ALL VMs from ALL configured clusters. This is a convenience tool that aggregates VMs from all clusters. In single-cluster mode, returns VMs from the single cluster. Returns: Dict with cluster names as keys and VM lists as values
List network bridges on a node
Output schemas are not documented. Tools describe what they return in natural language (e.g., 'Dict with cluster names as keys') but do not provide formal JSON Schema definitions for their return types. LLMs cannot plan downstream tool calls without knowing the structure of returned data.
Descriptions are sparse and generic. Most tool descriptions are 50 - 70 characters, well below the production baseline of 194 chars. Descriptions lack context about when to use each tool vs. similar ones (e.g., when to use proxmox-list-vms vs. proxmox-vm-info, or which aggregation tools to prefer in multi-cluster mode). Generic descriptions like 'Get status of a Proxmox node' do not explain prerequisites, return values, or common use patterns.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 21 | - | v1 |
List LXC containers in Proxmox cluster
List nodes in Proxmox cluster
List storage devices in Proxmox cluster
List tasks/operations on nodes
List virtual machines in Proxmox cluster
Get detailed information about an LXC container
Get status of a Proxmox node
List content in a storage device
Get status of a specific task
Get detailed information about a virtual machine
Parameter descriptions are missing or minimal. Several tools (e.g., proxmox-node-status, proxmox-list-vms, proxmox-storage-content) declare parameters but descriptions are terse (e.g., 'Optional node filter' for proxmox-list-vms.node). Production baseline is 72 chars for param annotations. These lack guidance on format, constraints, and relationships (e.g., is node a name or ID? What formats does search accept? Are any parameters mutually exclusive?).
No tool annotations despite all tools being READ_ONLY. The rubric requires tool annotations (readOnlyHint, destructiveHint, idempotentHint) for clarity. All 15 tools are marked risk=READ_ONLY in the provided spec, but no evidence of annotation metadata in the source code visible.
No pagination support visible for list tools. Tools like proxmox-list-vms, proxmox-list-lxc, and proxmox-list-tasks may return many results but lack limit, offset, or cursor parameters. Production pattern requires pagination to prevent context window exhaustion when results are large.
No error handling guidance. The source code does not show error recovery patterns (e.g., retry logic, user-fixable vs. retryable error classification, actionable error messages). If a tool fails (e.g., node not found, permission denied), LLMs receive no guidance on what to do next.
Large dependency footprint with unclear linkage. pyproject.toml lists 60+ dependencies (security, infrastructure, monitoring, AI/ML, database, Kubernetes, Docker, LDAP, GPU, etc.), but the visible tool definitions only expose 15 basic read-only tools. Many imported modules (SecurityManager, InfrastructureManager, NetworkManager, etc.) are never verified as registered or their schemas validated. This creates maintenance risk and potential for tools to exist but be undocumented.