Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds a useful behavioral nuance by noting the tool is also useful on standalone nodes, going beyond the annotations without contradicting them.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One concise, information-dense sentence. It puts the core purpose first and adds the standalone-node note without any fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With zero parameters, rich annotations, and an output schema present, the description provides everything needed to select and invoke this tool. The standalone-node note adds helpful context beyond the minimally required summary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no parameter semantics burden on the description. The input schema confirms the absence of parameters, and the description appropriately says nothing about arguments.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: retrieving cluster quorum and member status. It doesn't explicitly distinguish this from sibling tools like get_node_status or list_nodes, but the resource scope is specific enough for an agent to infer its purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context: use this tool to get cluster quorum and member status, and it also applies to standalone nodes. It doesn't name alternatives or when-not-to-use conditions, but for a zero-parameter read-only tool the context is adequate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already convey readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond annotations by clarifying that omitted fields are not unset, which can prevent a costly misunderstanding for an agent reading a partial configuration summary.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, tight sentence. The primary action is front-loaded, and the important behavioral caveat ('omitted fields are not unset') is appended without verbosity. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with a full output schema and safety annotations, the description is reasonably complete. The main gap is the lack of any usage context or alternate-tool guidance, but the core behavior and non-destructive nature are adequately conveyed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description needs to compensate by explaining parameters, but it does not mention node, vmid, or guest_type at all. The parameter names and enum are somewhat self-explanatory, but no additional semantic meaning is provided beyond the schema itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Read') and resource ('allowlisted configuration summary'), which clearly distinguishes this from sibling tools like get_guest_status or list_guests. However, the term 'allowlisted' is not explained, leaving some ambiguity about what exactly is included or excluded.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 such as get_guest_status or list_guests. There is no mention of prerequisites, when a configuration summary is appropriate, or when another tool should be preferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safe/read-only profile is covered. The description adds what is being read (power state, current resource usage) but reveals no additional behavioral traits such as authentication requirements, freshness guarantees, or failure behavior. It does not contradict the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence that states the operation and the data returned with no wasted words. The short length is appropriate for a read-only status tool with an output schema and annotations.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple status-read tool, the description plus the readOnly/idempotent annotations and existing output schema cover the essential context. The main gaps are the lack of explicit parameter semantics and sibling routing, but they do not make the tool unusable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 compensate by explaining node, vmid, or guest_type; it only refers generically to 'a guest'. The property names and constraints carry some meaning, but an agent gets no help on how the three required parameters relate to the operation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') and resource ('a guest'), and names the exact data returned: power state and current resource usage. This distinguishes it from siblings like get_guest_config (configuration) and list_guests (enumerating guests).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 single guest's live state or resource usage is needed—but it gives no explicit exclusions or pointers to alternatives such as get_guest_config or list_guests. The context is clear but the guidance is implicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds crucial behavioral context beyond those annotations by explicitly warning that the ID is not reserved and that concurrent users may claim it. This is valuable information that affects how an agent should use the result.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences deliver complete and essential information with no fluff. The primary purpose is front-loaded, followed by the key caveat. Every word earns its place, 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter read-only utility with an output schema present, the description is fully complete. It states the core function and the one behavioral nuance that could change how the result is used. Nothing necessary for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so there is no parameter semantics to elaborate on. The baseline of 4 applies, and the description does not need to add parameter-level details. It does not waste space describing nonexistent inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Find') and resource ('an available VM ID'), making the tool's function immediately clear. It also adds the distinguishing caveat that the ID is not reserved, which differentiates it from any reservation or creation tool. The scope is unambiguous and distinct from sibling tools like list_guests or get_cluster_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not state when to use this tool versus alternatives. It does not mention that the tool should be used before creating a VM or that it complements creation workflows. It also gives no guidance on what to do after obtaining the ID. The only contextual hint is the reservation caveat, which is more behavioral than usage-oriented.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds the concrete set of returned metrics but no additional behavioral context such as units, timing, failure modes, or permissions. It is adequate but not exceptional.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler. Every word contributes to what the tool returns, making it easy to scan during tool selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, one-parameter read-only status tool with an output schema and strong safety annotations, the description provides enough information to select and invoke the tool correctly. Return values are presumably covered by the output schema, so no critical detail is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single required parameter 'node' is referenced by the description, and the schema's name and regex pattern make the expected value fairly obvious. However, schema description coverage is 0% and the description does not explain the node format or that it is required, so it only partially compensates.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Uses a specific verb and resource: 'Get a node's CPU, memory, swap, load, and uptime.' This clearly identifies the tool's scope and differentiates it from sibling tools like get_cluster_status and get_guest_status by focusing on node-level metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for retrieving node resource metrics, so an agent can infer when to call it. However, it does not explicitly state when not to use it or name alternatives, leaving usage guidance implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds valuable context beyond annotations by specifying the exact completion condition (status=stopped and exitstatus=OK), which is important for polling loops and success determination.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core action and immediately states the critical success condition. There is no redundant wording or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values do not need explanation. Combined with rich annotations and a clear success condition, the description is nearly complete for a simple read-only polling tool. The main gap is parameter semantics, but that is already reflected in that dimension.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It does not explain what 'node' or 'upid' mean or how they identify a task, though the schema titles and patterns offer partial hints. The description adds minimal parameter-level meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Poll a task') and a precise resource ('task'), with a clear completion condition. It is distinguishable from sibling tools like list_tasks or get_guest_status because it focuses on polling a single task's status and defines success criteria.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies polling a task is the use case, but it does not explicitly state when to use this tool versus siblings like list_tasks or get_guest_status. No alternatives or exclusion criteria are mentioned, leaving some inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the 'connected Proxmox VE' scope, clarifying that this returns the version of the currently attached environment. There is no hidden behavioral complexity to disclose for a zero-parameter getter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, information-dense sentence with no filler. The key action and target resource are front-loaded, and every word contributes to understanding the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter, read-only, idempotent getter with an output schema, the description is fully sufficient. The annotations cover safety, the output schema covers return structure, and siblings provide enough context to avoid confusion.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the baseline is 4. The description adds meaning about what the returned version represents (the connected Proxmox VE instance) without needing parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('Get') tied to a clear resource ('connected Proxmox VE version and release'). It is immediately distinguishable from all sibling tools, which are about cluster status, resources, nodes, storage, guests, snapshots, tasks, etc.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use this tool when you need the Proxmox VE version and release of the connected environment. No exclusions or alternatives are needed because none of the sibling tools serve this purpose and there are no parameters or conditions to disambiguate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description aligns with these annotations by saying 'List', but adds no extra behavioral detail beyond the node-scope context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The entire description is one focused sentence with no filler. Every word contributes to understanding the tool's purpose and scope.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only listing tool with only two required parameters, an output schema, and safety annotations, the description is sufficiently complete. The only notable omission is explicit sibling differentiation, which is more of a usage-guideline concern than a completeness gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 0% schema description coverage, the description partially compensates: 'QEMU virtual machines or LXC containers' maps to the guest_type enum values, and 'on one node' clarifies the node parameter. However, it adds no detail about node constraints or how guest_type values map beyond what the schema's enum already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('List'), specific resource types ('QEMU virtual machines or LXC containers'), and a clear scope ('on one node'). This distinguishes it from broader sibling tools like list_resources and list_nodes without ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'on one node' implies this tool is for per-node guest listing, but the description does not explicitly mention when to prefer it over alternatives such as list_resources or get_guest_status. Usage context is implied rather than clearly stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the specific output fields (uptime, CPU, memory usage) beyond the annotations, but does not disclose other behavioral traits like pagination, ordering, or limits. Given the annotations cover the main behavioral concerns, a score of 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that front-loads the verb and resource, then lists the specific fields. There is no waste or repetition; every word contributes to clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with no parameters and an existing output schema, the description is sufficient to understand its purpose. It does not explicitly say 'all nodes' but that is implied. The presence of an output schema means return values are documented elsewhere, so the description does not need to elaborate on them. The description is complete enough for an agent to call the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema is fully covered (100%) and there is nothing to explain. The baseline for zero parameters is 4, and the description adds no unnecessary parameter information, which is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and resource ('nodes'), and explicitly names the returned metrics (uptime, CPU, memory usage). This clearly distinguishes it from siblings like list_resources or list_storage, leaving no ambiguity about what the tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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 such as get_node_status or list_resources. It does not mention any exclusions, prerequisites, or conditions that would help an agent choose this tool over others. The usage is implied but not stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: results are filtered by the token's visibility and 'vm' includes both QEMU and LXC. These are consistent with the annotations and add value, but no further behavioral details 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the main action and scope, then adds a useful clarification about the vm type. There is no filler or redundant text; every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one optional parameter, annotations cover the safety profile, and an output schema exists. The description communicates the token-scoped visibility and resolves ambiguity in the vm type. The main gap is not stating the default behavior when resource_type is omitted, but the overall definition is adequate 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden for explaining resource_type. It clarifies the 'vm' value but leaves 'storage', 'node', 'pool', and 'sdn' semantically undefined. It also does not explain what happens when resource_type is null (the default), which is important for correct invocation. The agent must rely on enum names and inference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('List'), a specific resource ('cluster resources'), and a scope qualifier ('visible to this token'). It also clarifies the 'vm' resource type by noting it includes QEMU and LXC. It does not explicitly contrast itself with sibling tools like list_nodes or list_storage, but it is clear enough that an agent can understand the core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context about token-scoped visibility, which implies the tool respects permissions. However, it gives no explicit guidance on when to use this tool versus the more specific sibling tools (list_guests, list_storage, list_nodes), nor does it say when not to use it. Usage is only implied by the generic resource_type parameter.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, covering safety and idempotency. The description adds the detail about 'parent relationships,' giving a hint about the output structure. No other behavioral traits like pagination or ordering are mentioned, but given the annotations, this is acceptable.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with zero wasted words. The action is front-loaded, and the description is appropriately brief for a simple listing tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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 covered elsewhere. The description is minimal but sufficient for a straightforward listing operation. However, the parameters are not explained at all, and with 0% schema description coverage, an agent might be uncertain about parameter semantics. The description could be more helpful by clarifying parameters or the meaning of 'parent relationships.'

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 any parameters. The schema provides types, a pattern for node, min/max for vmid, and an enum for guest_type, but the description adds no additional meaning. It doesn't clarify that vmid is the guest ID or that guest_type selects between QEMU and LXC. With 0% coverage, the description should compensate but fails to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'List' and the resource 'guest snapshots' with an additional detail about 'parent relationships.' This distinguishes it from sibling tools like list_guests and list_storage_content, though it doesn't explicitly name them. The purpose is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description offers no explicit guidance on when to use this tool versus alternatives. It implies usage for snapshot listing, but lacks any when-to-use or when-not-to-use statements. For a listing tool, this is adequate but could be improved by noting it requires a specific guest and is for snapshot management.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat safety traits. The description adds the node scope but that is already evident from the parameter. It does not disclose additional behaviors like rate limits or response format specifics, so it meets the baseline for annotation-covered tools.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no redundant words. It is front-loaded with the action and resource, making it efficient for an agent to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with one parameter and an output schema, so the description is nearly adequate. However, it lacks usage guidance and does not clarify what 'availability and capacity' means precisely (e.g., disk space vs. storage pools). This leaves minor gaps for an agent, but the output schema likely fills in return details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 'node' parameter. It says 'on a node', which clarifies the parameter's role as the target, but it does not explain what constitutes a node or any constraints beyond the schema's pattern. This is minimal added value over the parameter name itself.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action 'list' and the resource 'storage' scoped to 'a node'. It is specific enough to distinguish from sibling tools like list_storage_content, though it does not explicitly differentiate. The phrase 'availability and capacity' is somewhat ambiguous but still conveys the core purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given on when to use this tool versus alternatives such as list_storage_content or list_nodes. There are no mentions of conditions, prerequisites, or exclusions, leaving the agent to infer usage.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds no additional behavioral details beyond listing, which is acceptable given the annotations, but it also does not enrich behavioral understanding further.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single, front-loaded sentence with no filler. Every phrase adds meaning, and the core action and resource are stated immediately.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is a read-only list operation with annotations and an output schema, so return value details are not needed. The description is sufficient for basic invocation, though it could briefly clarify the role of the node parameter or mention sibling tool list_storage for contrast.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 does map the content parameter to human-readable categories ('volumes, backups, ISOs, container templates'), but it leaves the required node and storage parameters unexplained. Parameter names help, but the description only partially covers the parameter space.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and identifies a clear resource: volumes, backups, ISOs, or container templates within a storage. This makes the tool's purpose immediately distinguishable from siblings like list_storage or list_nodes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context for when to use the tool: to enumerate storage contents of various types. It does not name alternative tools or provide exclusion criteria, but the intended use case is evident from the wording.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark it read-only and non-destructive, so the description only needs to add behavior on top. It adds 'recent' and pagination, but doesn't disclose ordering, time-window semantics, or whether tasks of all statuses are included. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the core operation and appends the only usage hint needed. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Annotations, input constraints, and an output schema cover safety, bounds, and return shape. The description completes the picture with recency and pagination, though 'recent' is left somewhat vague and the sibling get_task_status is not mentioned.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parameter descriptions in the schema, the description must compensate. It does give start and limit a clear purpose (pagination), but it leaves 'node' to be inferred and doesn't define what start represents (offset). This is adequate but not thorough.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

'List recent node tasks' names a specific action and resource, and the 'recent' qualifier narrows the scope. It is clearly a list operation rather than a status lookup, but it doesn't explicitly contrast with get_task_status or list_nodes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The pagination hint ('use start and limit') is useful operational guidance, but there is no statement about when to choose this over get_task_status or when it should not be used. Sibling differentiation is left to the agent's inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.