mcp-proxmox

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.2.2
Disambiguation4/5
Most tools are clearly separated by resource type and action (snapshot vs backup vs guest lifecycle). Minor overlap exists between list_storage_content (backup/template filters) and list_backups/list_templates, but descriptions clarify the intended use.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (list_snapshots, create_backup, delete_firewall_rule, get_guest_status). Minor abbreviations like create_vm vs create_container do not break the convention.
Tool Count2/5
34 tools is on the heavy side for an MCP server, exceeding the 25+ threshold. While each tool maps to a distinct Proxmox API operation, the surface area is broad and some actions (e.g., guest power operations) could be consolidated.
Completeness4/5
Core workflows are covered: guest lifecycle, snapshots, backups, firewall, templates, and cloud-init. Gaps include general VM/CT configuration updates beyond resize, storage provisioning, and node maintenance, but these are secondary to the main management domain.
Average 3.9/5 across 34 of 34 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 2 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 17, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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.json to 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates a snapshot but lacks critical details: it does not specify if this is a read-only or destructive operation, what permissions are required, whether it affects VM/container availability, or any rate limits. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, starting with the core purpose followed by parameter details in a structured 'Args:' section. Each sentence adds value without redundancy, making it efficient and easy to parse, though it could be slightly more concise by integrating the parameter explanations more seamlessly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with 3 parameters, no annotations, but an output schema exists), the description is moderately complete. It covers the basic purpose and parameters but lacks behavioral context and usage guidelines. The presence of an output schema means return values are documented elsewhere, reducing the burden on the description, but overall it falls short of being fully informative for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining each parameter: 'vmid' as the numeric ID of the VM/container, 'name' with format constraints (alphanumeric, hyphens, underscores), and 'description' as optional. However, it does not cover all potential semantics, such as valid ranges for 'vmid' or effects of the snapshot creation, leaving some gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a new snapshot') and the target resource ('for a VM or container'), which is specific and unambiguous. However, it does not explicitly differentiate this tool from sibling tools like 'create_backup' or 'rollback_snapshot', which might involve similar snapshot-related operations, leaving some room for confusion in tool selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. It does not mention sibling tools such as 'create_backup' (for backups) or 'rollback_snapshot' (for reverting to snapshots), nor does it specify prerequisites like VM/container state or permissions, leaving the agent without context for appropriate 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?
No annotations are provided, so the description carries the full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose any behavioral traits like pagination, rate limits, authentication needs, or what constitutes a 'backup file' in this context. This is inadequate for a tool with potential complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with the core purpose, followed by parameter details in a structured 'Args' section. There's minimal waste, though the parameter explanations could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, 0% schema coverage, but an output schema exists, the description is moderately complete. It covers the basic purpose and parameters, but lacks behavioral context and usage guidelines. The output schema mitigates the need to explain return values, but overall completeness is just adequate for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists all three parameters with brief explanations of their filtering purposes, adding meaning beyond the bare schema. However, it doesn't detail format constraints (e.g., node name patterns) or interactions between filters, leaving gaps in semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('backup files across storages'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_storage_content' or 'list_snapshots', which might also involve listing backup-related items, so it misses full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. With siblings like 'list_storage_content' and 'restore_backup', there's no mention of context, prerequisites, or exclusions, leaving the agent to guess based on tool names alone.
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 carries full burden but offers minimal behavioral insight. It states it's a list operation but doesn't cover pagination, sorting, error conditions, authentication needs, or rate limits. The description doesn't contradict annotations (none exist), but it's insufficient for a tool with potential complexity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately concise with two sentences that directly state the purpose and parameter meaning. It's front-loaded with the core functionality, though the 'Args:' section could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter, 0% schema coverage, and an output schema (which reduces need to describe returns), the description is minimally adequate. It covers the basic purpose and parameter meaning but lacks behavioral details and usage context that would help an agent operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds basic semantics for the single parameter 'vmid' by explaining it's 'The numeric ID of the VM or container.' This provides context beyond the schema's type/requirement info, though it doesn't detail format constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all snapshots') and resource ('for a VM or container'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'list_backups' or 'list_containers' beyond mentioning snapshots specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 doesn't mention prerequisites, context for selecting this over other list tools, or relationships with sibling tools like 'create_snapshot' or 'delete_snapshot'.
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 carries full burden but offers minimal behavioral insight. It mentions filtering capabilities but doesn't disclose whether this is a read-only operation, what permissions are required, how results are paginated or sorted, or what happens with invalid filters. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence adds value, and it's appropriately sized for a listing tool. Minor improvement could come from integrating the parameter details more seamlessly, but overall it's well-organized and avoids redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 optional parameters), no annotations, and an output schema (which handles return values), the description is minimally adequate. It covers purpose and parameters but lacks behavioral context like permissions, pagination, or error handling. The output schema reduces the need to explain returns, but more operational guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for both parameters beyond the schema's 0% coverage. It explains that 'node' filters by node name and 'status' filters by specific states ('running', 'stopped'), including enum values not in the schema. This compensates well for the schema's lack of descriptions, though it doesn't detail format constraints or default behaviors.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all LXC containers across the cluster'), making the purpose immediately understandable. It distinguishes from siblings like list_vms and list_nodes by specifying LXC containers. However, it doesn't explicitly contrast with list_guests or other container-related tools, keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like list_vms or list_guests. It mentions filtering options but doesn't explain when filtering by node or status is appropriate or what happens without filters. No prerequisites or exclusions are stated.
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 full burden. It states it's a list operation, implying read-only behavior, but doesn't disclose any behavioral traits like permissions needed, rate limits, pagination, or what happens if no storage pools exist. The mention of 'capacity and usage info' hints at output content but lacks detail on format or completeness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a brief parameter explanation. Every sentence adds value: the first defines the tool's scope and output, the second clarifies the optional parameter. There's no wasted text, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (1 optional parameter) and the presence of an output schema (which handles return values), the description is minimally adequate. However, with no annotations and incomplete parameter documentation, it leaves gaps in behavioral context and usage guidance. It meets basic needs but could be more comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an 'Args' section that documents the 'node' parameter as optional for filtering by node name, adding meaning beyond the input schema (which has 0% description coverage and only shows 'node' as an optional string/null). However, with 1 parameter and low schema coverage, this partially compensates but doesn't fully explain the parameter's semantics (e.g., node name format or filtering logic).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List storage pools across the cluster') and specifies the resource ('storage pools'), including what information is returned ('with capacity and usage info'). It distinguishes from siblings like list_nodes or list_storage_content by focusing on storage pools specifically. However, it doesn't explicitly differentiate from all siblings, keeping it at 4 rather than 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. It doesn't mention sibling tools like list_storage_content (which might list contents within storage pools) or explain scenarios where filtering by node is appropriate. There's no context about prerequisites or 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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions default values and limits (default 20, max 100) which is helpful, but doesn't cover authentication needs, rate limits, error handling, pagination, or what 'recent' means temporally. For a read operation with no annotation support, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear purpose statement followed by parameter details. The two-sentence format is efficient, though the second sentence could be more concise. No wasted words, but could benefit from bullet points for parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 3 parameters with 0% schema coverage and no annotations, the description does a decent job explaining parameters but lacks behavioral context. The existence of an output schema means return values don't need explanation, but for a tool with no annotations, more operational guidance would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates well by explaining all three parameters: 'node' (name of Proxmox node), 'limit' (default 20, max 100), and 'status' (optional filter with specific values: 'ok', 'error', 'running'). This adds meaningful context beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('recent tasks on a Proxmox node'), with examples of task types (backups, migrations, snapshots). It distinguishes from siblings like list_backups or list_snapshots by covering multiple task types, but doesn't explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or compare with sibling tools like get_guest_status for task-related information. The description only states what it does, not when it's appropriate.
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 carries the full burden of behavioral disclosure. It states what the tool does but lacks details on permissions, rate limits, response format, or error handling. For a read operation with no annotation coverage, this is a significant gap in 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, with a clear purpose statement followed by concise parameter explanations. Every sentence adds value without redundancy, making it efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description doesn't need to explain return values. However, with no annotations and 0% schema description coverage, it partially compensates with parameter semantics but lacks behavioral context. For a metrics retrieval tool, this is adequate but with clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining 'vmid' as 'The numeric ID of the VM or container' and 'timeframe' with options and default, which clarifies beyond the bare schema. However, it doesn't detail the format or units of the metrics returned, leaving some semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'resource usage metrics (CPU, memory, network, disk I/O) for a VM or container', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_guest_status' which might provide different types of status information, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. It doesn't mention sibling tools like 'get_guest_status' or explain the context for choosing metrics over status, nor does it specify prerequisites or exclusions, leaving usage unclear.
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 mentions 'Auto-detects type and node,' which adds some context beyond basic functionality, but it doesn't cover critical aspects like whether this is a read-only operation, error handling, permissions required, rate limits, or what 'detailed status' entails. For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded. The first sentence clearly states the purpose, and the second provides essential parameter details with an example. There's no wasted text, and the structure is efficient, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (1 parameter, no annotations, but with an output schema), the description is somewhat complete but has gaps. The output schema exists, so the description doesn't need to explain return values, but it lacks usage guidelines and full behavioral transparency. It covers the basic purpose and parameter semantics adequately but falls short in providing a holistic understanding for effective tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics beyond the input schema. The schema has 1 parameter with 0% description coverage (only 'vmid' as an integer). The description explains that 'vmid' is 'The numeric ID of the VM or container (e.g. 100, 200),' clarifying its purpose and providing an example. This compensates well for the low schema coverage, though it could be more detailed (e.g., valid ranges).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get detailed status of a VM or container by VMID. Auto-detects type and node.' It specifies the verb ('Get'), resource ('detailed status of a VM or container'), and key mechanism ('by VMID'). However, it doesn't explicitly differentiate from sibling tools like 'get_guest_metrics' or 'get_node_status', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. It doesn't mention sibling tools like 'get_guest_metrics' (for metrics vs. status), 'list_vms' (for listing vs. detailed status), or 'get_node_status' (for node vs. guest status). There's no context about prerequisites or exclusions, leaving the agent to infer usage from the purpose alone.
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 must carry the full burden of behavioral disclosure. The description only states the basic action (list) but doesn't disclose details like whether the operation is safe (read-only), whether it requires specific privileges, or what happens if the node is invalid. It also doesn't mention the output format beyond the schema, though the output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a parameter hint in a structured format. It is extremely concise and front-loaded with the core purpose, with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple action (list) with one parameter and an output schema. The description captures the essential purpose and the parameter, but given that no annotations exist, it could add more context like whether this is a read-only operation or the types of interfaces included. It's adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does 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 parameter meaning. It does explain that 'node' is the 'Name of the Proxmox node (e.g. 'pve')', which adds a concrete example and clarifies the expected value. This is helpful but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List network interfaces, bridges, and bonds on a Proxmox node', which is a specific verb+resource+scope. It distinguishes the tool from siblings like list_storages or list_vms, though it doesn't explicitly differentiate from the node-status tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to list network information for a given node, but it doesn't provide explicit guidance on when to use this tool versus alternatives (e.g., get_node_status) or mention any prerequisites. The context is clear but lacks exclusions or alternative recommendations.
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 carries the full burden of behavioral disclosure. While it mentions the backup modes ('snapshot', 'suspend', 'stop') which imply different downtime impacts, it doesn't explicitly state whether this is a destructive operation, what permissions are required, or how long the process might take. The description adds some context but leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by parameter details. Every sentence adds value, though the parameter explanations could be slightly more concise. The information is appropriately front-loaded with the core functionality stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a backup operation with no annotations, the description covers parameters well but lacks important behavioral context about permissions, side effects, and error conditions. The presence of an output schema helps, but for a potentially impactful operation, more guidance on usage and consequences would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed semantics for all 5 parameters. It explains what each parameter means, lists valid values for mode and compress, and specifies defaults. This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a backup') and the target resource ('VM or container'), distinguishing it from siblings like create_snapshot or restore_backup. It also specifies the backup type as 'vzdump', which adds technical precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like create_snapshot or restore_backup. The description lacks context about prerequisites, timing considerations, or comparisons with 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?
With no annotations provided, the description carries full burden but only states what the tool does without behavioral details. It doesn't disclose whether this is a read-only operation, potential performance impacts, pagination behavior, or error conditions, leaving significant gaps for a tool that lists resources across a cluster.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly front-loaded with the core purpose in the first sentence, followed by a clean Args section. Every sentence earns its place with zero wasted words, making it immediately understandable and scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (listing across a cluster with filtering), no annotations, but an output schema exists, the description covers the essential purpose and parameters well. It's complete enough for basic usage, though additional behavioral context would enhance it for a production environment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for both parameters: 'node' filters by node name and 'status' filters by specific states ('running', 'stopped'), adding meaningful context beyond the bare schema. However, it doesn't explain format requirements or default behaviors when parameters are omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('List all QEMU virtual machines') and resource ('across the cluster'), distinguishing it from siblings like list_containers, list_nodes, or list_snapshots. It precisely defines scope without being vague or tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 like get_guest_status or list_containers. The description mentions filtering options but doesn't specify contexts where this tool is preferred over others for similar 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?
No annotations are provided, so the description carries the full burden. It indicates this is a read operation ('Get') and specifies the type of data returned (CPU, memory, etc.), which is useful behavioral context. However, it doesn't disclose potential errors (e.g., invalid node name), performance characteristics, or authentication requirements, leaving gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose in the first sentence, followed by a concise 'Args' section that adds necessary parameter context without redundancy. Every sentence earns its place, and the structure is clear and efficient, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (single parameter, read-only operation), the description covers the purpose and parameter semantics adequately. An output schema exists, so the description doesn't need to explain return values. However, with no annotations, it could benefit from more behavioral context (e.g., error handling) to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning by explaining the 'node' parameter as 'Name of the Proxmox node' with an example ('e.g. 'pve', 'node1''), which clarifies the expected input format beyond the schema's basic string type. This is valuable given the low coverage, though it doesn't detail constraints like valid node names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'detailed status for a specific node', with specific attributes listed (CPU model, memory, disk, and versions). It distinguishes from siblings like 'list_nodes' (which lists nodes) and 'get_guest_status' (which focuses on guests), but doesn't explicitly contrast them. The purpose is specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying 'for a specific node', suggesting it's for detailed status of individual nodes rather than listing all nodes. However, it doesn't explicitly state when to use this vs. alternatives like 'list_nodes' (for overview) or 'get_guest_status' (for guest-specific status). No exclusions or prerequisites are mentioned.
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 carries the full burden of behavioral disclosure. It mentions 'gracefully shut down' and the mechanisms, which implies a non-destructive operation, but does not address critical aspects like required permissions, potential side effects, error conditions, or what 'graceful' entails in practice. The description is insufficient for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by a parameter explanation. Both sentences are necessary and front-loaded, with zero redundant information. The formatting with 'Args:' enhances readability without adding bulk.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation operation with no annotations) and the presence of an output schema (which may cover return values), the description is partially complete. It explains the purpose and parameter but lacks details on behavioral traits, error handling, and usage context relative to siblings. The output schema might mitigate some gaps, but the description alone is inadequate for safe operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does 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. It provides the parameter 'vmid' with a clear explanation ('The numeric ID of the VM or container to shut down'), adding essential meaning beyond the schema's basic type definition. However, it does not cover potential constraints or examples, leaving some gaps in parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('gracefully shut down') and target resource ('a VM or container'), distinguishing it from sibling tools like 'stop_guest' (which may imply forceful termination) and 'reboot_guest'. It also specifies the mechanism ('via ACPI signal (VMs) or init (containers)'), providing precise differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for graceful shutdowns rather than forceful stops, but does not explicitly state when to use this tool versus alternatives like 'stop_guest' or 'reboot_guest'. It provides some context through the mechanism details, but lacks explicit guidance on prerequisites, exclusions, or comparative scenarios with siblings.
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 mentions the action ('Start') but lacks details on permissions required, whether it's idempotent, expected time to start, error conditions (e.g., if VM is already running), or what the output schema might indicate. This leaves significant gaps for a mutation tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured: a clear purpose statement followed by a brief parameter explanation in a labeled 'Args' section. Every sentence adds value without redundancy, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (which reduces need to describe return values) but no annotations and low schema coverage, the description is minimally adequate. It covers the basic action and parameter, but as a mutation tool, it should include more behavioral details like error handling or side effects to be fully complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context for the single parameter 'vmid' by specifying it as 'The numeric ID of the VM or container to start', which clarifies its purpose beyond the schema's basic type (integer). With 0% schema description coverage and only one parameter, this compensates adequately, though it could note format constraints (e.g., valid ranges).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Start') and target resource ('a stopped VM or container'), distinguishing it from sibling tools like 'stop_guest', 'reboot_guest', or 'shutdown_guest'. It explicitly mentions the state requirement ('stopped'), which helps differentiate its purpose from other power-state operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by specifying the target must be 'stopped', suggesting it should not be used on running or paused instances. However, it does not explicitly state when to use alternatives like 'reboot_guest' or 'shutdown_guest', nor does it mention prerequisites such as checking guest status first, leaving some ambiguity in context.
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. While it mentions that the container can be started after creation and that VMID is auto-assigned if not provided, it lacks critical information such as required permissions, whether this is a destructive/mutative operation (implied by 'Create' but not explicit), potential rate limits, error conditions, or what happens on failure. For a complex creation tool with 12 parameters, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence stating the purpose, followed by a comprehensive parameter list. Every sentence earns its place by providing essential information. It could be slightly more concise by integrating defaults into the parameter descriptions more seamlessly, but overall it's efficient and front-loaded with the core functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (12 parameters, creation operation) and the presence of an output schema (which means return values are documented elsewhere), the description does a good job covering inputs and basic behavior. However, it lacks details on permissions, error handling, and side effects, which are important for a creation tool. The parameter explanations are thorough, but behavioral context is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the input schema provides no descriptions for any parameters. The description compensates fully by providing detailed explanations for all 12 parameters, including examples (e.g., 'pve' for node, template format), defaults, optional vs. required status, and guidance on how to find values (e.g., using list_storage_content for templates). This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('new LXC container from a template'), making the purpose specific and unambiguous. It distinguishes this tool from siblings like create_vm (which creates virtual machines) and clone_guest (which clones existing guests), establishing clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage by mentioning that templates can be found using the list_storage_content tool with content_type='vztmpl', which helps guide the agent to necessary prerequisites. However, it doesn't explicitly state when to use this tool versus alternatives like create_vm or clone_guest, nor does it mention any exclusions or when-not-to-use scenarios.
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 full burden. It states it's a listing operation (implied read-only) and specifies what data fields are returned, but doesn't disclose behavioral traits like pagination, rate limits, authentication requirements, or error conditions. It adds some context about returned attributes but lacks operational details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('List all nodes in the Proxmox cluster') and adds useful detail about included attributes. Every word earns its place with zero waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0 parameters, 100% schema coverage, and an output schema (which handles return values), the description is reasonably complete. It specifies the resource scope and key attributes returned. However, as a read operation with no annotations, it could benefit from mentioning behavioral aspects like data freshness or cluster-wide scope implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not introducing confusion or redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all nodes in the Proxmox cluster') with specific attributes included ('status, CPU, memory, and uptime'). It distinguishes from siblings like 'get_node_status' (single node) and 'list_containers/list_vms' (specific resource types).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving cluster-wide node information but doesn't explicitly state when to use this versus alternatives like 'get_node_status' (for a specific node) or other listing tools. No explicit exclusions or prerequisites are mentioned.
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 full burden. It describes a read-only listing operation but doesn't disclose behavioral traits like pagination, rate limits, authentication requirements, error conditions, or what happens when storage doesn't exist. The description is minimal beyond stating the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by parameter explanations. Every sentence adds value, and it's appropriately sized for a listing tool with 3 parameters. The information is front-loaded with the core function stated first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (listing operation with filtering), no annotations, and the presence of an output schema, the description provides adequate context. It explains what the tool does and documents all parameters, though behavioral aspects like error handling are omitted. The output schema will handle return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all 3 parameters: node (Proxmox node name), storage_name (storage pool name with examples), and content_type (optional filter with enumerated values). This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'content of a storage pool', with specific examples of content types (ISOs, templates, backups, disk images). It distinguishes from siblings like list_storages (which lists storage pools themselves) and list_backups (which lists backups specifically).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by specifying what content types can be listed and mentioning the optional filter parameter. However, it doesn't explicitly state when to use this tool versus alternatives like list_backups or list_storages, nor does it provide exclusion guidance.
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 discloses key behavioral traits like auto-detection of type/node, default full clone behavior, and optional linked clones, but does not cover permissions, rate limits, error conditions, or the output format (though an output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, followed by a clear 'Args' section. Every sentence adds value without redundancy, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (cloning operation with 6 parameters) and no annotations, the description does well by explaining parameters and basic behavior. However, it lacks details on permissions, errors, or side effects. The presence of an output schema mitigates the need to explain return values, keeping it reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides detailed semantics for all 6 parameters beyond the schema, explaining each parameter's purpose, defaults (e.g., full_clone default true), and implications (e.g., linked vs. full clone), adding significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Clone an existing VM or container') and resources ('VM or container'), distinguishing it from siblings like create_vm, create_container, or create_snapshot by focusing on cloning rather than creating from scratch or snapshotting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cloning VMs/containers but does not explicitly state when to use this tool versus alternatives like create_vm or create_container. It mentions auto-detection of type and node, which provides some context, but lacks explicit guidance on prerequisites or exclusions.
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 burden of behavioral disclosure. It states the VM is 'created stopped by default' and mentions the auto-start option, which is useful. However, it doesn't cover important behavioral aspects like required permissions, whether this is a long-running operation, error conditions, or what happens if resources are insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening statement followed by organized parameter documentation. While comprehensive, it's appropriately sized for an 11-parameter tool. The only minor improvement would be front-loading more critical behavioral information before the parameter list.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (11 parameters, creation operation) and presence of an output schema (which handles return values), the description provides good coverage. It explains the core functionality and documents all parameters thoroughly. The main gap is lack of behavioral context around permissions, errors, and resource constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing detailed parameter documentation. Each parameter gets clear explanations, examples (e.g., '32G', 'local:iso/ubuntu-24.04.iso'), defaults, and usage context. The description adds substantial value beyond what the bare schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Create a new QEMU virtual machine') and resource ('virtual machine'), distinguishing it from sibling tools like clone_guest, create_container, or list_vms. The opening sentence provides unambiguous purpose without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (to create a new VM) and mentions the 'start_after_create' parameter for auto-start behavior. However, it doesn't explicitly contrast when to use this versus alternatives like clone_guest or create_container, which would be needed for a perfect score.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the destructive nature ('Delete'), the safety mechanism via the 'confirm' parameter, and the two-step warning behavior. It doesn't cover permissions, rate limits, or error conditions, but for a tool with no annotations, this provides substantial behavioral context beyond basic functionality.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded: the first sentence states the core purpose, followed by a structured 'Args' section. Every sentence earns its place by explaining parameters or behavior. It could be slightly more concise by integrating the confirm behavior into the main sentence, but it's well-structured and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation, 3 parameters, 0% schema coverage, no annotations, but with an output schema), the description is largely complete. It covers purpose, parameters, and key behavioral traits (safety mechanism). The output schema likely handles return values, so the description doesn't need to explain those. It lacks details on permissions or error cases, but for most contexts, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It explicitly documents all three parameters ('vmid', 'name', 'confirm') with clear semantics: 'vmid' as the numeric ID of the VM/container, 'name' as the snapshot name, and 'confirm' with its safety role and two-step behavior. This adds complete meaning beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Delete') and target resource ('a snapshot from a VM or container'), distinguishing it from sibling tools like 'rollback_snapshot' (which reverts to a snapshot) or 'delete_guest' (which deletes the entire VM/container). The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the 'confirm' parameter explanation ('First call without confirm shows a warning'), suggesting a two-step safety pattern. However, it doesn't explicitly state when to use this tool versus alternatives like 'rollback_snapshot' or 'delete_guest', nor does it mention prerequisites (e.g., the snapshot must exist). The guidance is useful but incomplete.
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 of behavioral disclosure. It reveals the two-step confirmation process (first call shows warning, second with confirm=true executes), which is valuable behavioral context. However, it doesn't mention potential side effects like service interruption, permissions required, or whether the reboot is graceful/forced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly front-loaded with the core purpose in the first sentence, followed by parameter explanations in a clear Args section. Every sentence earns its place with no wasted words, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a destructive operation with no annotations but with an output schema (which handles return values), the description does well by explaining the confirmation safety mechanism. However, for a reboot tool, it could better address risks like data loss or specify whether it's a hard/soft reboot to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining both parameters: vmid as 'numeric ID of the VM or container' and confirm's purpose and behavior ('Must be true to execute. First call without confirm shows a warning'). This adds crucial meaning beyond the bare schema, though it could specify ID format/ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('reboot') and target resource ('a running VM or container'), distinguishing it from sibling tools like shutdown_guest, stop_guest, start_guest, and delete_guest. It uses precise language that conveys the exact operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool (to reboot a running VM/container) and includes a safety mechanism with the confirm parameter. However, it doesn't explicitly state when NOT to use it or mention specific alternatives like shutdown_guest for graceful shutdowns versus reboot for restarting.
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 of behavioral disclosure, and it does reveal the key side-effect of changes taking effect on next boot and the requirement for at least one parameter. However, it omits whether the configuration overwrites or merges with existing cloud-init settings, and lacks error-handling or prerequisite details like requiring cloud-init to be installed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally well-structured: a summary sentence, a critical constraint, and a neatly formatted Args list. Every sentence earns its place, and the layout is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description thoroughly covers the tool's purpose, key constraint, and all parameters, and since an output schema exists, return values need not be detailed. It falls short only by not addressing whether configuration merges with or overwrites existing settings, and omitting any prerequisites like requiring a cloud-init-enabled OS image.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the Args section comprehensively documents all seven parameters with rich context, including formats and examples (e.g., ip_config's 'ip=dhcp' or 'ip=10.0.0.5/24,gw=10.0.0.1'), encoding notes for ssh_keys, and units for nameserver. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it configures cloud-init settings for automated provisioning on a VM, using a specific verb and resource. This unambiguous scope distinguishes it from sibling tools like list_vms, create_snapshot, or start_guest, none of which handle cloud-init configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear operational context, noting that 'At least one parameter must be provided' and that changes take effect on next boot, which helps an agent decide when to invoke it. However, it does not explicitly name alternatives or state when not to use this tool versus a sibling, though the unique purpose makes this less critical.
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 of behavioral disclosure. It mentions prerequisites and exclusions, which adds useful context beyond the basic action. However, it doesn't describe important behavioral aspects like authentication requirements, rate limits, error conditions, or what happens when commands fail or timeout.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by prerequisites, exclusions, and parameter explanations. Every sentence earns its place, and the information is front-loaded with the most important details first. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there's an output schema (which handles return values), no annotations, and good parameter coverage in the description, this is reasonably complete. The main gap is lack of behavioral details about error handling, security implications, or performance characteristics that would be helpful for a command execution tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by providing clear semantic explanations for all 3 parameters: vmid ('numeric ID of the VM'), command ('command to execute' with examples), and timeout ('Max seconds to wait' with default and max values). This adds substantial value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Execute a command') and target resource ('inside a QEMU VM via the guest agent'), distinguishing it from sibling tools like start_guest or get_guest_status that perform different operations on VMs. The verb+resource combination is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool by specifying prerequisites ('Requires qemu-guest-agent to be installed and running inside the VM') and exclusions ('Not supported for LXC containers'). However, it doesn't explicitly mention alternatives or contrast with sibling tools like exec_container_command if such existed.
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 discloses the two-step confirmation process (first call shows warning, second with confirm=true executes), which is valuable behavioral context. However, it doesn't mention potential destructive effects, permissions needed, rate limits, or what happens if the restored guest conflicts with existing resources.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear purpose statement followed by a well-organized parameter breakdown. Every sentence adds value, with no redundant information. The two-step confirmation warning is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a restoration operation with 6 parameters and no annotations, the description does well by explaining all parameters and the confirmation workflow. Since an output schema exists, it doesn't need to describe return values. However, for a potentially destructive operation, more behavioral context about risks would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining all 6 parameters in detail. It provides examples (e.g., volid format), default values, optional vs. required status, and practical guidance like using list_backups to find volid values. This adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Restore') and target resources ('a VM or container from a backup file'), distinguishing it from siblings like create_backup, rollback_snapshot, or clone_guest. It precisely defines the operation without being tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by referencing list_backups to find available backups and explaining when to use confirm. However, it doesn't explicitly state when NOT to use this tool or compare it to alternatives like rollback_snapshot for snapshot-based restoration.
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. It explicitly states the operation is IRREVERSIBLE and that the VM can no longer be started after conversion, only cloned. It also explains the confirm parameter behavior: first call without confirm shows a warning. This is strong behavioral disclosure beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It leads with the core action and irreversibility warning, then provides parameter details in a clear Args section. Every sentence adds value, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no nested objects) and the presence of an output schema, the description is quite complete. It covers the key behavioral aspects (irreversibility, confirm flow) and parameter semantics. It could mention what the output looks like, but the output schema likely covers that, so the description is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains vmid as 'The numeric ID of the VM to convert' and confirm as 'Must be true to execute. First call without confirm shows a warning.' This adds meaning beyond the schema's basic type/default, especially for confirm's two-step behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Convert a stopped VM into a template.' It uses a specific verb (convert) and resource (VM), and distinguishes this from sibling tools like create_vm, clone_guest, and list_templates. The irreversible nature is highlighted upfront, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when a VM is stopped and you want to make it a template. It also provides a clear prerequisite (VM must be stopped) and a warning about irreversibility. However, it does not explicitly mention alternatives or when not to use it, but the context is clear enough for an agent to decide.
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?
With no annotations, the description carries full burden and effectively discloses critical behaviors: irreversible deletion, prerequisite (guest must be stopped), destruction of disk images, and a confirmation safety step. It does not mention permissions, rate limits, or error conditions, but covers key destructive traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and warning, followed by structured parameter explanations. Every sentence adds value—no fluff or repetition—making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity of a destructive operation, no annotations, and an output schema (which handles return values), the description is mostly complete. It covers purpose, prerequisites, safety, and parameter semantics, but lacks details on permissions, error cases, or post-deletion effects, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful context for both parameters: vmid is explained as 'numeric ID of the VM or container to delete', and confirm is detailed with its safety role ('Must be true to execute. First call without confirm shows a warning'), going beyond the basic schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('permanently delete') and resource ('a VM or container'), distinguishing it from siblings like stop_guest or delete_snapshot by emphasizing irreversibility and destruction of disk images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit prerequisites ('The guest must be stopped before deletion') and a safety mechanism ('First call without confirm shows a warning'), but does not specify when to use this versus alternatives like delete_snapshot or restore_backup, though the irreversible nature is implied.
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?
This is a migration operation, which is inherently destructive/mutating. There are no annotations provided, so the description must carry the burden. It does disclose the behavior of the 'confirm' parameter: 'First call without confirm shows a warning.' It also clarifies what 'online' does: 'Keeps the guest running.' This is helpful because the schema only says 'default: true' with no explanation. It could be improved by mentioning prerequisites (e.g., shared storage, cluster membership) or consequences (e.g., downtime for offline migration).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a bullet-like structure with each parameter explained in one line. It front-loads the purpose. No wasted words. Each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a migration tool with no annotations, the description does a good job covering key aspects: purpose, parameters, and the confirm flow. It lacks some operational details like error conditions or prerequisites, but it provides enough for an agent to use it safely. The presence of an output schema might help, but we don't see its content. The score reflects that a few more details (like what happens on failure, or requirements for shared storage) would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning the description must fully compensate. It does: it explains 'vmid' as the numeric ID, 'target_node' with an example, 'online' with behavior (keeps guest running), and 'confirm' with the warning behavior. This is a strong compensation. The only minor gap is that it doesn't explain the format of vmid (e.g., 100-199 for VMs) but it's a standard term.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Live migrate a VM or container to another node in the cluster.' This is a specific verb+resource combination that distinguishes it from siblings like clone_guest or backup operations. It also mentions both VMs and containers, which adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to move a guest to another node. It notes the difference between online vs offline migration. However, it does not explicitly state when NOT to use it or mention alternatives. It says 'Live migrate...' but doesn't discuss scenarios where offline migration would be preferable.
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?
With no annotations provided, the description carries the full burden. It details operational behavior including default enablement ('enable: Enable rule immediately (default true)'), position in chain, and scope resolution. It could mention permissions or side effects, but the core 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear one-line summary, followed by a compact parameter list. Each parameter line is informative and not redundant. It is slightly long due to 13 parameters, but each line earns its place with useful detail or examples.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (13 parameters, 3 scope modes), the description is complete: it explains every parameter, required and optional, and defines scope fallback behavior. The presence of an output schema reduces the need to describe return value. The description adequately covers how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides detailed semantics for all 13 parameters, including accepted values, examples, and optionality. This adds significant value beyond the schema's bare types and defaults, especially for fields like dport, source, iface, and pos.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Add a firewall rule to a VM/CT, node, or cluster' with a specific verb and target scope. It distinguishes this from sibling tools like list_firewall_rules and delete_firewall_rule by emphasizing the creation action and clarifying the three possible target levels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: if neither vmid nor node is provided, the rule applies at cluster level, and 'node' is ignored when vmid is set. It does not explicitly mention alternatives, but no alternative add tool exists, so exclusions are not necessary.
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?
The description indicates a read-only action via the verb 'List.' It does not mention any side effects or permissions, but with no annotations, the description carries the burden. Since listing is inherently read-only and no mutating behavior is implied, it is sufficiently transparent, though it could be more explicit about the absence of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It states the purpose in one sentence and then provides parameter details, with no unnecessary wording or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential use case and parameter behavior. It does not detail the return format, but since an output schema is indicated (though not shown), that may be unnecessary. Overall, it provides sufficient context for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters: vmid targets a specific VM/container, node targets a node, and notes that vmid takes precedence. This adds meaningful semantics beyond the schema, which only lists types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'List firewall rules.' It also specifies the target scopes (VM/CT, node, or cluster), which distinguishes it from other list tools like list_snapshots or list_networks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides usage guidance by explaining the optional parameters and their precedence (vmid overrides node). It implicitly indicates when to use each targeting option, though it does not explicitly compare with other list 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.
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' makes it clear this is a read-only operation, and 'in the cluster' scopes the search domain. It does not detail output format or edge cases, but the output schema likely covers that, and no side effects are expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the action 'List' and includes only essential scope details. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a parameterless list operation with an output schema, the description provides sufficient context: it states the action, resource, scope, and purpose ('for cloning'). No additional behavioral or return-value details are necessary given the simplicity and existing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema. The description correctly omits parameter details, and the baseline for 0-param tools is 4, which is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and resource 'VM templates', and adds the scope 'in the cluster for cloning'. This clearly distinguishes it from sibling tools like list_snapshots or list_vms, and unambiguously states the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by mentioning 'available in the cluster for cloning', which tells the agent when to use this tool (when listing templates). It does not explicitly exclude alternatives, but the resource type is unique enough that clear context is provided without the need for exclusions.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior: it's a destructive operation ('Force-stop') with a risk of data loss, includes a confirmation mechanism, and outlines a two-step process (first call without confirm shows a warning). This adds significant value beyond the basic schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and warning, followed by a structured 'Args' section that efficiently details parameters. Every sentence earns its place by providing essential information without redundancy, making it highly concise and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation with confirmation), no annotations, and an output schema present, the description is largely complete. It covers purpose, risks, and parameter semantics well, but could benefit from more explicit guidance on when to use versus siblings like 'shutdown_guest' for full contextual coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It fully explains both parameters: 'vmid' as 'The numeric ID of the VM or container to stop' and 'confirm' with detailed semantics about its role in execution and the warning mechanism. This adds crucial meaning not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Force-stop') and target ('a running VM or container'), distinguishing it from siblings like 'shutdown_guest' or 'reboot_guest' by emphasizing forceful termination. It specifies the resource type and the potential consequence of data loss, making the purpose explicit and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for usage with the warning about data loss and the two-step confirmation process, but it does not explicitly state when to use this tool versus alternatives like 'shutdown_guest' or 'reboot_guest'. It implies usage in forceful scenarios but lacks direct comparison or exclusion criteria.
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?
With no annotations, the description carries the behavioral disclosure burden. It discloses the confirmation requirement ('Must be true to execute'), the warning on first call, and the precedence rule ('node... Ignored if vmid is provided'). It does not mention reversibility or error handling, but the destructive nature is implied by 'delete' and the confirm step.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and efficient. It opens with the core purpose, then a usage hint, then a clear Args list. No redundant sentences; every line adds value. The code-block formatting for args enhances readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no annotations, the description covers all key aspects: how to identify a rule (position), scope selection (vmid, node, cluster), confirmation workflow, and prerequisite listing. The output schema exists, so return details are not needed. This is comprehensive for a delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain all parameters. The 'Args' section explicitly describes each parameter: pos (position from list), vmid (optional VM scope), node (optional node scope, ignored if vmid), and confirm (must be true to execute). This adds significant meaning beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: 'Delete a firewall rule by its position number.' It specifies the method (position number) and directly differentiates from sibling tools like list_firewall_rules and add_firewall_rule by focusing on deletion and referencing the list command for positions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use list_firewall_rules first to see rule positions.' It also explains scope selection (vmid, node, or cluster default) and the confirm behavior (first call shows a warning). It does not explicitly state when not to use the tool, but the prerequisites and scope logic are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses critical behaviors: disk resize is irreversible, and the confirm flag is required to execute (with a warning on first call). This goes beyond the bare mutation and alerts the user to side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise but includes some redundancy (e.g., listing parameters in prose and then again in arg list). Still, it is well-structured and not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential context: what it does, prerequisites (at least one resource), and behavioral consequences. It is complete for a mutation tool without needing an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Each parameter is explained with units (MB for memory), format (disk_size with units and examples), and defaults (disk default 'scsi0'). This adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: resizing CPU, memory, and/or disk of a VM or container. It is specific and distinguishes from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states that at least one resource must be provided, explains the effect on running guests (reboot required for CPU/memory) and that disk resize is immediate and irreversible. This provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and excels by disclosing critical behavioral traits: the destructive nature ('All changes since the snapshot will be LOST'), the confirmation workflow ('First call without confirm shows a warning'), and the execution requirement ('Must be true to execute'). This goes beyond basic function to explain safety and procedural aspects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, followed by a critical warning, then parameter details in a clear 'Args:' section. Every sentence earns its place by providing necessary information without redundancy, making it highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (destructive operation), no annotations, and an output schema present, the description is complete. It covers purpose, warnings, parameter semantics, and usage guidelines, leaving output details to the schema. This provides all needed context for safe and correct tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It does so by explaining all three parameters: 'vmid' (numeric ID of VM/container), 'name' (snapshot to rollback to), and 'confirm' (must be true to execute, with warning behavior). This adds essential meaning beyond the bare schema, clarifying purpose and usage for each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Rollback a VM or container to a previous snapshot') and distinguishes it from siblings like 'create_snapshot', 'delete_snapshot', and 'restore_backup' by focusing on reverting to an existing snapshot rather than creating, deleting, or restoring from a backup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage guidance: the 'confirm' parameter must be true to execute, with a warning on first call without it. This clearly indicates when to use it (for rollback operations with confirmation) versus alternatives like 'create_snapshot' or 'restore_backup' for other snapshot-related tasks.
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:

[![mcp-proxmox MCP server](https://glama.ai/mcp/servers/antonio-mello-ai/mcp-proxmox/badges/card.svg)](https://glama.ai/mcp/servers/antonio-mello-ai/mcp-proxmox)

Score Badge

Copy to your README.md:

[![mcp-proxmox MCP server](https://glama.ai/mcp/servers/antonio-mello-ai/mcp-proxmox/badges/score.svg)](https://glama.ai/mcp/servers/antonio-mello-ai/mcp-proxmox)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/antonio-mello-ai/mcp-proxmox'

If you have feedback or need assistance with the MCP directory API, please join our Discord server