proxmox-mcp

by edymol

Overview Schema Related Servers Score Discussions

Python

Remote

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Every tool targets a distinct resource and action: configuration vs status, snapshots vs backups, guests vs containers, node listing vs capacity. The consolidated health summary explicitly positions itself as a higher-level read, not a duplicate. There is no real overlap or risk of misselection.
Naming Consistency4/5
Eleven tools follow a consistent verb_noun snake_case pattern (list_*, get_*, check_*, inspect_*), with verbs semantically appropriate to each operation. The one exception is 'guest_health_summary', which is a noun phrase and breaks the pattern, but it is a single minor deviation.
Tool Count5/5
Twelve tools is squarely in the well-scoped range (3-15) for a Proxmox introspection server. Each tool covers a meaningful read-only aspect of the cluster, and there is no redundancy or bloat. The count aligns with the apparent domain and purpose.
Completeness4/5
The surface covers the core read-only workflows: guest listing/status/config, node capacity, storage, snapshots, backups, container inspection, and IP availability. Minor gaps exist (e.g., no node network info, no task history), but these are not critical for the evident purpose of a monitoring/introspection MCP server.
Average 4.4/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without any annotations, the description fully carries the behavioral burden and excels: it discloses idempotence, read-only safety, single-node edge case behavior, and partial failure handling with warnings rather than exceptions. This goes beyond what annotations typically provide.
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 two sentences, front-loaded with the primary purpose. The second sentence adds valuable edge-case and error-handling details without any fluff or redundancy.
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 simplicity, the presence of an output schema, and no annotations, the description covers the essential contextual aspects: what it returns, read-only behavior, single-node handling, and partial failures. The only minor gap is the unmentioned profile parameter, but it is optional and does not undermine overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description never mentions the 'profile' parameter, and schema coverage is 0%, so no meaning is added beyond the parameter's existence in the schema. The description does not compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The first sentence clearly states the tool lists all cluster nodes with specific attributes (capacity, uptime, PVE version), using a specific verb and resource that distinguishes it from siblings like get_node_capacity.
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 as a general node listing but provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools. The single-node and partial-result notes give context but not direct selection criteria.
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?
No annotations are present, so the description carries the full burden, and it excels: it declares read-only/idempotent behavior, enumerates returned metrics, and explains two edge cases (stopped guest and unknown vmid) with concrete responses. This is exemplary disclosure beyond typical descriptions.
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?
Four compact sentences, each adding distinct value: purpose, safety/return scope, and two edge cases. No filler or repetition; every sentence earns its place.
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 tool is well-covered in terms of behavior and return semantics, and an output schema exists. However, the undocumented 'profile' parameter and lack of alternative-tool guidance leave minor gaps, making it strong but not perfect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no property descriptions (0% coverage), so the description must compensate. It gives some meaning to 'node' and 'vmid' through context, but the optional 'profile' parameter is never mentioned, leaving its semantics entirely undocumented.
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 phrase 'One guest's live status, on exactly the node named' clearly identifies the operation as retrieving live status for a single guest on a specific node. This distinguishes it from sibling tools like get_guest_config and guest_health_summary, and the tool name supplies the missing verb.
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 does not explicitly name alternatives or state when to prefer this tool over siblings. It offers contextual signals like 'live status' and 'exactly the node named' that imply per-node monitoring use, but no exclusionary guidance is provided.
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 full weight. It explicitly states 'Read-only and idempotent', a critical safety property. It also discloses a key edge-case behavior: an unreachable node yields a partial result 'naming it rather than an exception.' The explanation of 'allocation' adds semantic depth about how the data is computed. This goes well beyond a typical opaque description.
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 three sentences, each with a distinct role: purpose, error behavior, and allocation semantics. It is front-loaded with the core purpose in the first sentence. No redundant phrases or filler; every sentence earns its place.
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 tool has an output schema, so return value details are not required in the description. The description covers purpose, read-only/idempotent behavior, partial-failure handling, and the 'allocation' comparison. However, it is missing any explanation of the 'profile' parameter, which is an optional input that could materially affect the query. This gap prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/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 explain parameters. It indirectly clarifies 'node' by stating 'exactly one node,' but it never mentions 'profile' by name or purpose. The 'allocation' concept might relate to profile, but no explicit linkage is made, leaving the profile parameter completely unexplained. The description adds minimal value for 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 opens with a specific resource enumeration: 'CPU, memory, swap, and per-mount filesystem utilization for exactly one node.' The scope ('exactly one node') clearly distinguishes it from sibling tools like list_nodes, which would return all nodes. The verb (get) is implicit but the noun phrase is precise and self-explanatory.
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 a single node ('exactly one node') and notes the 'allocation' comparison for capacity planning. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or direct the agent to list_* tools for broader queries. The guidance is mostly implicit.
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, the description fully shoulders behavioral disclosure. It clearly states the operation is read-only and idempotent, explains the semantics of missing backups, and details partial failure behavior with warnings and partial results. This is rich, valuable context beyond a basic listing.
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 three sentences, each earning its place. The first sentence states the core output, the second adds critical interpretive context, and the third clarifies failure behavior. No filler 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?
The description covers key behavioral aspects such as read-only/idempotent, partial failures, and the significance of missing backups. An output schema exists, so return values need not be detailed. Slight gap remains around parameter usage configuration, but overall it is contextually sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain node, vmid, or profile, nor how they affect scope. The phrase 'per guest' and 'every guest in scope' hints at filtering, but the parameters themselves are not named or described, leaving the agent with inadequate guidance.
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 opens with a specific verb and resource: 'Backup volumes with their guest, format, size, and timestamp, plus recency per guest.' This clearly defines what the tool returns and distinguishes it from sibling tools like list_snapshots or list_guests.
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 the tool by focusing on backup listings and recency per guest, but it does not explicitly name alternatives or state when not to use it. The context is clear enough for an agent to infer its use for backup assessment, but explicit exclusions would be stronger.
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 exceeds it. It explicitly states the tool is 'Read-only and idempotent,' guarantees mount contents are never read, and that environment variables, labels, and command lines are never returned. It also explains the precise semantics of partial results and warnings, providing deep behavioral transparency beyond any typical annotation.
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 long but every sentence adds value. It is front-loaded with the core purpose, followed by a structured breakdown of report contents and then a well-organized explanation of edge cases. The formatting with bold markers for critical guarantees makes it easy to scan. Nothing feels redundant or wasteful.
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 and the presence of an output schema, the description sufficiently covers what is inspected, what is returned, and how to interpret unusual cases. The only notable omission is the 'profile' parameter, which is optional and not explained. Otherwise, the description provides complete contextual guidance for selecting and invoking the 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?
The description gives meaningful clues for three of four parameters: 'node' is named, 'LXC guest' maps to vmid, and 'project' is the compose project name. However, the optional 'profile' parameter is never mentioned, and with 0% schema description coverage, the agent receives no additional clarity on what profile does or when to set it. The description partially compensates but leaves a gap.
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 opens with a clear, specific statement: 'One compose project inside one LXC guest, on exactly the node named.' and then enumerates exactly what it reports (status, working directory, config paths, per-service details). This distinguishes it from sibling tools like 'list_guest_containers' or 'get_guest_config' by its focus on a single compose stack and its read-only inspection behavior.
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 establishes the precise scope: 'one compose project inside one LXC guest, on exactly the node named.' It also explains nuanced edge cases (empty services list, partial results with warnings, guests without Docker) that clarify when the tool is applicable and how to interpret responses. However, it does not explicitly name alternative tools for other scenarios, so it stops short of full when-to-use vs. when-not-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, the description carries the full burden and does so exceptionally. It discloses that the tool combines multiple sources, provides evidence for conclusions, can report 'inconclusive', and never reports 'free' based on absence of evidence. This is far more transparent than typical tool descriptions.
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 front-loaded: the first sentence states the core purpose, followed by key behavioral and safety constraints. Every sentence adds essential information with no fluff.
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 tool has an output schema, so return values are already specified. The description nonetheless explains the semantics of its conclusion ('in_use', 'free', 'inconclusive') and error cases, making it complete for an IP availability check. Minor gaps like parameter format do not undermine overall contextual completeness.
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 explains that 'ip' must be inside the profile's configured networks and within permitted_networks, and that 'profile' determines the network configuration. However, it does not specify the IP address format (IPv4 vs IPv6) or the behavior when 'profile' is null, leaving ambiguity.
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 checks whether an address is in use within the profile's configured networks. The verb 'check' and resource 'IP availability' are explicit, and the tool is distinct from all sibling tools, which focus on guests, nodes, storage, etc.
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: read-only, idempotent, refuses addresses outside permitted_networks, and raises ProfileError when no network is configured. These constraints effectively tell when the tool will succeed or fail, but it does not explicitly name alternative tools or state when to prefer them.
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?
Despite lacking annotations, the description discloses important behavioral traits: it is read-only and idempotent, explicitly states what fields are returned, clarifies that secrets are never included, and describes error handling for unknown vmid and unreadable configs. This significantly exceeds basic expectations.
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 compact and information-dense, with three sentences each serving a purpose: defining scope, listing return fields and exclusions, and describing error behavior. No redundant wording or unnecessary details are present.
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 output schema exists, the description need not enumerate return fields, but it does anyway, adding value. It covers return content, exclusions, error conditions, and partial result behavior, making it fully sufficient for an agent to use correctly.
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 schema has 0% description coverage, so the description must compensate. It clarifies the roles of 'node' and 'vmid' through natural language, but the optional 'profile' parameter is not explained at all. This partial coverage merits a mid-range score.
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 retrieves a single guest's configuration on a specified node. It distinguishes itself from sibling list tools by emphasizing 'one guest' and listing specific configuration fields returned, making the purpose unmistakable.
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 that this tool is for retrieving a detailed configuration of a single guest on a specific node, implying it is not for listing or status checks. However, it does not explicitly name alternatives like list_guests or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and exceeds expectations. It states 'Read-only and idempotent' and then provides a detailed, nuanced explanation of four absence scenarios, including how docker_available and partial differentiate them. This level of behavioral disclosure is exceptional and prevents misinterpretation of edge cases.
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 dense but every sentence earns its place. It is front-loaded with the core purpose, then lists output fields, then explicitly states exclusions, and finally explains edge cases in a structured, logical progression. The length is justified by the complexity of the behavior being described, and there is no 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?
Given the tool's complexity and the presence of an output schema (which handles return values), the description is remarkably complete. It covers the purpose, the output fields, what is deliberately omitted, and the full semantics of failure/absence cases. The only minor gap is the undefined 'profile' parameter, but overall context for agent decision-making is exceptional.
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 implicitly defines 'node' (the node named) and 'vmid' (the LXC guest) through the opening sentence. However, it does not mention the 'profile' parameter at all, and with 0% schema description coverage, the description must compensate but fails to explain this optional parameter. This is a notable gap, though the two primary parameters are clear.
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 identifies the tool's purpose: listing Docker containers inside a specific LXC guest on a named node. It uses a specific verb ('list') and resource ('Docker containers ... inside one LXC guest'), and the scope is precise ('exactly the node named'). This distinguishes it from sibling tools like list_guests, which list guests themselves, and inspect_compose_stack, which inspects compose stacks.
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 this tool is appropriate: when you need container-level details within a particular LXC guest on a specific node. It does not explicitly name alternatives or say 'use X instead', but it clarifies what the tool does not return (env vars, labels, command lines) and explains the meaning of docker_available and partial, helping an agent decide if this tool fits. However, it stops short of explicit when-to-use vs. alternatives.
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 fully discloses behavioral traits: read-only and idempotent, stopped guests included, empty results on no match, and handling of unknown guests with partial markers. This goes well beyond structured fields and gives the agent critical expectations.
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: the first sentence states the core purpose, and each subsequent sentence adds a distinct behavioral detail. No filler or repetition. It is concise yet comprehensive.
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 has 4 optional parameters and an output schema, the description covers important edge cases (stopped, empty, unknown) and explicitly notes partial results. It is complete for a list operation and sufficiently rich despite the absence of annotations.
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 mentions 'filtered subset' and the behavior of filters that match nothing, but does not explain each parameter's meaning (node, status, profile, guest_type) beyond what the schema already shows. The schema's enums help, but the description falls short of fully documenting parameter semantics.
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 lists every LXC and VM in the cluster, with optional filtering. It distinguishes from siblings like list_guest_containers by explicitly naming both LXC and VM guest types. The verb 'list' and specific resource are immediately clear.
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 useful context for when to use this tool, such as the inclusion of stopped guests and the read-only/idempotent nature. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a full exclusionary guideline.
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 read-only and idempotent behavior, the empty-list edge case with the 'current' pseudo-entry, and the node/vmid binding safety property. Since no annotations are provided, this thorough behavioral context fully carries the transparency burden.
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?
Three concise sentences, each with a distinct purpose: defining the operation, describing the empty-list edge case, and explaining the safety binding. No unnecessary words.
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 edge cases, idempotency, and safety properties. With an output schema present, return values need not be described. It is complete for a simple read-only listing 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?
It adds meaning to node and vmid by explaining they are bound together, and 'exactly one guest' implies vmid identifies the guest. However, the profile parameter is not mentioned at all, and with 0% schema coverage, this partial compensation leaves a gap.
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 lists snapshots for exactly one guest, with specific fields (parent, description, timestamp, RAM state). This distinguishes it from sibling tools like list_guests and get_guest_status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'exactly one guest' provides clear context for when to use the tool. However, it does not explicitly name alternative tools or describe when not to use it, so it stops short of full 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, the description carries the full behavioral burden. It discloses read-only and idempotent nature, explains the meaning of an empty concerns list, differentiates three non-error states (guest not running, no Docker, no backup), describes partial results and warnings, and specifies error behavior for unknown vmid. This is thorough and goes beyond a simple action.
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 long but every sentence adds value: purpose, read-only assurance, what is combined, usage guidance, concerns semantics, edge cases, and error handling. It is front-loaded with the main purpose and structured logically, making it easy to process.
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 fully covers purpose, usage, behavioral nuances, and edge cases, while the presence of an output schema means return value format doesn't need to be in prose. It answers likely agent questions about when to use, what to expect, and how failures are handled, making it complete for a tool of this complexity.
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 schema has 0% description coverage, so the description should compensate. It implicitly references 'node' and 'vmid' in context ('on exactly the node named', 'a vmid the cluster does not report...'), but does not explicitly define them or their formats. The 'profile' parameter is never mentioned, leaving its purpose entirely undocumented. This is a clear gap for a 3-parameter tool.
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 is a consolidated read of a guest on a given node, combining multiple health dimensions. It explicitly distinguishes itself from sibling tools like get_guest_status, list_snapshots, list_backups, and list_guest_containers by saying 'Prefer this over calling... separately'.
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?
The description gives explicit when-to-use guidance: 'Prefer this over calling get_guest_status, list_snapshots, list_backups, and list_guest_containers separately when the question is "how is this guest doing"'. This directly names alternatives and provides a selection criterion.
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 does so excellently. It discloses read-only and idempotent behavior, the aggregation algorithm when `node` is omitted, and the partial-failure handling (warning + 'partial' instead of a full exception). This is rich behavioral detail beyond what annotations would typically provide.
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 three sentences, each earning its place: purpose, parameter behavior, and failure semantics. It is front-loaded with the core purpose and avoids any redundant wording. Perfect balance of completeness and brevity.
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 tool has two optional parameters and a nuanced aggregation behavior; the description covers these thoroughly, including edge cases like node fallback and per-storage partial failures. An output schema exists to document return values, so the absence of field-level detail in the description is appropriate. No critical information is missing for correct 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 input schema offers no descriptions for `node` or `profile`, and schema coverage is 0%. The description significantly compensates by thoroughly explaining the `node` parameter's effect on output and data source, and it references 'profile' in the context of cluster-wide behavior. However, the `profile` parameter itself remains somewhat undefined, so it adds strong but not complete semantic coverage.
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 first sentence clearly identifies the resource ('storage entries') and the output scope ('per-node status and a cluster-wide aggregate'), which distinguishes it from sibling tools focused on guests, nodes, and backups. Though it lacks an explicit verb, the tool name 'list_storage' and the noun phrase make the listing 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 provides clear context on when to use the `node` parameter (restrict to one node) versus omitting it (cluster-wide with a fallback), effectively guiding usage. It does not explicitly name alternative tools or when not to use this one, but the read-only and idempotent nature implies appropriate scenarios.
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:

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

Score Badge

Copy to your README.md:

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

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/edymol/proxmox-mcp'

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