pve-mcp-server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Every tool targets a distinct resource and aspect, such as node status vs. node network vs. node PCI devices. Even similar-sounding tools like pve_get_node_disks and pve_get_node_pci are clearly separated by described hardware type.
Naming Consistency4/5All tools share the pve_ prefix and use lowercase with underscores, but two tools use 'list_' (pve_list_vms, pve_list_lxc) while the rest use 'get_', creating a minor inconsistency in verb choice.
Tool Count3/5With 25 tools, the server sits at the heavy end of the borderline range. The count is reasonable for a comprehensive read-only monitoring surface, but it feels ample and lacks any action-oriented tools to balance it.
Completeness1/5The toolset is entirely read-only, offering no ability to create, start, stop, delete, or modify virtual machines or containers. This leaves major management workflows completely unsupported, making it severely incomplete for a Proxmox VE server.
Average 3.6/5 across 25 of 25 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must convey behavioral traits. It only lists returned data and does not state whether the operation is read-only, any side effects, errors, or access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, immediately conveying the core resource. However, it is a sentence fragment rather than a complete sentence, which slightly reduces readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With a simple one-parameter tool and an output schema present, the description lists key return fields and serves as a minimal viable description. It lacks usage context, error handling, or notes on node validity, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only says 'on a node' without clarifying the expected format or meaning of the 'node' parameter. This leaves the parameter semantics underspecified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as TLS certificates on a node and lists specific fields (subject, issuer, fingerprint, expiry dates), making the scope unambiguous. It distinguishes from siblings because no other tool focuses on certificates, though it lacks an explicit verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it returns and does not mention prerequisites, exclusions, or alternative tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the data content (IOMMU groups, vendor, class) but says nothing about read-only behavior, permissions, error cases, or potential performance implications. This is a significant gap for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise phrase with no redundant words, earning its place. It is slightly under-specified as a sentence fragment but remains efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are covered elsewhere, but the description fails to explain the required input parameter. Given the low complexity, a simple mention of node would have made this more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention the 'node' parameter at all. The parameter name is self-explanatory, but the description adds no value in explaining accepted values, format, or semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the specific resource (PCI devices) and scope (node), and the passthrough context distinguishes it from sibling get_ tools. However, it lacks an explicit action verb like 'list' or 'get', making the purpose slightly less direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in PCI passthrough scenarios ('available for passthrough') but does not explicitly state when to use this tool versus alternatives or any exclusions. No sibling differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions 'historical metrics' and 'over time', implying time-series data and a read-only operation, but it does not explicitly state that there are no side effects, nor does it describe the response structure, aggregation, or any rate-limit or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded with the primary purpose and includes the key resource (node) and metric types. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description leaves important context unaddressed: usage guidance, parameter semantics, and behavioral nuances. For a tool with no annotations, this sparse description is incomplete for an agent to select and invoke it with confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. However, it does not explain the 'node' or 'timeframe' parameters at all, nor does it elaborate on the enum values (hour/day/week/month/year). The phrase 'over time' weakly hints at timeframe, but adds no concrete meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool returns: historical metrics for a node, including CPU, RAM, net, and disk over time. It distinguishes from sibling tools like pve_get_node_status (current status) and pve_get_vm_rrddata (VM-specific) by specifying 'node' and 'over time', though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is for historical time-series data as opposed to current status, nor does it reference sibling tools such as pve_get_node_status or pve_get_vm_rrddata.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure, but it does not explicitly state that this is a read-only operation, mention ordering or pagination of the task list, or describe any limits. It only indicates the content (history of certain operations), so most behavioral characteristics are undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's focus and uses examples to clarify what counts as a cluster task. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter) and an output schema exists, so the description does not need to explain return values. However, it lacks explicit read-only confirmation and usage guidance, making it only minimally complete for an agent selecting this tool without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'limit' parameter with 0% schema description coverage, and the description does not mention or explain this parameter. While the parameter name and default value make its purpose fairly obvious, the description adds no information beyond the schema and fails to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's scope as cluster task history and lists example operation types (migrations, backups, clones, snapshots), which distinguishes it from sibling tools focused on nodes, VMs, storage, etc. However, it uses a noun phrase rather than an explicit verb like 'list' or 'retrieve', so it is slightly less direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, nor any conditions or exclusions. The description only states what the history contains, leaving the agent to infer usage context from the tool name and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states what the tool returns and the scoping, but does not explicitly mention that it is a read-only operation, any required permissions, or what happens if the VM name is invalid. Given the lack of annotations, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that immediately states the resource and scoping. It is front-loaded with the purpose and contains no filler, making it an model of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and zero parameter documentation, the description is too thin to be fully complete. It fails to explain important behavioral aspects such as required permissions, return format (though an output schema exists), and parameter constraints. More context is necessary for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema parameter coverage is 0%, so the description must compensate. It explains that vm_name selects VM-level rules, but it does not describe the expected format of node or vm_name (e.g., name vs. ID), and node is not explained at all. The description offers minimal additional meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (firewall rules) and the two scopes (node or specific VM). Although the verb 'get' is not explicitly stated in the description, the tool name supplies it. The distinction from sibling tools is clear since none of the siblings deal with firewall rules.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool: pass vm_name for VM-level rules, otherwise it operates at node level. It does not mention alternatives, but there are no sibling tools for firewall rules, so the guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral expectations, but it only lists output fields. It does not explicitly state that this is a read-only query, what permissions are needed, or any error or rate-limit behavior. The 'get' action implies read-only but is not disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short, information-dense sentence that front-loads the resource ('all NICs and bridges') and enumerates key fields. There is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read tool with an output schema, the description captures the essential return content. However, it omits usage context and parameter semantics, leaving it slightly incomplete despite low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'node' parameter has zero schema description coverage, and the description only says 'on a node,' adding little beyond the schema's 'Node' title. It does not specify node name format, accepted values, or that the parameter is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving all NICs and bridges on a node, listing specific attributes such as IP, netmask, gateway, MAC, and bridge ports. This differentiates it from sibling tools focused on disks, PCI, services, and other node resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives or any prerequisites. The name and description imply it is for node network inspection, but no exclusions or alternative pointers are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the action and the data included, without mentioning read-only semantics, authentication requirements, error behavior, or side effects. The verb 'Get' weakly implies non-mutation, but that is not explicitly stated, and no other behavioral traits are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no extraneous words. It efficiently communicates the core purpose and the key items returned (storage pool, path, size), earning every word's place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter) and the presence of an output schema, return values need not be elaborated. However, the description lacks usage guidance, parameter semantics, and behavioral context, leaving an agent without enough information to confidently invoke the tool among the many similar pve_get_* siblings. It is a minimally adequate but notably incomplete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for the vm_name parameter (0% coverage), so the description must compensate. It only says 'for a specific VM', which connects the parameter to the tool's purpose but does not clarify whether vm_name is a name or ID, nor any format or constraints. The parameter semantics are therefore only minimally enriched beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the disk/storage layout for a specific VM, listing the storage pool, path, and size per disk. It distinguishes itself from sibling tools like pve_get_storage and pve_get_node_disks by explicitly scoping to a single VM and specifying the exact information returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for a specific VM' gives some context for when to use this tool, implying it is for per-VM disk queries rather than host-level storage. However, it does not explicitly mention when not to use it or suggest alternatives like pve_get_vm_config, which might also include disk information. This leaves some ambiguity in tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only lists metric categories and says 'over time' without explaining output format, timeframe handling, aggregation, or that it is a read-only operation. This is insufficient to predict behavior beyond a vague sense of returned data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence, front-loaded with the core purpose. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are likely specified there, but the description omits any guidance on the required/variable parameters. An agent cannot correctly choose a timeframe or know that vm_name is mandatory from the description alone. The description is too sparse to fully support tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%: neither vm_name nor timeframe is described in the description. The mention of 'over time' vaguely alludes to the timeframe concept but does not map to the parameter or explain its options/default. The description does not compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns historical performance metrics for a VM, listing specific metric types (CPU, RAM, net I/O, disk I/O) and emphasizing the time dimension. This differentiates it from sibling tools like pve_get_node_rrddata (node metrics) and pve_get_vm_status (current status).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need historical VM metrics) but does not explicitly state alternatives or conditions where other tools would be preferred. It gives clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description focuses solely on the content returned and gives no behavioral context. It does not disclose that the operation is read-only, what happens if the VM does not exist, or how the response is structured. Since no annotations are provided, the description carries the full burden and falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose ('Full VM config') followed by a concise list of fields. Every word adds value, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists the configuration fields, giving a useful overview of the response content. However, it omits details about output format, error behavior, and permissions, which are critical given the absence of an output schema and annotations. A slightly more detailed description would make it fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter vm_name has no schema description, and the tool description does not mention it either. The agent must rely solely on the parameter name, with no guidance on format, required syntax, or possible values. The description fails to compensate for the missing schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly lists the configuration fields returned (CPU type, BIOS, boot order, NIC list, disk config, tags, description), making it clear this tool retrieves the full VM configuration. This distinguishes it from sibling tools like pve_get_vm_disks and pve_get_vm_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Full VM config' provides clear context for when to use this tool—when the complete VM configuration is needed. However, it does not explicitly state when not to use it or mention alternative tools for more specific queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does add the word 'Live' and lists the exact fields returned, which gives some behavioral context. However, it does not state whether the VM must be running, how missing VMs are handled, or the exact return structure (object vs array), so transparency is partial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the main concept ('Live VM metrics') and enumerates fields with no filler. Every word contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter getter with no output schema, the description lists the expected fields but omits the return shape, error behavior, and relationship to sibling tools. It is adequate for a simple status read, but clear gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the vm_name parameter. The parameter name and title are self-explanatory, but the description adds no additional meaning (e.g., whether it expects a VMID or hostname), so it fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Live VM metrics: CPU%, RAM used/max, PID, uptime, QMP status, lock, tags' clearly defines the tool as a status/read-only getter for a VM. The specific field list sets it apart from sibling tools like pve_get_vm_config, pve_get_vm_disks, and pve_get_vm_rrddata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any when-to-use guidance, such as 'use this for current status; use pve_get_vm_rrddata for historical metrics'. It also does not mention any alternatives or exclusions, leaving the agent to infer usage solely from the tool name and sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It names the relevant services but does not state that the operation is read-only, whether the list includes only active/running services, what permissions are needed, or what form the output takes beyond the systemd service names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded phrase that immediately states the resource and gives concrete examples. There is no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with an output schema, the description is mostly adequate. However, it lacks explicit usage guidance and behavioral caveats such as read-only confirmation, making it not fully self-sufficient without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description provides the only context for the single 'node' parameter by saying services exist 'on a node'. This makes the parameter's purpose understandable, but it does not explain valid node formats or that node values likely come from pve_get_nodes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource ('systemd services') and the scope ('on a node') with concrete examples (pveproxy, pvedaemon, pve-ha-*, corosync). This clearly distinguishes it from sibling tools that target node status, network, disks, or VMs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is for listing node-level systemd services and clarifies the service set, but it does not explicitly state when to prefer this over related tools like pve_get_node_status or provide exclusion criteria. Usage is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the returned data fields (model, serial, size, etc.), which is useful, but it does not mention any behavioral aspects such as read-only nature, required permissions, or potential side effects. The lack of contradiction with annotations makes this a neutral score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that front-loads the core purpose and lists key attributes. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter, and an output schema exists, which covers return structure. The description is terse but adequately covers the essential context for a node disk listing tool, though it lacks any caveats about edge cases or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented 'node' parameter. The description only says 'on a node' without specifying the format (e.g., hostname, IP, or node ID) or any constraints. This is insufficient for an agent to confidently populate the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose as retrieving physical disk information from a node, listing specific attributes such as model, serial, size, type, S.M.A.R.T. health, and wear. This distinguishes it from sibling tools like pve_get_vm_disks, which targets VM disks, and pve_get_storage, which covers storage pools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to get physical disk details for a node, but it provides no explicit guidance on when to choose this over alternatives. There is no mention of exclusions or comparisons with sibling tools, leaving the usage context implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly implies a read-only retrieval operation by listing metrics, but it does not disclose potential permissions, performance considerations, or behavior under error conditions (e.g., if the node is offline). Some extra context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary purpose ('Detailed node metrics') and then lists the specific metrics without any filler or repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one parameter and no output schema, the description provides a good overview of the returned metrics, which effectively communicates the expected output shape. However, it lacks explicit guidance on parameter usage and error scenarios, making it slightly incomplete but still adequate for a straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'node' with no description (0% coverage). The tool description does not elaborate on what values to pass, leaving the parameter's semantics entirely to inference from its name. Given the low schema coverage, the description should have compensated but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: providing detailed node metrics. It enumerates specific metric categories (CPU%, RAM, swap, etc.), which makes it distinct from sibling tools like pve_get_node_network or pve_get_node_disks that focus on specific subsystems.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when overall node health metrics are needed, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or alternative recommendations. The usage context is only implied by the list of general metrics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. The verb 'List' implies a read-only operation, and the description specifies output fields. However, it does not disclose potential edge behaviors like filter defaults, invalid node handling, or authentication requirements, offering only minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with only 13 words, front-loaded with the action and resource. Every word is informative, and it avoids redundancy with the schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with two optional parameters, the description covers the core purpose and output fields. It lacks explicit mention of how status_filter behaves, but the schema's enum and default fill that gap. Given the presence of an output schema, the description is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It does not explicitly explain the 'node' parameter, though 'across all nodes' hints at its role, and it completely omits the 'status_filter' parameter. The schema's enum and defaults provide some clarity, but the description adds little beyond the structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with a clear resource 'LXC containers' and scope 'across all nodes', also enumerating returned fields. This distinguishes it from sibling pve_list_vms, which lists VMs, so the purpose is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing to list LXC containers, and sibling names suggest alternatives, but it does not explicitly state when to use this tool vs. alternatives or any exclusions. No direct comparison to pve_list_vms is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description introduces the key behavior of returning all cluster resources in a single call and suggests performance ('Fast'). It does not explicitly state that the operation is read-only or that results can be filtered by the 'type' parameter, which limits full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two brief, front-loaded sentences. Every word contributes: 'all cluster resources' defines scope, 'in one bulk call' conveys efficiency, and the resource list adds concreteness. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the presence of an output schema reduces the need to explain return values. However, the description omits the optional 'type' parameter that controls filtering, which would be useful for an agent deciding whether to use this bulk tool vs a specific resource tool. Overall it is acceptable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description lists resource types that loosely correspond to the enum values (vm, node, storage) but does not explain the 'type' parameter as a filter. It also introduces 'LXC' as a separate category when the schema treats LXC as a VM subtype, and omits 'sdn' entirely. The schema's enum lacks descriptions, so the description needed to compensate but does so incompletely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'All cluster resources in one bulk call' and enumerates the included resource types (VMs, nodes, storage, LXC). This distinguishes it from sibling tools like pve_get_nodes or pve_list_vms by emphasizing the aggregate, bulk nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one bulk call' and 'Fast overview' clearly imply when this tool should be used: when a broad, multi-resource snapshot is needed quickly, contrasting with the more specific sibling tools. However, it does not explicitly list alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It accurately states the action but adds no additional behavioral context such as whether it is read-only, requires specific permissions, or returns a summary or detailed listing. It is not misleading, but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence conveys the purpose and includes the key content types. Every word earns its place; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, an output schema exists, and the description covers the core action. It would be slightly more complete if it referenced the content_type filter or the default 'all', but the schema covers those details, so the description is sufficient for a straightforward listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds meaning to 'content_type' by listing examples (images, ISOs, backups, templates) that map to enum values. However, 'node' and 'storage' are not elaborated, and the default behavior of 'all' is not mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List content of a storage pool' and enumerates content types (VM images, ISOs, backups, templates), clearly distinguishing it from siblings like pve_get_storage which likely retrieves storage configuration rather than contents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage (when you need to list storage contents) but does not explicitly contrast with alternatives or state exclusions. No guidance on when not to use it or how it differs from pve_get_storage or pve_list_vms is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'List' implies a read-only operation, and the mention of capacity info adds some behavioral context. However, it does not explicitly state that the operation is non-mutating, nor does it disclose any potential caveats like pagination or permission requirements. The output schema exists, which partially covers return values, but other behavioral traits are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, concise sentence that front-loads the verb and resource, followed by the key output fields. No unnecessary words, and all information is directly relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with an output schema, the description is fully adequate. It tells the agent exactly what the tool returns and implies it lists all storage pools. The tool can be selected and invoked correctly based solely on this description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description correctly adds no parameter information, and no further semantic explanation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('List') and resource ('storage pools'), and specifies the output details (capacity info: type, total GB, free GB, used %). This distinguishes it from siblings like pve_get_storage_content, which focuses on storage contents rather than pool-level capacity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. For example, it does not clarify that this tool is for pool-level capacity while pve_get_storage_content is for listing items within a storage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral transparency. It discloses a dependency (guest agent must be installed) and the data returned, but does not describe what happens if the agent is absent, whether the operation is read-only, or any error behavior. This is minimally adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence: it names the tool's resource, lists the specific data fields, and states the agent requirement. Every element is essential, and there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one parameter and no output schema, the description covers the core purpose, returned data, and a critical dependency. It does not detail parameter usage or failure modes, but given the tool's simplicity and the obvious vm_name parameter, this is sufficient for contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single vm_name parameter, and the description does not explicitly explain the parameter. While the parameter is inferable from the tool name and description, the description adds no semantic value beyond the schema, failing to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving QEMU guest agent data including IP addresses, OS info, and hostname. This specific resource and data list distinguish it from sibling tools like pve_get_vm_status or pve_get_vm_config, which focus on other aspects of VM information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key usage condition: 'Requires agent installed inside VM,' which tells the user when this tool is applicable. It does not explicitly mention alternatives or exclusions, but the prerequisite effectively guides usage for a get-type tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosing behavior. It describes the tool as performing a diff between live and stored config, which implies read-only behavior, but it does not explicitly state safety, permissions, or potential side effects. This is a moderate level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core purpose without any fluff or repetition. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description is adequate to convey scope and purpose. The output schema presumably documents return values, so the description need not explain them. It could have briefly mentioned parameter usage, but overall it is complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter (vm_name) with 0% description coverage. The tool description does not mention the parameter or provide any additional semantic detail, so it fails to compensate for the lack of schema documentation. The parameter is only trivially inferable from the tool name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: it identifies the tool as retrieving config changes pending reboot for a VM, and clarifies that it returns a diff between live and stored config. This clearly distinguishes it from sibling tools like pve_get_vm_config or pve_get_vm_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for viewing unapplied config changes (pending reboot), which implies when to use it. However, it does not explicitly mention alternatives or when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation via 'status' and 'list', but does not explicitly state safety, permissions, or side effects. It adds minimal behavioral context beyond what the name suggests.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's function. Every word contributes meaning, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, read-only status tool, the description adequately communicates what the tool returns: HA cluster status and a list of HA-managed resources. It does not detail the format or fields, but given the straightforward nature, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is trivially complete. Per the rubric, 0 params receives a baseline of 4. The description adds no parameter information, but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'HA cluster status and list of HA-managed resources.' It uses a specific resource (HA cluster) and distinct outputs (status and resource list), distinguishing it from siblings like pve_get_cluster_resources which target general cluster resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you need HA cluster status or HA-managed resources) but provides no explicit guidance on when to use this tool over alternatives, nor any exclusions. There is no mention of situations where another tool (e.g., pve_get_cluster_resources) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of indicating safety. The verb 'List' implies a read-only operation, and the description discloses returned data fields. However, it does not mention authentication requirements, pagination, error behavior, or other behavioral details, though the output schema may cover some of this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that immediately states the action and scope. There is no redundant information or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list tool, the description is adequately complete, especially with an output schema present. It names the key output fields and scope. It could be slightly stronger by explicitly differentiating from sibling tools, but that is more of a guidelines concern.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the description does not need to explain parameter behavior. The baseline for zero-parameter tools is 4, and there are no gaps to penalize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('List all nodes') on a clear resource ('Proxmox cluster') and includes the expected output fields (status, memory, uptime). It is easily distinguished from sibling tools like pve_get_node_status, which targets a single node.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied: use this when you need a cluster-wide node overview with status and resource usage. However, no explicit guidance is given about when to prefer this over siblings like pve_get_cluster_resources or pve_get_node_status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden of behavioral disclosure. The verb 'List' implicitly indicates a read-only operation, but the description does not explicitly state safety, permissions, or any additional behavioral traits (e.g., scope, rate limits). It conveys the basic action but lacks richer transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the main action ('List') and then provides a clear list of the output fields. There is no wasted wording or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with no parameters and an output schema, the description adequately covers the tool's purpose and content. It does not need to explain return values since an output schema exists. The description is complete enough for an agent to select this tool appropriately among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. The description does not need to explain any parameters since none exist, and the schema confirms this is complete (100% coverage with no properties).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and clearly identifies the resource as 'VM replication jobs', which distinguishes it from sibling tools like pve_get_backup_jobs. The included fields (source, target, schedule, rate, status) further clarify the tool's exact purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a user needs to view replication jobs, but it does not explicitly state when to use this tool over alternatives or exclude other cases. No direct 'when' or 'when not' guidance is provided, so it falls at the 'implied usage' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavior. It mentions wildcard support in name filtering and status options, but does not disclose return format, potential side effects, or whether it includes VMs across all nodes beyond the phrase 'cluster'. The operation is inherently read-only, but this is not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is one concise sentence that front-loads the main action and includes filter details without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers the core functionality and optional filters. The output schema provides return value details, so the description does not need to explain that. It is nearly complete, though it could mention pagination or that it lists across all nodes explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add parameter meaning. It explains that name_filter supports * wildcards and that status_filter filters by status, adding value beyond the raw schema. However, it does not describe matching behavior or default values beyond what the schema enum/defaults provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists QEMU VMs in the Proxmox cluster, using a specific verb and resource. It distinguishes from sibling pve_list_lxc by specifying QEMU VMs (not LXC containers).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for listing VMs with optional filters, but does not explicitly state when to use it over alternatives like pve_get_vm_status or pve_list_lxc. No exclusions or alternative tool names are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the default behavior when vm_name is omitted ('all VMs'), which is valuable. However, it doesn't discuss error cases, permissions, or return payload details, which is expected given no annotations. The core behavior is transparent enough for a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and information-dense, with zero filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with one optional parameter and an output schema, the description covers the essential usage. It could mention potential errors or require more detail, but the low complexity makes this sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the vm_name parameter's effect: filter by VM name or omit for all VMs. This compensates for the schema's 0% coverage, clarifying the parameter's optionality and semantics effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists Proxmox-level snapshots for a VM, with a scope qualifier ('or all VMs if no name given'). This specific verb-resource combination distinguishes it from sibling tools that target nodes, storage, or VM configurations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use this tool: to retrieve snapshots for a specific VM or all VMs based on vm_name. It doesn't explicitly name alternatives or exclusions, but the scope guidance is sufficient and unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'List' clearly signals a read-only operation, and the description adds the specific fields returned. This is adequate for a simple, side-effect-free operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded clause that states exactly what the tool does and what it returns. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation with an output schema, the description adequately captures the tool's purpose and key returned data. It is complete given the low complexity and presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty with 100% coverage, so there are no parameter semantics to clarify. Baseline for no parameters is 4, and the description correctly focuses on output rather than inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'configured vzdump backup jobs' and enumerates the returned attributes (schedule, storage, VMs, compression, mode). This clearly distinguishes it from sibling tools like pve_get_replication_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for reading backup job configuration via the verb 'List' but offers no explicit guidance on when to prefer this tool over alternatives or when it is inappropriate. It does not mention exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/UriWise/pve-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server