longhorn-mcp

Server Quality Checklist

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

Latest release: v0.1.6
Disambiguation2/5
Several tools are near-duplicates or have unclear boundaries: volume_snapshot_create is explicitly equivalent to volume_snapshot_cr_create, and volume_snapshot_list/get overlap with snapshot_list/get while backupvolume_backup_* overlaps with backup_*. The many similarly named resources (backup, backupvolume, backupbackingimage, backuptarget) make selection error-prone despite good per-tool descriptions.
Naming Consistency4/5
Most tools follow a readable resource_verb pattern (backuptarget_create, volume_snapshot_delete, recurringjob_list). There are notable deviations like longhorn_list_tags, longhorn_events, volume_update_setting, and backuptarget_update_name, but they are a minority and the overall convention remains recognizable.
Tool Count1/5
At 103 tools, the surface is enormous and far beyond what an agent can efficiently scan; this is an extreme count, not just slightly heavy. Even though Longhorn is a complex system, exposing nearly every resource and action as a separate MCP tool creates an overwhelming selection problem.
Completeness4/5
The tool set covers nearly all major Longhorn resources—volumes, snapshots, backups, backup targets, nodes, settings, recurring jobs, system backup/restore, and backing images—with CRUD and lifecycle actions. Some gaps exist (e.g., no dedicated backup restore to volume or support-bundle generation), but they are minor and workable, especially with longhorn_raw_request as an escape hatch.
Average 3.7/5 across 100 of 103 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 30 commits in the last 12 weeks
- Last stable release on August 14, 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 bears the full burden of disclosing operational behavior. It does not explain whether the volume must be attached, whether trimming is disruptive, or what side effects occur; 'trim the filesystem' leaves these details to inference.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief, but the first sentence merely restates the title and the second is only a link. The wording is concise but not substantive; the limited space could have been better used for operational details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and a one-sentence description plus a link, the definition omits crucial context for a filesystem-trim operation. The external link may help a human, but an AI agent needs the key information inline.
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 single parameter 'name' has no schema description (0% coverage), and the tool description does not define it. An agent might infer it refers to the volume name from the context, but the description fails to explicitly state the parameter's meaning, format, or requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource, 'Trim the filesystem on a volume,' which clearly identifies the operation. However, this essentially restates the tool's title and provides no differentiation from sibling volume-management tools like volume_attach or volume_snapshot_purge.
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?
There is no guidance on when to use this tool versus alternatives, nor any mention of preconditions, exclusions, or when trimming is appropriate. The only extra is an external documentation link, which does not substitute for explicit usage instructions.
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 present, the description carries the full behavioral disclosure burden. It does indicate a 'Force' resync operation, which hints at non-idempotent or state-changing behavior, but it does not state side effects, permissions required, reversibility, or whether existing backup state is replaced or merged.
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 terse and front-loaded with the action, followed by a documentation link. It contains no filler or redundant phrasing, though its brevity does sacrifice explanatory richness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five undocumented parameters, no annotations, no output schema, and many related siblings, this description is far from complete. An agent cannot determine how to set the boolean flags, what values name expects, or when this tool is the right choice over backupvolume_sync.
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?
Schema description coverage is 0%, and the description does not explain any of the five parameters. The boolean flags syncBackupTarget, syncBackupVolume, syncAllBackupTargets, and syncAllBackupVolumes, as well as the required name field, are left completely ambiguous, so the description adds no semantic value beyond the raw 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 a specific action ('Force Longhorn to resync') and the resource ('backup target/backup volume state'), so the core purpose is identifiable. It loses the top score because sibling tools like backupvolume_sync exist and the description does not explicitly distinguish the two.
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 gives essentially no guidance on when to invoke this tool versus alternatives such as backupvolume_sync or backuptarget_update. The word 'Force' implies a troubleshooting or resync scenario, but there are no explicit conditions, prerequisites, or exclusion notes.
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 only says 'Create' and provides a docs link; it does not mention idempotency, duplicate-name behavior, validation requirements, permissions, or side effects of creating a recurring job.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, with no filler, and the docs link is a useful pointer. However, for an 8-parameter creation tool, the terseness borders on under-specification rather than disciplined conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, nested objects, and 5 required parameters, the description is not complete enough for reliable invocation. The external docs link helps, but the MCP description itself leaves essential behavioral and parameter context unexplained.
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?
Schema description coverage is only 25%, covering cron and task, while required fields like name, retain, and concurrency plus optional groups, labels, and parameters are left unexplained. The description adds no parameter-level meaning and does not compensate for the low schema coverage.
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 uses a clear verb-resource pair ('Create a new Longhorn recurring job') and names the domain-specific resource, which distinguishes it from list/get/update/delete siblings. It does not articulate scope or nuances beyond creation, but the core purpose is unambiguous.
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 about when to call this tool versus alternatives such as recurringjob_update or volume_recurring_job_add. The description does not mention prerequisites, typical workflow steps, or exclusions, leaving the agent to infer usage from the sibling 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?
No annotations are provided, so the description must disclose behavioral traits itself. It only says 'Activate' without explaining side effects, whether the DR volume becomes read-write, whether replication to the standby is stopped, whether the operation is reversible, or what prerequisites must exist. This is a mutating state change, so the lack of behavioral detail 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 concise and front-loaded, with a useful documentation link appended. It earns credit for being easy to scan, though its brevity contributes to the lack of semantic coverage in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-changing operation with no annotations, no output schema, and two undocumented parameters, the inline description is too sparse to fully support correct invocation. The docs link is a helpful reference, but the description alone does not convey prerequisites, parameter meanings, or behavioral consequences.
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?
Schema description coverage is 0%, so the description must compensate for the bare schema, which only lists 'name' and 'frontend' as strings. The description does not explain that 'name' identifies the standby volume or what values 'frontend' accepts, leaving the agent without enough information to invoke the tool correctly.
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 states a specific action ('Activate') on a specific resource ('standby (DR) volume'), which is more precise than the title and suggests a distinct operation from ordinary volume attach. However, it does not explicitly differentiate itself from sibling tools like volume_attach or clarify the failover context beyond the DR term.
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?
There is no explicit guidance on when to use this tool versus alternatives such as volume_attach or volume_detach. The phrase 'standby (DR) volume' implies the intended scenario, and the Longhorn docs link may help, but the description itself provides no prerequisites, conditions, 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?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It states the core action (creating a PV) but does not disclose side effects, conflict behavior if the PV already exists, whether the operation is idempotent, or any volume-state requirements. For a state-changing tool with zero annotation coverage, this is a meaningful 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 appropriately brief: one sentence stating the action plus a documentation link. The core purpose is front-loaded and there is no filler. The doc link is a reasonable addition, though it partly substitutes for missing behavioral and parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a creation tool with 6 parameters, no annotations, and no output schema, this description is under-specified. It does not explain the name/pvName relationship, conflict semantics, prerequisites, or operation consequences. The documentation link is the only concession to completeness and shifts the burden onto the agent to fetch external context.
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?
Schema description coverage is 0% across 6 parameters, and the description offers no parameter-level clarification. Critically, the distinction between 'name' and 'pvName' is ambiguous — the description's phrase 'backed by this Longhorn volume' only weakly hints that 'name' refers to the volume while 'pvName' refers to the PV. fsType, secretName, secretNamespace, and storageClassName are entirely unexplained, and the description does nothing to compensate.
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 uses a specific verb and resource: 'Create a Kubernetes PersistentVolume backed by this Longhorn volume.' This clearly indicates the tool provisions a PV object and implicitly distinguishes it from the sibling volume_pvc_create, which provisions a PVC. However, it never names that sibling or the distinction explicitly, so the differentiation is left to the reader.
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?
There is no guidance on when to use this tool versus alternatives such as volume_pvc_create or volume_snapshot_cr_create. No prerequisites (e.g., volume state, cluster permissions) are mentioned, and the documentation link is a passive reference rather than actionable routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral disclosure burden. It only repeats that a snapshot is created; it does not state whether the volume must already exist, whether creation is synchronous, what side effects occur, or what the response contains. This is slightly better than a pure tautology but still lacks meaningful behavioral 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 one short, front-loaded sentence with a supporting docs link. There is no wasted wording, and the core purpose appears immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no annotations, no output schema, and no parameter descriptions, this description is far from complete. It does not explain how to invoke the tool correctly, what 'name' refers to, or what the operation returns. The external docs link is not a substitute for inline tool definition context.
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?
Schema description coverage is 0% and the description adds no parameter meaning. The required 'name' property is ambiguous—it is not clarified whether it is a volume name or snapshot name—and labels, backupMode, and snapshotName are left entirely unexplained.
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 and resource: 'Create a snapshot of a volume.' This is specific enough to distinguish it from list/get/delete/revert snapshot tools, but it does not explicitly contrast it with sibling tools such as volume_snapshot_backup or volume_snapshot_cr_create.
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 usage guidance is provided. The description does not say when to use this tool instead of volume_snapshot_backup, volume_snapshot_cr_create, or snapshot_list, and it gives no prerequisites, exclusions, or context about the target volume. A docs URL is referenced but not integrated into actionable guidance.
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, but it only restates the operation without explaining effects, prerequisites, idempotency, or potential disruptions. The docs link is useful but does not itself disclose the behavioral traits needed to call the tool safely.
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 a single clear sentence followed by a relevant docs link. It is front-loaded and free of filler, though it omits behavioral and parameter details that would increase usefulness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters, no output schema, no annotations, and minimal schema descriptions, the description is not complete enough for an agent to call this reliably. It fails to clarify what 'name' refers to, what the attachment means operationally, or what consequences may occur, making the docs link a partial patch rather than a full remedy.
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 only 17%, with just hostId documented as 'Node name to attach to,' and the description adds no parameter-level clarification. The six parameters include likely important fields like name and disableFrontend that are left unexplained, so the description does not compensate for the schema's low coverage.
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 states a clear action ('Attach a volume to a node') with a specific verb and resource. It does not explicitly distinguish this from siblings like volume_detach, but the action is unambiguous. A short docs link adds a reference point without confusing 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.
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 such as volume_detach, volume_activate, or volume_engine_upgrade. There is no mention of prerequisites, common scenarios, or exclusions, leaving the agent to infer usage from the name 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 the full burden of behavioral disclosure, but 'Create a new Longhorn volume' only restates the operation implied by the tool name. It does not disclose whether creation is asynchronous, whether a duplicate name causes an error, what side effects occur, or how the agent can confirm the volume is ready. The documentation link partially mitigates this, but the description itself adds no behavioral context beyond the name.
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?
Two sentences with zero filler: the purpose statement is front-loaded and the documentation reference is appended where it belongs. Every word earns its place, and the doc link is a high-value addition rather than noise. It is not a 5 because it is so thin that it borders on under-specification for a 12-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity — 12 parameters, 3 required, a nested 'extra' merge object, no output schema, and no annotations — a two-sentence description is insufficient for an agent to call the tool correctly or interpret the result. The description does not clarify the expected return value, the merge semantics of 'extra', or the conditions under which creation fails or succeeds.
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 only 42%, leaving 7 of 12 parameters (name, backingImage, dataLocality, diskSelector, nodeSelector, numberOfReplicas, staleReplicaTimeout) undocumented, and the description does nothing to compensate — it mentions no parameters at all. The schema itself covers size, extra, frontend, accessMode, and fromBackup, but the description's job of filling the coverage gaps is entirely unmet.
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 states a specific verb and resource — 'Create a new Longhorn volume' — naming the exact external system and item type, which distinguishes it from the many sibling operations like volume_list, volume_get, volume_delete, and the snapshot/backup creation tools. It adds 'new' and 'Longhorn' beyond the title, confirming it creates a fresh volume rather than a derived artifact. It stops short of 5 because it doesn't explicitly contrast with related creation tools such as volume_snapshot_create or volume_pv_create.
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?
There is no statement about when to use this tool versus alternatives, no exclusions, and no mention of prerequisites such as a healthy cluster or sufficient storage. The only usage signal is the verb 'create' plus an external documentation link that the agent must fetch to learn anything further. No guidance is given for when volume_create is the wrong choice.
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, yet it only names the action. It fails to reveal that expansion is an asynchronous/cancelable operation (evidenced by the volume_cancel_expansion sibling), that shrinking is not supported, or that a filesystem resize may be needed afterward.
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?
A single scannable sentence with the action front-loaded and a relevant docs link appended. There is zero filler; it could carry more detail without becoming verbose, but structurally it is clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating 2-param tool with no annotations, no output schema, and no parameter descriptions, one sentence is inadequate. Missing context includes size units, the cannot-shrink constraint, the cancelable async nature, and prerequisites. The docs link partially compensates but the definition is not self-sufficient.
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 both parameters, but it only loosely maps 'size' to 'new size' and leaves 'name' to be guessed as the volume identifier. It does not specify the size string format, units (e.g., Gi), or that the value must exceed the current size — all essential for a correct invocation.
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 states a specific verb ('expand') applied to a clear resource ('a volume') with a concrete outcome ('to a new size'). This distinguishes it from most siblings like volume_create or volume_update_setting, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It omits prerequisites (volume must exist, attachment state), the constraint that size can only grow, and when the sibling volume_cancel_expansion would apply. The agent must infer usage entirely from the tool name.
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 reveals the mechanism (CRD-backed) but does not mention side effects, prerequisites, reversibility, idempotency, or what happens on failure. The equivalence claim gives no detail about behavioral differences from the non-CRD path.
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, front-loaded sentence with no filler, and the documentation link is useful supporting context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, plus three parameters with nested labels, this definition is too thin. It omits required parameter meaning, behavioral results, and any distinction from the equivalent sibling, making it inadequate for safe invocation.
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?
Schema description coverage is 0% and the description adds no meaning for the three parameters. The required `name` is ambiguous: it could be the volume name or the VolumeSnapshot CR name, especially since `snapshotName` is an optional separate field. The agent cannot infer correct values from either schema or description.
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 states a clear verb and resource: create a snapshot via the VolumeSnapshot CRD-backed action. However, it undermines distinction from the sibling volume_snapshot_create by calling the two 'equivalent', leaving the agent unsure how this tool differs operationally.
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?
It names volume_snapshot_create as an equivalent alternative but provides no guidance on when to choose one over the other. The word 'newer' weakly implies a preference, but there is no explicit condition or exclusion to guide 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?
With no annotations, the description carries the full burden of disclosing behavior. It only restates the listing action and scoping, without confirming read-only status, return format, pagination, or potential side effects. The agent cannot infer the output structure or safety profile.
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 one sentence plus a documentation link. The action and scope are front-loaded with no redundant wording, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema and no annotations, the description is thin. It omits parameter disambiguation, return value details, and behavioral guarantees. The external docs link partly compensates, but the description alone is not self-sufficient for correct tool selection and invocation.
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 the lone 'name' parameter. 'Scoped by the source volume' hints at the parameter's role, but it remains ambiguous whether 'name' is the backup volume name or the source volume name. No format, examples, or constraints are given.
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 states a specific verb and resource ('List backups for a backup volume') and adds a scoping constraint ('scoped by the source volume'), which helps distinguish it from generic backup listing. However, it does not explicitly differentiate itself from near-sibling backupvolume_backup_list, and the phrase 'backup volume' vs 'source volume' leaves slight ambiguity.
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 about when to use this tool over alternatives such as backupvolume_backup_list or backup_list. There are no exclusion criteria or decision rules; the docs link is a general reference, not a usage directive.
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 disclose side effects such as whether an existing backing image is overwritten, whether authentication (e.g., 'secret') is required, or what runtime behavior results. The description only states the operation and links to documentation, leaving these behavioral traits undisclosed.
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 one concise sentence plus a documentation link, with no filler or repetition. It front-loads the core action and resource, though it sacrifices necessary parameter detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With four undocumented parameters, no output schema, and no annotations, the description is too sparse for an agent to call the tool confidently. The documentation link is useful but does not provide the needed inline context about parameter semantics, return values, or behavioral effects.
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 any of the four parameters ('name', 'secret', 'dataEngine', 'secretNamespace'). The phrase 'backup target' gives minimal context for the operation but not enough to know what each parameter means or how to set them.
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 states a clear action ('Restore') on a specific resource ('backing image') from a defined source ('backup target'), making the tool's function unambiguous. It does not explicitly differentiate from sibling tools, but no other restore tool appears among the siblings, so the purpose is sufficiently distinct.
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 when restoring a backing image from a backup target, but it provides no explicit when-to-use, when-not-to-use, or alternative tool guidance. It does not mention related operations like creating or uploading backing images, leaving usage to be inferred from the wording 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?
There are no annotations, so the description must carry the behavioral disclosure. It mentions 'Force a resync' but does not describe side effects, idempotency, prerequisites, or consequences of forcing the resync. The external docs link is helpful but does not compensate for the missing behavior details in the description itself.
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 with no wasted words. The action is front-loaded and the docs link is the only extra element, making it appropriately concise and 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?
For a one-parameter tool with no output schema and no annotations, the description is minimally viable: it identifies the action and resource. However, it lacks explicit parameter semantics, usage guidance, and behavioral context, leaving clear gaps in how an agent should select and invoke the tool.
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 schema has one required 'name' parameter with no description, and schema description coverage is 0%. The description mentions 'a backup volume' but never explicitly states that 'name' is the backup volume name, forcing the agent to infer the parameter's meaning.
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 states a specific action, 'Force a resync,' with a clear resource, 'backup volume against the backup target.' It is clear about what the tool does, though it does not explicitly call out how it differs from siblings like backuptarget_sync.
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 usage guidance is provided. The description does not say when to use this tool, when not to use it, or mention any alternatives. The docs link is a reference, not selection guidance.
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 behavioral disclosure, but it only says 'Attach.' It does not mention side effects, whether this is a mutating operation, whether existing attachments are replaced, permission requirements, or what happens to attached schedules.
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?
One concise, front-loaded sentence with a useful documentation link. It is efficiently written, though the brevity comes at the cost of behavioral and parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations, no output schema, and zero inline schema descriptions, this description is incomplete. An agent cannot fully determine which parameter is the volume name or how isGroup behaves without additional context. The docs link helps but does not substitute for inline guidance.
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 compensate. It gives one hint—'or job group' maps to isGroup—but it does not clarify that 'name' appears to be the target volume or explain how jobName is used. Most parameter meaning is left to inference.
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?
States a specific verb ('Attach') and resource ('recurring job...to a volume'), clearly distinguishing it from sibling tools like recurringjob_create and volume_recurring_job_delete. The purpose is immediately understandable.
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 when-to-use guidance, no prerequisites (e.g., that the recurring job must already exist), and no mention of alternatives such as recurringjob_create for defining a job first. The intended use is only implied by the action, not explained.
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 only says the tool updates a setting; it does not mention whether changes apply immediately, require restarts, are reversible, validate values, or cause side effects on running volumes.
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 a single front-loaded sentence with the core action and scope first, followed by the valid settings list and a documentation link. The list is long but directly relevant; the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and three required parameters, the description is incomplete. It does not explain the meaning of the volume 'name' parameter, how to choose the correct 'value' type for each setting, or what success/failure responses look like. The docs link helps but does not substitute for inline guidance.
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 needed to compensate, but it only repeats the enum values already present in the schema. It adds no explanation for what 'name' refers to, no type-to-setting mapping, and no guidance on how to format 'value' for different settings.
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 states a specific action ('Update'), a specific resource ('one of Longhorn's per-volume settings'), and narrows scope with 'per-volume', which distinguishes it from the sibling setting_update that targets global settings. The list of valid setting names reinforces the tool's purpose without ambiguity.
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 given about when to use this tool versus alternatives such as setting_update for global settings, volume_update for other volume properties, or volume_expand for size changes. The description only states what the tool does, not when to prefer it.
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 behavioral burden. It adds only the qualifier 'configured' and a docs link; otherwise it repeats the title's verb. It does not state the read-only nature explicitly, nor describe output shape, sorting, pagination, or failure behavior. For a zero-annotation tool, this is a meaningful 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?
Two short sentences with the core action front-loaded and a useful reference link appended. The docs URL earns its place as contextual material. Minor deduction because the first sentence nearly duplicates the title, a slot that could have carried differentiating or behavioral value instead.
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?
For a zero-parameter list operation, the description is near-minimally viable: an agent can invoke it correctly and understand its purpose. However, with no output schema, there is no indication of what fields a backup target contains (e.g., name, URL, availability), and no hint of when list is preferred over backuptarget_get. The docs link partially offsets these 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?
The input schema is empty with zero parameters, so there is nothing for the description to document. The rubric's baseline for 0 parameters is 4, and the description correctly avoids inventing parameter details. No compensation is needed.
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 states a specific verb and resource: 'List configured backup targets.' The verb 'list' inherently distinguishes it from sibling operations like backuptarget_create, backuptarget_update, and backuptarget_delete. However, it largely restates the title and does not explicitly contrast with the closely related backuptarget_get, so it stops short of 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. Siblings include backuptarget_get and backupvolume_list, but nothing tells an agent whether to prefer this list call or a get call for a specific target. The Longhorn docs link points to general backup-and-restore documentation, not to a usage decision guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that a backup is created, with no mention of potential side effects, required backup target configuration, or that a system backup is a Longhorn CRD operation. The docs link is helpful but the description itself lacks behavioral 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?
Single sentence with a supporting link, no redundant phrase. The core action is front-loaded and the docs link is placed after, keeping the description efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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, but with no annotations, no output schema, and no behavioral context the description is under-specified. It omits prerequisites (e.g., backup target) and expected outcomes, so an agent may call it without understanding side effects. The docs link helps but is not inline guidance.
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 the 'name' parameter at all. An agent must infer that 'name' is the backup name from the tool name, which is not reliable. With no param details in either schema or description, the agent cannot validate input 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?
States the specific action 'Create' and the resource 'Longhorn system backup,' clearly distinguishing it from sibling tools like systembackup_list/get/delete and systemrestore_create. The docs link adds authoritative context. No ambiguity about the tool's primary function.
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 gives no guidance on when to choose this tool over alternatives such as volume_snapshot_backup, volume_backup, or systemrestore_create. No prerequisites or context are mentioned, leaving the agent to infer the appropriate use case from the name 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, the description carries the full behavioral burden, but it only states the high-level creation behavior and the PV binding. It does not disclose side effects, idempotency, namespace defaults, prerequisites, or what happens if the PVC already 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?
One focused sentence followed by a relevant docs link. The key behavior is front-loaded and no words are wasted, making this appropriately concise for its complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and three undocumented parameters; the description provides only the high-level action and a docs link. It omits return values, defaults (e.g., namespace), and the relationship between name/pvcName/namespace, so an agent is not fully equipped to invoke it correctly.
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?
Schema description coverage is 0%, yet the description explains none of the three parameters. It leaves even the required 'name' ambiguous: the volume name, the PVC name, or something else? 'pvcName' and 'namespace' are not addressed at all, so an agent cannot confidently populate the input.
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 names a specific verb and resource: 'Create a Kubernetes PersistentVolumeClaim bound to this Longhorn volume's PV.' This is more specific than the title and clearly separates it from the sibling volume_pv_create, since it creates the PVC rather than the PV.
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 makes the action unambiguous but never states when to use this tool rather than volume_pv_create or another volume action. Usage is only implied by the creation semantics; there are no explicit conditions, 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?
No annotations are provided, so the description carries the full behavioral disclosure burden. It only states that the tool gets a CRD-backed snapshot; it does not describe read-only behavior, what happens when the snapshot is not found, required permissions, or what is actually returned. The docs link points to setup steps, not tool 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 a single, front-loaded sentence that states the verb and object immediately. The documentation link adds context without bloating the description, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two required parameters, no output schema, and no annotations, this description is under-specified. It omits parameter semantics, return value shape, not-found behavior, and any routing guidance among sibling snapshot tools. The docs link provides some help but does not make the description complete enough on its own.
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 map the required parameters name and snapshotName to their roles beyond 'for a volume.' An agent must infer that 'name' is likely the volume name and 'snapshotName' is the snapshot name; the description adds almost no parameter-level meaning.
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 a specific verb ('Get') and clearly identifies the resource as a CRD-backed snapshot for a volume. The 'CRD-backed' qualifier distinguishes it from sibling getters like volume_snapshot_get or snapshot_get, and 'one' makes the singular nature of the operation clear.
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?
There is no explicit guidance about when to use this tool versus volume_snapshot_cr_list, volume_snapshot_get, or snapshot_get. Usage must be inferred from the tool name and the phrase 'get one'; no alternatives, exclusions, prerequisites, or conditions 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 present, so the description carries the full burden. It only says 'List', which implies a read operation, but does not disclose behavior such as whether it returns a flat list or detailed objects, any pagination/limits, or authentication requirements. The doc link adds external reference but not internal behavioral 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 one sentence that immediately states the action and resource, followed by a relevant doc link. No filler or redundant phrasing. The purpose is front-loaded, and the link provides optional depth without cluttering the core definition.
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 one required parameter, no output schema, and no annotations, so the description carries most of the context. It correctly identifies the resource and volume association, and the doc link offers deeper setup context. However, it lacks any indication of return format, available fields, or edge cases, leaving some ambiguity for a minimally described read operation.
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 coverage is 0% for the single required 'name' parameter, but the description says 'for a volume', which strongly implies the parameter is the volume name. This adds meaning beyond the schema, though it does not clarify expected format, exact resource type, or whether other optional parameters exist.
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 states a specific verb ('List') and resource ('CRD-backed snapshots for a volume'), which distinguishes it from regular volume snapshot tools like volume_snapshot_list. The CRD qualifier and volume context clarify what this tool operates on, though it stops short of explicitly comparing with sibling tools.
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 given on when to use this tool versus alternatives such as volume_snapshot_list, snapshot_list, or volume_snapshot_cr_get. The 'CRD-backed' qualifier implies a usage context, but without exclusions or alternative routing, the agent is left to infer the appropriate scenario.
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 behavioral disclosure burden. It identifies what is being listed but does not state whether the operation is read-only, whether pagination exists, what ordering or scope applies, or what errors might occur. The docs link points to more information but does not provide inline behavioral 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 compact and front-loaded: the primary operation appears in the first sentence, and the docs link adds context without bloat. Every element contributes to the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation, the description is minimally serviceable: it names the resource and links to official documentation. However, with no output schema and no annotations, it does not explain the response shape, pagination, or any list-specific caveats, leaving some inference required.
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 the schema fully documents that, so there is no parameter semantics burden on the description. The baseline for a zero-parameter tool is therefore appropriate.
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 states a clear verb-resource pair ('List Longhorn backing images') and adds a domain docs link. It distinguishes itself from sibling get/create/delete operations by the 'list' verb, though it does not explicitly say how it differs from backingimage_get.
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?
There is no guidance on when to use this tool versus alternatives such as backingimage_get or backingimage_list_tags. An agent must infer usage from the tool name and conventional list semantics; no exclusions or selection criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses no behavioral traits. It does not state that this is a read-only operation, what the response contains, whether pagination or filtering occurs, or any side effects. Since no annotations are provided, the description carries the full burden, and this single sentence does not satisfy it.
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, front-loaded sentence with no redundant words. It conveys the essential purpose immediately and is appropriately sized for a tool with no 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?
Although the tool is simple (no parameters), the description omits any information about the return format or content, which is not covered by an output schema or annotations. An agent invoking this tool would not know what kind of data to expect in the response, making the description adequate but incomplete.
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, so there are no parameter details to explain. With an empty input schema, the description need not describe any arguments. Baseline of 4 applies for zero-parameter tools.
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 a list operation on a specific resource ('Longhorn instance manager pods/records'). The verb 'List' and the resource are explicit, and the action differentiates it from sibling instancemanager_get. However, the phrasing 'pods/records' is slightly ambiguous about whether it lists pods, records, or both, preventing 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?
No guidance is provided about when to use this tool versus alternatives such as instancemanager_get. The description only states the action and resource, with no mention of use cases, 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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It only repeats the verb 'List' and adds a docs link; it does not state scope, response format, or any side effects. The behavior is implicitly a read operation, but nothing explicit is added beyond the name.
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?
One sentence that leads with the verb and object, followed by a single relevant documentation link. No fluff, no redundancy, and it is instantly parseable.
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?
For a zero-parameter list tool, the description is minimally sufficient: it names the resource and provides external docs. However, it does not distinguish from volume_recurring_job_list or clarify whether it returns all jobs cluster-wide, and since there is no output schema, a bit more context on the return value would help.
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, so there is nothing to explain. The baseline for no parameters is 4, and the description correctly adds no unnecessary param details.
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 states a clear verb+resource pair: 'List Longhorn recurring jobs.' This is direct and unambiguous. However, it doesn't explicitly differentiate itself from sibling volume_recurring_job_list, which also deals with recurring jobs, so it falls short of a 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?
No guidance is given about when to use this tool versus alternatives such as recurringjob_get or volume_recurring_job_list. There are no usage conditions, exclusions, or mention of the read-only nature relative to mutation 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?
There are no annotations, so the description carries the full burden of behavioral disclosure. It only states the operation and the missing-schema caveat. It does not mention side effects, whether a backup target is required, whether the operation is asynchronous, or any permission or idempotency considerations.
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 focused sentences with no filler. The main action is front-loaded, followed by the necessary schema caveat and a doc link. Every sentence contributes useful information for invoking the tool.
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 description is incomplete on its own for an action with no annotations and no output schema. It does address the missing input schema by pointing to a discovery mechanism, which is valuable. However, it omits prerequisites such as needing a configured backup target, and it does not comment on response shape or job lifecycle. An agent could likely succeed after using the suggested discovery path, but the description leaves meaningful gaps.
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 50%, with only 'extra' having a schema description. The description adds useful direction: the exact body is version-dependent, and agents should call longhorn_describe_resource_type('backingImage') or pass fields via 'extra'. This compensates partially for the sparse schema but does not clarify the meaning of 'name' beyond it being required.
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: "Create a backup of a backing image." This is a specific verb plus resource, and the title reinforces it. Although it does not explicitly name sibling tools, the purpose is unambiguous and distinguishable from the other backing-image-related tools.
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 focuses on a schema caveat and how to discover the body shape, which is invocation guidance rather than usage context. No mention is made of prerequisites, exclusions, or alternative tools.
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 and does clearly flag the operation as destructive and authorization-gated. It does not, however, explain what makes it destructive, whether the change is reversible, or what side effects the update has on existing backup references.
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 front-loaded, with only three short sentences plus a documentation link. The destructive warning and authorization requirement are placed immediately after the action, and no sentence is wasted.
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?
For a simple two-parameter mutation, the description is serviceable but leaves gaps: parameter semantics are unclear, there is no mention of expected response or absence thereof, and sibling routing is absent. The documentation link provides an external fallback but not inline completeness.
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 the parameters. It implicitly identifies backupTargetName as the updated reference, but it never states that 'name' identifies the target record nor how the two parameters relate.
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 states a specific verb ('Update'), resource ('backup target record'), and the exact field being changed ('backupTargetName reference'). It is clearly about a narrow rename/reference update, even though it does not explicitly compare itself to the similar sibling backuptarget_update.
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 gives a strong invocation boundary: it is destructive and must only be called after explicit user authorization in the current conversation. However, it provides no guidance on when to choose this tool over backuptarget_update or other backup-target operations.
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 only says 'Get a single backup volume by name' and links to docs; it does not mention return format, not-found behavior, permission requirements, or whether the operation is a safe read. This is thin for an unannotated tool.
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, front-loaded sentence that states the core operation immediately, followed by a useful documentation link. There is no filler or redundant restatement of the tool name.
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 simplicity, one parameter, no output schema, and no annotations, the description is minimally adequate with the docs link offering an escape hatch. Still, it leaves out basic behavioral expectations such as what the response contains and what happens when the named backup volume does not exist.
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. The phrase 'by name' does add meaning beyond the bare 'name' property by confirming that the parameter is the lookup identifier. However, it provides no detail about name format, uniqueness, or expected values, so compensation is only partial.
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 ('Get'), the resource ('a single backup volume'), and the lookup key ('by name'). It distinguishes itself from list-style siblings by emphasizing 'single,' though it does not name any sibling explicitly.
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 use case is implied: use this when you need one backup volume by name rather than a list. However, there is no explicit guidance about when to prefer backupvolume_get over backupvolume_list or backupvolume_backup_get, and no when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral context; it does state a single read operation and references official docs for sharding concepts. It does not disclose not-found behavior, return format, or access requirements, but for a simple read operation this is minimally adequate.
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?
One short, front-loaded sentence plus a relevant documentation link; no filler or redundancy. It earns its place and is easy to scan.
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?
For a one-parameter getter, the essentials (verb, resource, lookup field) are present, and the docs link supplies background. However, without an output schema it does not state what is returned or error behavior, leaving a minor gap.
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 coverage for the single parameter is 0%, and the description only repeats the word 'id' ('by id') without adding format, source, or semantics beyond the schema. The lone 'id' parameter is self-descriptive, but the description does not compensate for the low coverage.
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?
States a specific verb ('Get'), resource ('shard'), and lookup method ('by id'). It is clear and distinguishes from shard_list by using 'single' and from shardgroup_get by naming the shard resource, though it does not explicitly name siblings.
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 'by id' phrasing implies use when the caller already has a shard identifier, with shard_list as the enumeration alternative, but the description offers no explicit when/when-not guidance or mention of alternatives.
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 for behavioral disclosure, and it only states the core action. It does not disclose that this is a mutating operation that copies snapshot data into a backup target, that a backup target must likely be configured beforehand, or that Longhorn backup creation is typically asynchronous. The description at least conveys that a backup artifact is created, but critical operational context is missing.
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?
A single front-loaded sentence naming the action and source resource, followed by a reference link, with zero filler. Every element earns its place, and the description is appropriately sized for the minimal content it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a moderately complex mutating tool (4 params including a nested labels object, a required but ambiguous 'name') with no annotations, no output schema, and an elaborate sibling ecosystem around backups and backup targets. The description does not clarify the required parameter, backupMode values, prerequisites such as an existing backup target, or operation timing. The external docs link partially mitigates the gaps but does not make the definition self-contained enough for reliable autonomous invocation.
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 compensate for undocumented parameters, and it barely does. The phrase 'from a volume snapshot' weakly hints that snapshotName identifies the source snapshot, but the required 'name' parameter is never explained: it is ambiguous whether it refers to a volume, a snapshot, or the resulting backup. labels and backupMode are entirely unexplained, leaving an agent to guess their accepted values and meaning.
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 'Create a backup from a volume snapshot' uses a specific verb (create) plus a resource (backup derived from a snapshot), conveying the input-to-output relationship the bare name 'volume_snapshot_backup' does not. It is clearly distinguishable from siblings like volume_snapshot_create (creates snapshots, not backups) and backup_get/backup_list (read 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?
No explicit when-to-use or when-not-to-use guidance is given, and no alternative tools are referenced. Usage is only implied by the semantics: an agent can infer 'use this when you need to create a backup from a snapshot,' but nothing tells it to prefer this over volume_snapshot_create or how it relates to backuptarget/backupvolume tooling. The Longhorn docs link points to relevant material but is not in-description guidance.
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 behavioral disclosure burden. It only says 'Create a new backup target' and points to Longhorn docs; it does not disclose potential failure modes, whether creation is idempotent, whether credentials or external connectivity are required, or what side effects may occur during creation.
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 focused sentence followed by a reference link. It is front-loaded with the core purpose and contains no filler or redundant restating of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no annotations, no output schema, and a nested `extra` parameter. The description is too thin to fully prepare an agent: it does not explain expected input requirements, return behavior, or operational constraints. The Longhorn docs link provides a reference but does not substitute for inline tool guidance.
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 adds no parameter-level meaning, but the input schema already documents `extra` as 'Additional Longhorn fields, merged verbatim into the request body.' The `name` field is self-evident from its name and role. At 50% schema coverage, this is acceptable, though the description could have clarified required name 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 states a specific action and resource: 'Create a new backup target.' The verb 'create' plus the resource 'backup target' clearly distinguishes this tool from the sibling backuptarget_update, backuptarget_delete, and backuptarget_sync operations without confusion.
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?
Usage is implied: this tool is for creating a backup target, while siblings are for updating, deleting, or syncing. However, the description gives no explicit when-to-use guidance, prerequisites, or exclusions, so the agent must infer the appropriate context from the operation name.
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 burden of behavioral disclosure. It confirms this is a read operation, but it does not disclose response behavior, error cases (e.g., node not found), authentication needs, or any other operational traits beyond what 'Get' already implies.
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, front-loaded sentence that identifies the action, resource, and identifying parameter with no wasted words. The included documentation link is relevant and provides an easy path for additional context without cluttering the description.
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?
For a simple get-by-name tool with one parameter and no output schema, the description is largely sufficient: it names the operation, the resource, and the required lookup key, and provides a documentation link. It could be more complete by noting what happens when the node does not exist, but the overall context is adequate for a low-complexity read operation.
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 does connect the single parameter 'name' to the lookup key for the node record, which is some added meaning beyond the raw schema. However, it does not add any format, constraints, or examples beyond the parameter name itself.
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?
Description states a specific verb ('Get'), a specific resource ('a single Longhorn node record'), and the lookup key ('by name'), which clearly differentiates it from node_list and node_update. It is immediately obvious what the tool does and how it differs from sibling tools.
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 implies usage when a single node record is needed by name, but it does not explicitly state when to use this tool versus alternatives like node_list or node_update. No guidance on when not to use it is provided, leaving the agent to infer usage from the sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral disclosure burden, but it only says 'Get' and provides a docs link. It does not state behavior for a missing/invalid id, whether the operation requires special privileges, or what response the caller can expect.
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 short sentences and wastes no words. The core action is front-loaded, and the documentation link is useful and clearly separated.
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 is a simple one-parameter getter, so the absence of an output schema is not on its own fatal, but the description leaves out how to obtain/format the id and what the return payload is. The linked Longhorn docs partially compensate for the missing context.
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 needs to explain the 'id' parameter beyond its name. Saying 'by id' only repeats the obvious and does not clarify id format, source, or whether the id is numeric/name-based. This is insufficient compensation for the missing 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 description states the exact operation ('Get'), the resource ('shard group'), and the selection criterion ('by id'), so an agent immediately knows what the tool does. 'A single' also differentiates it from shardgroup_list without needing to open schemas.
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 phrase 'by id' implies this is the single-item retrieval tool rather than shardgroup_list, but the description never explicitly says when to choose it over alternatives such as shard_get or shardgroup_list. There is no 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden of behavioral disclosure. It does meaningfully state that this is a plain read-only GET, which signals no side effects and read-only-mode compatibility. It does not describe response shape, error behavior for missing IDs, or any authentication requirements, leaving some 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short: one sentence with the essential behavior and a documentation link. It is front-loaded with the key action and read-only note, with no filler or redundant information. Every part 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?
For a simple one-parameter get operation with no output schema, the description provides enough context for an agent to understand the core behavior and safe execution. The docs link adds helpful reference material. Minor missing details like id format and error semantics prevent a 5, but overall this is reasonably complete for the tool's low complexity.
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 compensate for the undocumented parameter. 'by id' loosely indicates that the id parameter identifies the snapshot, but it does not explain the expected format (e.g., name vs. UUID) or where to obtain valid IDs. This is minimal compensation for a schema with no description at all.
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 states a specific verb ('Get'), a resource ('single snapshot by id'), and the HTTP nature ('plain read-only GET'), making the tool's purpose immediately clear. It does not explicitly distinguish itself from sibling tools like snapshot_list or volume_snapshot_get, but 'by id' and 'single' imply a targeted fetch rather than a list operation.
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 phrase 'available in --read-only mode' gives useful operational context, implying this is a safe read operation suitable for read-only environments. However, there is no explicit when-to-use versus alternative guidance, such as 'use snapshot_list to enumerate snapshots' or 'use volume_snapshot_get for volume-scoped retrieval.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. It discloses that the operation is destructive and requires explicit user authorization, which is valuable. But it does not say whether the purge is permanent/irreversible, what data is freed, or what side effects occur beyond removal.
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?
Two sentences plus a docs link; the core action is front-loaded and the safety warning follows directly. No redundant phrasing, and the link adds value without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, no output schema, and a single undocumented parameter, the description provides a safety warning but omits how success is confirmed, prerequisites, and the precise meaning of 'removed snapshots' in Longhorn. The docs link partially compensates, but the definition remains incomplete.
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 only parameter 'name' is undocumented in the schema. The description implies the target is a volume ('of a volume') but never explicitly states that 'name' refers to the volume name, leaving ambiguity about whether a snapshot name could also be expected.
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?
States a specific verb (purge) and target (removed snapshots of a volume). The phrase 'removed snapshots' distinguishes it from sibling volume_snapshot_delete, which targets existing snapshots, though it does not explicitly name that alternative.
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?
Provides an explicit when-not-to-call rule: only with user authorization, never proactively, speculatively, or as a side effect. It does not, however, state when this tool is appropriate relative to alternatives like volume_snapshot_delete.
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. It only states the update action, with no mention of side effects, such as whether lower values may cause existing copies to be pruned or whether higher values may trigger additional replica creation. It also does not note permissions, idempotency, or failure 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 a single clear sentence followed by a useful documentation link. It is appropriately sized, front-loaded with the core action, and contains no redundant or filler text.
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?
For a simple two-parameter update tool, the description provides the essential purpose and a documentation reference. However, with no annotations and no output schema, an agent would benefit from behavioral context (effects of changing the value, prerequisites, or confirmation behavior) to fully understand the operation's consequences.
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 does clarify the meaning of minNumberOfCopies ('minimum number of ready copies required'), but it does not explain the 'name' parameter beyond the general reference to 'a backing image', nor does it mention constraints like minimum 1. This is partial compensation for a low-coverage 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 uses a specific verb ('Update') and a precise resource ('the minimum number of ready copies required for a backing image'), which is far more specific than the title alone. It is clearly distinct from sibling tools like backingimage_create, backingimage_delete, and backingimage_cleanup.
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 use case: call this when you need to change the minimum ready-copies threshold for a backing image. However, it provides no explicit guidance on when to use this instead of related backing image tools, nor any 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but the description does not mention error behavior, return format, permission requirements, or whether the operation is safe. For a simple getter this is minimally acceptable but not rich.
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 short sentences with the action front-loaded and a useful docs link appended. There is no redundant wording or filler; it is appropriately sized for the tool's simplicity.
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?
For a one-parameter read operation, the description is usable, but with no annotations and no output schema it omits return value details, not-found behavior, and any permissions nuance. The docs link mitigates the gap but does not fully compensate for the lack of behavioral context.
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%, and the only parameter is 'name'. The description clarifies that the name identifies the backup target to retrieve, which is basic but sufficient for a single-parameter getter. It adds little more than what the schema already shows.
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 states a specific verb ('Get'), resource ('backup target'), and scope ('single...by name'), which clearly differentiates it from backuptarget_list and mutation siblings like backuptarget_update or backuptarget_delete. It does not explicitly name alternatives, so it falls short of a 5.
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 phrase 'by name' implies a precondition: the agent must know the target's name to retrieve it. However, there is no explicit guidance about when to use this tool versus backuptarget_list or when not to use it. Usage is only implicit.
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 behavioral transparency burden. It establishes that this is a read-only enumeration of backup-target-side volume records, but it does not mention prerequisites like a configured backup target, pagination behavior, or whether metadata is returned. The docs link helps but the description itself is thin.
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?
A single concise sentence front-loads the action and resource scope, followed by a useful documentation link. There is no filler, redundancy, or unnecessary detail.
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?
For a zero-parameter, read-only list operation, the description provides enough scope clarity and even differentiates backup volumes from other listed resources. It does not describe the return shape, but the low complexity and linked documentation mitigate that gap.
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 is empty with 100% schema description coverage, so no parameter semantics are needed. The description adds nothing about parameters, but none exist; this matches the baseline for zero-parameter tools.
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 uses a specific verb ('List') and resource ('Longhorn backup volumes'), with the parenthetical '(backup-target-side volume records)' clarifying the exact scope. This distinguishes it from plain volume lists, though it does not explicitly name sibling tools like volume_list or backup_list.
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?
There is no guidance on when to use this tool versus backupvolume_get, volume_list, backup_list, or other list operations. The Longhorn docs link provides reference material but no selection criteria, leaving the agent to rely on name inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does not disclose that this is a read-only operation, what happens if the name is not found, authorization requirements, or the shape of the returned object. The verb 'get' is the only behavioral signal.
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?
A single sentence with no filler. Every word is necessary and the key information is front-loaded.
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?
For a simple get-by-name tool with one parameter and no output schema, the description adequately conveys what is returned (the named instance manager). It omits error/edge-case details, but these are less critical for a basic retrieval 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 input schema only provides a string type for 'name'. The description adds meaning by explicitly saying the resource is retrieved 'by name', which is critical because schema description coverage is 0%. It maps the single parameter to the tool's purpose effectively.
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 states a specific verb (Get), a specific resource (instance manager), and a scoping constraint (single, by name). This distinguishes it from the sibling instancemanager_list, though it does not explicitly name the alternative.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The phrase 'by name' implies it should be used when a known instance manager identifier is available, but it does not route the agent away from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals that this is a cancel/mutation operation, but it does not disclose side effects, reversibility, idempotency, failure behavior, or what state the volume will be in after cancellation. The documentation link is a pointer, not a substitute for behavioral disclosure.
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 with no filler, and it includes a documentation link for further reference. It is front-loaded and every word contributes to the core meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation operation with no annotations, no output schema, and minimal parameter guidance, this description is incomplete. It lacks details about prerequisites, expected behavior, error conditions, and the meaning of the only parameter. The documentation link helps but does not make the tool self-sufficient for correct invocation.
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 compensate for the undocumented 'name' parameter. It does not explicitly say whether 'name' refers to the volume name, an expansion ID, or something else. The phrase 'volume expansion' gives a weak domain clue, but this is not sufficient.
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 states a specific action ('Cancel') and a specific resource ('an in-progress volume expansion'). It clearly distinguishes this tool from the sibling volume_expand, which initiates expansion.
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 'in-progress volume expansion' provides a clear condition for when this tool should be used: only when an expansion is currently underway. It does not explicitly discuss when not to use it or compare it with alternatives, but the context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It explicitly warns the tool is 'Destructive' and instructs the agent to require explicit user authorization. However, it does not mention irreversibility, impact on downstream operations, or what happens after deletion.
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 sentences with no filler: the action, the destructive warning, the authorization constraint, and a reference doc link. Important safety information is front-loaded, and every sentence earns its place.
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?
For a simple destructive tool with two string parameters and no output schema, the description covers the core purpose and safety gate. It is incomplete on parameter semantics and long-term effects, so an agent may still need external context before calling it correctly.
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 that 'name' refers to the volume and 'snapshotName' refers to the snapshot to delete. The phrase 'snapshot of a volume' hints at the relationship but does not compensate for the lack of parameter documentation.
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 states a specific verb and resource: 'Delete a snapshot of a volume.' This is clear and distinct from read/list operations, though it does not explicitly differentiate from sibling tools like volume_snapshot_purge or volume_snapshot_cr_delete.
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 gives explicit when-not guidance: do not call unless the user has explicitly authorized it in this conversation, and never proactively, speculatively, or as a side effect. It does not mention alternative tools or when a different snapshot operation would be preferable, so it stops 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.
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 behavioral burden. It discloses that no dedicated schema is published, which is useful, but it does not state side effects, asynchronous behavior, or what the upload trigger does beyond the name. For a mutating action, this is a significant transparency 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 concise, front-loads the purpose, and then provides necessary caveats in a second sentence. The doc link is a bit long but useful. It earns its place.
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 output schema and no annotations, a trigger action should explain what happens after the call. The description offers a fallback for schema discovery and a docs link, making it partially complete. But it omits behavioral context such as async execution, required permissions, or expected response. It is adequate but not thorough.
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 coverage is 50%: 'extra' has a meaningful description, but 'name' only has a type. The description adds value by explaining that extra fields are merged verbatim and by pointing to a way to discover the full body shape. However, it does not clarify the 'name' parameter beyond what the schema shows.
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 'Trigger backing image upload,' which names a specific verb and resource. It is distinct from sibling tools like backingimage_create or backingimage_cleanup because 'upload' is a unique operation. The action is immediately understandable.
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?
While it doesn't explicitly compare against alternatives, the operation is unique among siblings, so no exclusion is needed. It provides concrete invocation guidance: check the deployed schema via longhorn_describe_resource_type or pass fields via extra. The context is clear enough for an agent to proceed.
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 and does disclose the destructive nature upfront ('Destructive') plus a strong guardrail against unsanctioned calls. But it leaves key behavioral traits ambiguous: whether the underlying data is destroyed or only the metadata record, whether the deletion is reversible, and what cascading effects occur on associated backups.
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 economical sentences, each earning its place: purpose, destructiveness, and the authorization constraint are front-loaded. The docs link adds reference value without bloating the description.
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?
For a simple one-param destructive tool with no output schema, the safety semantics are well covered via the explicit authorization gate and 'Destructive' marker. However, the missing parameter semantics and lack of clarity about the actual scope of destruction (record vs. data) leave the definition incomplete for confident invocation.
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 adds no parameter guidance. The agent is left to infer what 'name' refers to, its expected format, and whether it comes from backupvolume_list or backupvolume_get output — a significant gap for a single-param destructive call.
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 states a specific verb and resource — 'Delete a backup volume record from the backup target' — and the word 'record' distinguishes this from deleting an individual backup within a volume (backupvolume_backup_delete). The scope is clear and properly differentiated from the many backup-related siblings.
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 gives explicit authorization gate guidance: 'Do not call this unless the user has explicitly authorized it in this conversation — never proactively, speculatively, or as a side effect of another task.' However, it provides no when-to-use vs. alternatives guidance (e.g., choosing this over backupvolume_backup_delete or backupvolume_list/get), leaving sibling differentiation entirely to the agent.
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. 'Get' clearly implies a read-only operation and 'by name' implies exact-identifier lookup, but the description does not mention side effects, error behavior when the image is not found, or what data is returned. For a simple getter this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear, front-loaded sentence that immediately states the operation and target. The Longhorn docs link is extra but relevant context, and the overall size is appropriate for a one-parameter getter.
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?
For a simple one-parameter read-only getter, the description is mostly sufficient: it names the resource, the selectors, and the action. However, there is no output schema and no mention of return content or not-found behavior, so an agent lacks some context about what to expect from a successful or failed invocation.
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 coverage is 0%, so the description must compensate. It does add the meaning that the 'name' parameter is the lookup key for a single engine image, but this largely restates what the schema property already suggests. No format, uniqueness, or existence requirements are given, so the contribution is minimal.
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?
States a specific verb ('Get'), a distinct resource ('engine image'), and a precise selection mode ('by name'). It clearly differentiates from engineimage_list, which would retrieve multiple images, and from engineimage_create/delete, which are mutations.
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 phrase 'single engine image by name' implicitly signals that this is for retrieving one known image rather than listing all images, but there is no explicit guidance on when to prefer this tool over siblings or what to do if the image does not exist. The Longhorn docs link points to upgrade docs but does not clarify 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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the list operation. It says nothing about return format, pagination, filtering, whether engine images are only ready ones, or any side effects—though listing is implicitly read-only.
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 front-loaded sentence that states the purpose immediately, followed by a relevant documentation link. There is no redundant or filler content.
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?
For a zero-parameter list tool, the description is nearly complete: it names the resource and provides a domain doc link. However, it does not indicate whether the result is a summary or full detail list, which would be helpful given no output schema exists.
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 the schema coverage is 100%, so there is nothing for the description to add. Per the baseline for a zero-parameter tool, this is appropriate.
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 states a clear verb and resource: 'List Longhorn engine images.' It distinguishes itself from sibling tools like engineimage_get, engineimage_create, and engineimage_delete by the list verb, and from other list tools by naming the specific resource.
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 gives no explicit guidance on when to use this tool versus alternatives such as engineimage_get or engineimage_list. It does not mention any exclusions, prerequisites, or selection criteria, leaving the agent to infer usage solely from the tool name.
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 present, so the description must carry the behavioral disclosure burden. 'Get' implies read-only behavior, but the description does not state return format, not-found behavior, permissions, or side effects. The external docs link is helpful but does not provide inline behavioral 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 extremely concise: two short clauses plus a reference link. Every element earns its place and the core operation is front-loaded without redundant restatement.
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?
For a simple one-parameter read operation, the description plus schema is largely sufficient for an agent to invoke it correctly. It omits return format and error details, but the official documentation link helps mitigate that gap for a tool of this low complexity.
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 has 0% description coverage, but the description compensates by saying 'by name,' which clarifies that the required `name` parameter identifies the specific system backup to retrieve. This fully covers the single parameter's meaning.
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 a specific verb ('Get') against a specific resource ('single system backup'), and the qualifier 'by name' distinguishes it from list/create/delete sibling operations. It avoids tautology and is immediately actionable.
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?
There is no explicit when-to-use guidance, nor any mention of alternatives such as systembackup_list or systemrestore_get. The only implied usage is that the caller must already know the backup name.
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 disclosing behavior. It only says 'Get', which implies a read operation, but it doesn't state what happens if the name doesn't exist, whether there are side effects, or what authentication is needed. This is a significant gap for a tool with no annotation safety hints.
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 states the operation and key parameter, followed by a documentation link. Every word earns its place and the core information is front-loaded.
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?
With no output schema and no annotations, the description should explain return values or error behavior, but it doesn't. The operation and parameter are clear, and the doc link adds context, but the agent is left guessing what the response contains or how failures are signaled. This is adequate for a simple get-by-name but not fully 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. It does clarify that the required 'name' parameter is the system restore's identifier by saying 'by name', adding meaning beyond the bare 'string' type in the schema. However, it doesn't describe any constraints or format expectations for the name.
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 'Get a single system restore by name' uses a specific verb and resource, and the qualifier 'single... by name' clearly distinguishes it from systemrestore_list, systemrestore_create, and systemrestore_delete. An agent can tell exactly what this tool does without needing to open the schema.
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 'by name' provides clear context: this tool is for retrieving one specific restore when the name is known. It doesn't explicitly recommend list or other alternatives for discovery, but the context is strong enough that an agent can infer when 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?
With no annotations, the description takes on the safety burden and does so well: it labels the operation 'Destructive' and warns that 'forceDetach: true risks data corruption if the volume is mid-write.' It also states the authorization requirement. It does not explain all side effects or post-detach state, but the critical behavioral risks are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the action, the risk, the destructiveness, and the authorization constraint each get a short sentence. The supporting docs link is the only extra element and is relevant. No filler or repetition.
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 description is adequate for a safety-critical tool because it highlights the destructive nature and authorization bar, and it links to official docs. However, there is no output schema, no annotations, and three of four parameters are not semantically explained, so the overall context is incomplete for a fully correct invocation.
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 should explain the four parameters. It only adds meaning for forceDetach, warning about the data-corruption risk. name, hostId, and attachmentID are left unexplained, leaving the agent without enough semantic guidance for the other three parameters.
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 opens with a specific verb+resource: 'Detach a volume.' This clearly identifies the operation and, through the 'detach' action, distinguishes it from sibling tools like volume_attach and volume_delete. However, it does not explicitly position itself among those siblings, so it stops just short of a fully differentiating statement.
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 an explicit authorization gate: 'Do not call this unless the user has explicitly authorized it in this conversation — never proactively, speculatively, or as a side effect of another task.' This tells the agent when not to invoke the tool. It does not, however, discuss when to prefer this over related volume operations, missing a small piece of routing 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, the description carries the burden of behavioral disclosure. The verb 'Get' and 'by name' convey a read/retrieval operation with no side effects, which is sufficient for a simple getter, but it does not state return shape or failure behavior. Minimal but not misleading.
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?
One sentence and a link, with the operative verb and resource front-loaded and no filler. Every element 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?
For a simple one-parameter getter with no output schema and no annotations, the description is nearly complete: it names the resource, the operation, and the identifying parameter. It only lacks explicit guidance on when to choose this over list/search siblings.
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 input schema provides only a `name` string with 0% description coverage. The description adds that the parameter is used to select a single backup backing image, which is helpful but largely restates the parameter name. It does not describe format, uniqueness, or how to discover valid names; the docs link is the only additional resource.
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 states a specific verb-resource pair ('Get a single backup backing image') and the selection mechanism ('by name'), which clearly distinguishes it from list-oriented siblings like backupbackingimage_list and mutation tools like backupbackingimage_delete. It is unambiguous 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.
Usage Guidelines3/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 caller already has a specific name—but it never explicitly contrasts it with alternatives (e.g., backupbackingimage_list) or states when not to use it. The Longhorn docs link provides background but not decision 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 must carry the full behavioral burden. It states 'Destructive,' which is a key trait, and adds an authorization guard, but it does not disclose the operation's consequences (e.g., whether it is reversible, whether running workloads are affected, or what specifically gets removed). The docs link offers supplemental information, but the description itself is thin.
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 concise, purposeful sentences: the action, the destructive warning with usage guard, and a documentation link. No filler or redundancy; the most important caution is front-loaded.
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?
For a simple delete tool with one parameter, the description covers the core action and authorization constraint. However, the lack of parameter documentation and minimal behavioral detail (beyond 'Destructive') leaves gaps that are especially notable because no annotations or output schema exist to fill them. The docs link partially mitigates this.
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% for the single required 'name' parameter, and the description does not compensate. It never explains that 'name' refers to the Longhorn engine image name or its expected format. While inferable from context, the description adds no parameter meaning beyond the schema field itself.
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 states a specific verb and resource: 'Delete a Longhorn engine image.' This clearly distinguishes the tool from sibling engineimage_list, engineimage_get, and engineimage_create tools by the delete action.
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 gives explicit authorization conditions: 'Do not call this unless the user has explicitly authorized it in this conversation — never proactively, speculatively, or as a side effect of another task.' It does not name alternatives, but for a destructive delete, the primary alternative is abstaining unless authorized, which is clearly communicated.
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 does reveal that this is a read-only GET operation returning field definitions and available actions, which is helpful. However, it does not mention potential error behavior, authentication requirements, or what happens when an invalid id is provided.
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 action and target resource, includes the exact HTTP endpoint, and adds helpful examples. There is no redundant or filler content.
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?
For a simple one-parameter schema-introspection tool, the description covers the request target, the HTTP method, and the shape of the response (fields and available actions). It is slightly incomplete in not pointing to the sibling list tool for discovering valid resource types, but this is a minor gap given the examples.
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 only defines 'id' as a string with no description, so the description must compensate. It does by explaining that 'id' is a Longhorn resource type and giving concrete examples, which meaningfully clarifies the expected value even though it does not enumerate all valid options.
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 states a specific verb ('Describe'), a precise resource ('one resource type'), and the underlying endpoint 'GET /v1/schemas/{id}'. It also gives concrete examples ('volume', 'backupTarget', 'node') that make the tool's scope immediately clear and distinguishable from sibling tools like longhorn_list_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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool compared to alternatives such as longhorn_list_resource_types or the many resource-specific get tools. The examples imply that it is for schema introspection, but the description does not state this or provide any when-to-use/when-not-to-use direction.
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. 'List' implies a read-only operation, and the description adds scope ('against its own resources'), but it does not disclose behavior such as event ordering, pagination, retention, namespace filtering, or output shape.
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?
A single, concise sentence that states the action, object, and scope without wasteful filler. The key qualifier ('against its own resources') is included up front and 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?
For a zero-parameter list tool, the description is mostly complete: it names the resource type and its scope. However, because there is no output schema, the description could usefully note what an event entry looks like or how events are returned, though this is a minor gap for such a simple 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 tool has zero parameters and schema description coverage is 100%, so the schema is self-sufficient. The description adds no parameter details, but none are required; the baseline for a zero-parameter tool is 4.
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 a specific verb ('List') and resource ('Kubernetes events Longhorn has recorded against its own resources'), clearly distinguishing this from sibling list tools that target specific resource types. The scope is explicit and immediately understandable.
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, and no exclusions or sibling comparisons are mentioned. While the description implies it is for inspecting Longhorn-related events, an agent gets no explicit context about troubleshooting or when another list tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden. The verb 'List' clearly indicates a read-only operation, and 'known to Longhorn' conveys a system-wide scope. However, it does not disclose return format, ordering, pagination, or the exact meaning of a tag being 'known to Longhorn,' leaving some behavior implicit.
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 extremely concise: one actionable sentence followed by a documentation link. It front-loads the core behavior and filter option without any wasted words. This is an appropriate amount of text for a simple list tool.
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 low complexity—one optional enum parameter and no output schema—the description is mostly complete. It states what is listed, the optional filter, and provides a documentation link. It could be slightly more complete by describing the expected return shape, but for a basic tag-listing operation the current description is adequate.
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 coverage is 0%, so the description must compensate. It does add meaning by framing 'type' as a filter and naming the categories: node, disk, and backing-image. This maps to the enum values, but it does not explain semantic differences between tag types or what the returned tags represent.
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 states a specific action and resource: 'List node/disk/backing-image tags known to Longhorn.' This clearly distinguishes the tool from sibling list tools like node_list or backingimage_list, which list resources rather than tags. The optional filter by type is also stated.
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 phrase 'optionally filtered by type' gives some guidance on how to narrow the result, and the tool's purpose implies when to use it. However, there is no explicit guidance about when to prefer this tool over alternatives or when not to use it. No alternatives or exclusions are mentioned.
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 behavioral disclosure burden. It correctly implies a read-only listing operation and adds useful context about what a VolumeAttachment represents, but it does not mention output format, pagination, or any other observable behavior beyond 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?
A single, compact sentence that front-loads the action and resource, with the parenthetical adding useful context without redundancy. Every word 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?
For a zero-parameter list operation on a well-defined resource, the description is sufficient for an agent to know what will be listed and what kind of data to expect. It could be slightly stronger by mentioning the return type, but the simplicity of the operation makes that a minor gap.
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, so the input schema is trivially complete and the description does not need to explain any parameters. The baseline of 4 applies because there is nothing for the description to add.
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 a specific verb ('List') and identifies the exact resource ('Longhorn VolumeAttachment records'), with a clarifying parenthetical ('attachment tickets per volume') that explains what these records represent. This clearly distinguishes it from the sibling volumeattachment_get, which retrieves a single record.
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 gives no guidance on when to use this tool versus the closely related volumeattachment_get or other list tools. Usage is only implied by the verb 'List' and the resource name, with no explicit context, 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, the description carries the behavioral burden; 'Get a single Longhorn volume' indicates a read-only lookup with no side effects. However, it does not disclose response format, not-found handling, or permissions, so some transparency gaps remain.
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 core statement is a single front-loaded sentence with no filler, and the optional docs link is a useful reference. Every part earns its place.
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?
For a one-parameter getter, the description gives enough to invoke it correctly, but without an output schema it omits what the response contains and how failures surface. It is minimally viable rather than complete.
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 coverage is 0% and the description only rephrases the schema's name field as 'by name' without adding format, examples, or identifier constraints. The self-evident string parameter is not enough to compensate for the low 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?
States the exact verb (get), resource (single Longhorn volume), and lookup key (name), which clearly distinguishes it from volume_list and other volume_* operations. The phrase 'by name' also differentiates it from getters that use IDs or filters.
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 makes it clear this is for fetching exactly one volume when its name is known, giving clear context for when to choose it over volume_list. It does not explicitly name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does communicate the scope ('all Longhorn volumes') and the read-only nature of listing is implied, but it does not mention return format, pagination, or potential side effects. This is minimal but not completely absent.
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 a single concise sentence followed by a documentation link. It is front-loaded and efficient, though the docs link points to 'create-volumes' which is arguably off-topic for a list operation, slightly reducing the score.
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?
For a simple zero-parameter list tool, the description is minimally sufficient: it names the resource and action. However, it lacks any mention of the return payload structure or behavioral nuances, which would be helpful given there is no output schema. The documentation link provides some external context.
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, so the schema already fully documents the input space. The description correctly adds no parameter information since there is nothing to explain, matching the baseline of 4 for zero-parameter tools.
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 'List all Longhorn volumes' with a specific verb ('List') and resource ('Longhorn volumes'), and the qualifier 'all' distinguishes it from single-volume tools like volume_get. It is unambiguous and easily distinguishable from siblings.
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 usage is implied by the straightforward 'List all Longhorn volumes' purpose, but there is no explicit guidance about when to use this versus alternatives like volumeattachment_list or snapshot_list. No exclusions or conditions are provided beyond the basic action.
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 itself carries the burden of disclosing behavior. It explicitly warns 'Destructive' and mandates explicit user authorization, which covers what gets destroyed and the auth requirement. It does not mention irreversibility or downstream effects on backups, but the core destructive nature is clearly flagged.
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 short, front-loaded with the action, and every sentence earns its place: the purpose, the destructive warning, the authorization guardrail, and a doc link. No filler.
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?
For a simple delete tool, it covers the purpose and safety, but the complete absence of parameter semantics is a significant gap. An agent cannot reliably construct a correct invocation because it doesn't know what values these two required fields should take.
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?
Schema description coverage is 0%, so the description was the only place to explain the parameters, and it does not. Neither 'name' nor 'snapshotName' is defined or given context, leaving the agent to guess which refers to the volume and which to the snapshot.
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 'Delete' and identifies the exact resource: a CRD-backed snapshot for a volume. The 'CRD-backed' qualifier distinguishes it from the sibling volume_snapshot_delete, so an agent can tell them apart.
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 gives an explicit when-not: do not call unless the user has explicitly authorized it in this conversation, never proactively, speculatively, or as a side effect of another task. It does not, however, point to an alternative tool for non-CRD snapshots, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It conveys a read-only 'Get' operation on a single identified resource, but it does not describe the response format, potential errors, or whether a file/artifact is returned. The docs link provides some added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence followed by a relevant documentation link. There is no filler or repetition; every element earns its place.
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?
For a one-parameter read tool, this is close to sufficient: it names the target, the identifying input, and links to Longhorn docs. However, there is no output schema and no explicit statement about what the caller should expect in return, so it is adequate but not fully self-contained.
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 clarify the sole parameter. It does establish that 'id' selects a specific support bundle, which adds meaning beyond the bare 'string' type, but it does not explain the id format or where to find it.
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 states a specific verb ('Get'), a clear resource ('support bundle'), and scope ('single' by 'id'). The word 'single' distinguishes it from the sibling supportbundle_list tool without ambiguity.
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 clearly indicates that the tool is used when you have a support bundle id and want exactly one result. It does not explicitly mention listing first or when not to use it, but the selection criterion is unambiguous.
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 clearly indicates a read operation, but it does not disclose behavior such as errors for missing names, return format, permission requirements, or whether the operation is purely read-only beyond the word 'Get'.
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 extremely concise and front-loaded: the core behavior is in the first sentence, and the documentation link is a useful addition. No words are wasted.
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?
For a simple single-parameter get operation, the description is mostly complete: it identifies the resource, the selection criterion, and provides a documentation link. It does not describe error behavior or return shape, but the resource name and action make the expected result fairly clear.
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 by explaining that the single 'name' parameter identifies which backing image to retrieve. This adds meaningful semantics beyond the schema's bare 'type: string' declaration, though it does not detail exact matching or formatting rules.
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 states a specific verb ('Get'), a specific resource type ('backing image'), and a selection criterion ('by name'). This clearly distinguishes it from sibling tools like backingimage_list, backingimage_create, and backingimage_delete.
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 when a single, known backing image is needed, but it does not explicitly state when to prefer this tool over backingimage_list or provide any exclusions. Usage context is only implicit through the phrase 'single... by name'.
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 explicitly labels the operation as 'Destructive' and warns against proactive or speculative invocation, which is valuable behavioral context beyond the schema. It could add permanence or remote-backup implications, but the warning is sufficient.
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 tight: purpose, destructive warning, authorization guidance, and a docs link. Every sentence earns its place, and the most important safety information is front-loaded.
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?
For a simple two-parameter destructive delete with no output schema, the description covers the purpose, safety profile, and authorization requirement. It does not describe return values, but delete operations typically return minimal or no structured output, so this is not a significant gap.
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 coverage is 0%, so the description must compensate. It clarifies that the backup belongs to a backup volume, implying 'name' identifies the volume and 'backupName' identifies the specific backup. However, it does not explain naming conventions or how to obtain valid values.
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 states a specific verb ('Delete'), a specific resource ('a specific backup belonging to a backup volume'), and its scope. This clearly differentiates it from sibling tools like backupvolume_delete or backupbackingimage_delete.
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?
It provides a clear authorization condition: do not call unless the user explicitly authorized it in this conversation. However, it does not mention alternatives or when this tool should be chosen over related backup deletion tools.
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 identifies this as a list operation, which implies a read-only behavior, and discloses what information is included (scheduling state, disks, conditions). It does not mention pagination or authentication, but for a zero-parameter list tool these are minor omissions.
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, well-structured sentence that immediately states the action and resource, then enriches with record contents and a documentation link. No wasted 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?
For a no-argument, read-only list operation with no output schema, the description is sufficient. It names the resource, indicates the kind of data returned, and points to documentation for further details. An agent can confidently invoke this tool.
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 has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and it adds useful context about what the returned records contain.
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 a specific verb ('List') and resource ('Longhorn node records') and adds meaningful detail about record contents. It does not explicitly distinguish this from sibling node_get, though the plural resource makes the contrast reasonably clear.
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?
Usage context is implied by the name and description: this is for listing node records, not getting a single node or updating node state. However, it does not explicitly state when to prefer this over node_get or provide exclusions, leaving the agent to infer from naming conventions.
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 behavioral burden. The verb 'Get' conveys a non-mutating read operation, and the documentation link adds useful external context. However, the description does not disclose error behavior, id format expectations, or any special orphan cleanup semantics beyond the bare operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence followed by a documentation link. Every element earns its place: the sentence states the operation and scope, and the link provides supplementary context without bloat.
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?
This is a simple get-by-id operation with one parameter and no output schema. The description is sufficient for an agent to select and invoke the tool correctly; the external docs link fills any deeper context about orphaned data cleanup. It does not describe the return structure, but that is not necessary for invocation.
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 should compensate. The phrase 'by id' confirms the id parameter selects the orphan record, which is somewhat helpful, but it adds little beyond the schema's own property name 'id' and the tool name. There is no extra detail on id format or accepted values.
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 a specific verb ('Get'), names the exact resource ('orphan record'), and scopes the operation to a single record identified by id. This clearly distinguishes it from sibling tools like orphan_list and other getters by specifying the object type and uniqueness.
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 clearly implies usage: call this when you have a specific orphan record id and want that one record. It does not explicitly name alternatives such as orphan_list for enumeration, but the 'single ... by id' phrasing gives sufficient contextual guidance for this simple tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 'List ... Longhorn has detected' implies a read-only report of pre-existing state rather than an active scan, and the doc link adds useful feature context. However, it never explicitly states that the operation is side-effect free, what the response contains, or that no cleanup is triggered.
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?
A single front-loaded sentence states the verb and resource immediately, followed by a relevant official doc link. Every element earns its place and there is no filler or redundant restatement of the title.
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?
For a zero-parameter list tool with no output schema and no annotations, the description is nearly complete: it names the resource type precisely and links to documentation on orphaned-data cleanup. The only gaps are an unstated response shape and an explicit read-only guarantee, but nothing an agent needs in order to select and invoke it correctly is absent.
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 has zero parameters (coverage is vacuously 100%), and the description correctly adds no parameter detail since none exist. Per the zero-parameter baseline, a 4 is appropriate; nothing is missing or unexplained.
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 a specific verb ('List') and a precise resource ('orphaned replica/engine instance directories'), adding the scope qualifier 'Longhorn has detected'. This clearly distinguishes it from the only related sibling, orphan_get, and from all other list tools by naming a unique resource.
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?
No explicit when-to-use or when-not-to-use guidance is provided; the description never contrasts with orphan_get or other listing tools. The doc link offers background context rather than selection criteria, so usage is only implied: this is the read-only report of orphans Longhorn has already detected.
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 behavioral burden. 'Get' implies a read-only operation with no destructive side effects, which is helpful but not explicit. It does not disclose behavior such as whether a missing job returns an error or what the response contains.
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 one clear, front-loaded sentence plus a documentation link. Every part earns its place, and nothing is redundant or padded.
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?
For a simple one-parameter get operation, the description is adequately complete: it states what is fetched and by what key, and it provides a docs link. It lacks return format or not-found behavior, but those are minor for this straightforward read action.
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. The phrase 'by name' confirms that the required 'name' parameter is the recurring job identifier, but it adds little beyond the parameter name itself and offers no format or uniqueness details.
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 states a specific action and resource: 'Get a single recurring job by name.' It clearly distinguishes this from the sibling list/create/update/delete tools by emphasizing 'single' and 'by name.' The title is reinforced without being merely 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 phrase 'by name' gives clear retrieval context: this is the tool to use when you already know the recurring job's name and need one object. It does not explicitly name alternatives like recurringjob_list or state when not to use it, so it falls short of the top score.
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 behavioral burden. 'Get' clearly implies a read-only operation with no side effects, but the description does not disclose expected response shape, error behavior, or whether a missing setting produces an error vs empty result. This is adequate but has gaps.
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 front-loaded sentence that states the verb, resource, and lookup key, followed by a relevant documentation link. Every part earns its place with 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?
For a one-parameter get operation, the description is nearly complete: it names the resource, identifies the input parameter, and links to authoritative docs. The only notable omission is not describing the return value, but the operation is simple enough that an agent can likely infer success by the response.
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 a required 'name' string with no description, and schema description coverage is 0%. The tool description at least clarifies that 'name' refers to a Longhorn setting name and gives a documentation link for valid names, but it does not provide concrete examples or enumerate valid setting names. This partially compensates for the schema 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 specific action ('Get a single Longhorn setting by name') and the resource ('Longhorn setting'), which immediately distinguishes it from siblings like setting_list (list all settings) and setting_update (modify a setting). The inclusion of the Longhorn docs link further anchors the resource.
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 clearly implies usage: call this when you need one specific setting and already know its name, versus setting_list for enumerating settings or setting_update for modifying. It does not explicitly name alternatives or state when-not-to-use, so it misses the highest bar, but for a simple get-by-name tool the context is clear.
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 clearly states that this is a simple list operation and provides a useful documentation link, but it does not describe output shape, pagination, or other behavioral details. For a read-only list with no parameters, this is minimally adequate.
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 one clear, front-loaded sentence followed by a helpful documentation link. Every word earns its place, and there is no 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 the low complexity of a zero-parameter list operation and no output schema, the description is mostly sufficient: it names the exact resource and scope. The documentation link provides additional context, though the description could explicitly mention that the return value is a list of settings.
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, so the baseline is 4. The description does not need to explain parameter semantics because there are none to document.
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 a specific verb ('List') and resource ('all Longhorn global settings'), making the tool's purpose immediately clear. It also distinguishes itself from sibling tools like setting_get and setting_update by emphasizing 'all' global settings.
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 that this tool is for enumerating all settings rather than retrieving or updating a single one, but it does not explicitly tell the agent when to use it versus setting_get or setting_update. No exclusions or alternative guidance is provided.
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 clearly discloses that the operation is destructive, can affect every volume in the cluster, and specifically calls out the danger-zone category. It also links to reference docs for further detail, which exceeds minimal behavioral disclosure.
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 compact paragraph with no filler. Each sentence earns its place: the action, the global/destructive warning, the explicit authorization gate, and the docs reference. The key action is front-loaded.
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 description covers the safety-critical aspects well: destructiveness, authorization requirement, and global impact. However, for a tool with zero schema parameter descriptions and no output schema, it lacks operational detail like how to determine valid setting names and value formats. The docs link partially compensates but is not a substitute for upfront semantics.
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 compensate. It only loosely implies that 'name' is the setting key and 'value' is the new value; it does not explain accepted value formats, valid setting names, or how values are serialized. The docs link helps but does not provide inline 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 action: 'Update a Longhorn global setting value.' The word 'global' distinguishes this from the sibling volume_update_setting, which targets per-volume settings. The resource and operation are 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 gives explicit when-not-to-use guidance: 'Do not call this unless the user has explicitly authorized it in this conversation — never proactively, speculatively, or as a side effect of another task.' It also flags destructive impact. It does not explicitly name sibling read-only tools like setting_get/setting_list as safer alternatives, so a small gap remains.
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 behavioral disclosure burden. It adds useful context beyond the title by flagging the feature as experimental and explaining what shard groups are, and the 'List' verb implies a read-only enumeration. It does not mention return format, pagination, or ordering, but for a zero-parameter read-only list tool the risk surface is small.
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?
A single front-loaded sentence states the operation first, then adds the defining parenthetical, the experimental caveat, and a documentation link. Every clause earns its place and there is no redundant filler.
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?
For a zero-parameter list tool with no output schema, the description covers the resource identity, the domain context (V2 data engine sharding), the experimental status, and provides a docs link for deeper reference. The only gap is lack of detail on the return shape or volume of results, which is minor for a simple enumeration.
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, so the baseline is 4 and there is no parameter semantics to document. The description still adds value by specifying exactly what entity is being enumerated, which is all an agent needs to call this tool correctly.
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 a specific verb-resource pair ('List shard groups') and expands it with a precise definition ('erasure-coding sets of shards') and scope ('backing V2 data engine sharded volumes'). This clearly distinguishes it from siblings like shard_list (lists shards, a different granularity) and shardgroup_get (fetches one group, not a list).
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?
Usage context is implied by the 'List' verb and the sibling naming pattern ('shardgroup_get' vs 'shardgroup_list', 'shard_list' vs 'shardgroup_list'), so an agent can infer this is for enumerating shard groups rather than fetching one or listing shards. However, there is no explicit when-to-use statement or contrast with alternatives, leaving selection to inference.
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 behavioral burden. It adds useful context about erasure-coded shards and the experimental nature of the feature, but it does not explicitly confirm read-only behavior, response format, or pagination 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 focused sentence followed by a documentation link. It front-loads the core purpose and avoids any filler 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?
For a simple 0-parameter list operation, the description is mostly complete: it identifies the resource, scope, and experimental status, and links to docs. It does not describe the return shape, but the list operation and provided documentation mitigate this.
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 the schema coverage is 100%, so there are no parameter semantics to explain. The baseline for 0-parameter tools is 4, and the description adds no unnecessary parameter commentary.
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 states a specific verb and resource: 'List erasure-coded shards backing V2 data engine sharded volumes'. It clearly differentiates from sibling tools like shard_get and shardgroup_list by scope and object type, and flags the feature as experimental.
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?
Usage context is implied through the phrase 'backing V2 data engine sharded volumes', and the tool name contrasts with shard_get/shardgroup_list. However, the description does not explicitly state when to use this tool versus alternatives or provide 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It accurately states the operation is a list of generated bundles, which implies a read-only, non-destructive action. However, it does not disclose return format, pagination, or whether only metadata is returned; the documentation link partially compensates for this gap.
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, front-loaded sentence that states the action and resource immediately, followed by a documentation link. There is no filler or redundancy; every element 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?
Given the tool's low complexity—zero parameters and no output schema—the description is nearly sufficient on its own: it identifies the action, resource, and a documentation reference. It lacks an explicit note about return shape, which is a minor gap for a simple list operation, and the attached docs help fill that context.
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 is an empty object with zero parameters, so there are no parameter semantics for the description to document. Per the rubric, a zero-parameter tool receives a baseline of 4, and the description appropriately contains no parameter-specific information.
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 precise verb 'List' with a specific resource, 'generated Longhorn support bundles,' immediately distinguishing this from get, create, delete, and update operations among siblings. The qualifier 'generated' clarifies that it returns existing bundles only, and the linked Longhorn docs further define what a support bundle is.
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?
There is no explicit guidance about when to use this tool versus alternatives, such as supportbundle_get for retrieving a single bundle. However, the usage is reasonably implied by the action: if the agent needs to enumerate existing generated bundles, this is the tool. No misleading guidance is present, but no exclusions or alternative routing are offered.
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?
There are no annotations, so the description must convey behavioral expectations. 'List' semantically suggests a read-only operation, and the included Longhorn docs URL offers some external behavioral context. However, the description itself does not disclose output shape, pagination, failure modes, or any specific 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 a single, front-loaded sentence that states the purpose and then provides a helpful documentation link. Every element earns its place, and there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list operation, this is nearly complete: it names the resource and provides authoritative documentation. The only notable omission is a direct description of the return value, but the docs link mitigates that gap.
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 has no properties, so there are no parameters to document. With zero parameters, the schema coverage is trivially complete and the description does not need to compensate for missing parameter meaning.
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 names a specific verb ('List') and a specific resource ('Longhorn system backups'), so an agent immediately knows what the tool does. It is also distinguishable from sibling tools like systembackup_get, systembackup_create, and systemrestore_list by action and resource.
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 action 'List' implies when to use the tool, but the description gives no explicit guidance about when to prefer this over systembackup_get or other backup-related tools. There are no exclusions or alternative routing hints beyond the obvious resource name.
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 full burden and clearly discloses that the operation is 'Destructive' and restores 'cluster-wide Longhorn state,' which implies overwrite of current state. It also adds an operational guardrail about explicit user authorization. It does not detail exactly what state is affected or return behavior, but for a destructive operation the key warnings are present.
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 sentences, front-loaded with purpose and scope, then safety guardrail, then a reference doc link. No filler; every sentence contributes.
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 description covers purpose, destructive nature, authorization, and provides a documentation link, but leaves parameters unexplained and return behavior unspecified. Given no output schema or parameter descriptions, the tool definition is somewhat incomplete for safe invocations.
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 coverage is 0% and the description does not explain the two required parameters (`name`, `systemBackup`). It references 'a system backup' but never maps that to `systemBackup` nor clarifies what `name` should be. An agent cannot reliably populate the args from this description alone.
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 states a specific verb ('Restore'), a resource ('Longhorn system'), and the scope ('cluster-wide Longhorn state'), distinguishing it from related sibling tools like systemrestore_delete or systembackup_create. The title is somewhat generic, but the description clarifies 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?
Provides explicit authorization gate: 'Do not call this unless the user has explicitly authorized it in this conversation — never proactively...' This gives clear context for when the tool is appropriate. It does not name alternative tools or explicitly contrast against them, but the restore semantics are unambiguous within the sibling set.
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 behavioral disclosure burden. 'List' reasonably conveys a read-only, non-destructive operation, but the description does not add details such as whether results are paginated, ordered, or filtered, or what the response shape is. The docs link is useful but does not explicitly state those behaviors.
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 short sentences with the core action front-loaded and only an authoritative docs link appended. There is no redundant phrasing, filler, or repeated schema content. Every word 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?
For a zero-parameter list operation with no output schema, the description plus docs link is largely complete: it identifies what the tool acts on and where to find deeper reference material. It does not explicitly state that the result is a collection, but 'List' strongly implies that, making this a minor rather than blocking gap.
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 defines zero parameters, so there is nothing the description needs to explain about parameter meaning or formats. The zero-parameter baseline applies here, and the description correctly focuses on the operation rather than inventing unnecessary parameter detail.
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 states a specific verb ('List') and a specific resource ('Longhorn system restore operations'), making the tool's purpose unambiguous. It is clearly distinguishable from sibling tools such as systemrestore_get, systemrestore_create, and systemrestore_delete. The Longhorn docs link reinforces the domain context without adding ambiguity.
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 verb 'List' implies this tool should be used for enumerating system restore operations, and sibling names imply alternatives for single-item operations. However, the description does not explicitly say when to use this tool versus systemrestore_get or systemrestore_create, nor does it provide exclusion conditions. The docs link is reference material, not decision guidance.
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 behavioral burden. Get clearly signals a read-only retrieval with no mutation or destructive side effects. It does not cover failure behavior like not-found errors, but the core safety trait is adequately disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The action, resource, and retrieval key are all front-loaded, 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is low complexity with one required parameter, no nested objects, and no output schema. The description covers the essential invocation details. It omits mention of alternatives or error cases, but those are secondary for a simple getter.
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 percent, so the description must compensate. The phrase by name clarifies that the name parameter is the record identifier, but it adds no detail about format, uniqueness, or how the name relates to the VolumeAttachment resource. This is adequate but minimal.
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 a specific verb, Get, a specific resource, VolumeAttachment record, and a retrieval scope, by name. It clearly distinguishes this single-record lookup from the sibling volumeattachment_list tool.
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 phrase single VolumeAttachment record by name implies this tool is for individual lookups rather than listing. However, it never explicitly names the list alternative or states when to prefer one over the other, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. 'List' clearly signals a read-only operation, and the docs link adds reference context, but the description does not disclose return shape, pagination, or error 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 a single information-dense sentence followed by a relevant documentation link. There is no redundancy, and the core purpose is front-loaded.
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?
For a one-parameter, read-only list operation with no output schema, the description provides enough information to reason about correct invocation. The docs link covers additional operational depth, but an explicit note about the response shape would have made it 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?
The input schema's `name` has no description and 0% schema coverage, so the description's 'attached to a volume' is what maps the sole parameter to a volume identifier. This is clear enough for an agent to populate `name` correctly, though not as explicit as a dedicated parameter comment.
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 states a specific action ('List') and a clearly scoped resource ('recurring jobs attached to a volume'), which distinguishes it from the global recurringjob_list sibling. The title reinforces the same purpose without ambiguity.
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 usage context by focusing on volume-scoped recurring jobs, but it does not explicitly state when to choose this over recurringjob_list or how it relates to volume_recurring_job_add/delete. The Longhorn docs link provides external context but no direct selection guidance.
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 behavioral burden. It discloses that creation is destructive, that downloads occur server-side from Longhorn's own network position, and that URLs must be trusted. It could specify more concretely what 'destructive' impacts, but the warning is substantive and actionable.
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 concise, purposeful sentences: the core action, the critical URL behavior, the authorization guardrail, and a doc link. No filler or repetition; safety-critical information is front-loaded early.
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?
For a risky create operation with no annotations and no output schema, the description covers the essential behavioral and authorization context and provides a documentation link. It does not enumerate all sourceType variants, but the schema lists examples and the doc link fills remaining 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 coverage is 75%, and the description adds value by explaining the meaning of parameters.url for sourceType 'download' and the trust implication. This goes beyond the schema's generic example and helps the agent construct valid, safe calls.
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 creates a new backing image, which is a specific verb+resource. It does not, however, differentiate from the sibling backingimage_upload or backingimage_backup_create, leaving the exact boundary between create and upload implicit.
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 gives explicit safety guidance: only use a 'download' sourceType URL the user has explicitly provided and trusted, and never call without explicit user authorization. It lacks an explicit comparison to alternatives like upload, but the when-not-to-use guidance is strong.
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 provided, so the description carries full responsibility, and it succeeds: it labels the call Destructive, discloses read-merge-write semantics vs full-replace PUT, and warns that evictionRequested:true drains replicas/backing images. This is exactly the behavioral disclosure an agent needs before invoking a mutation.
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?
Action, examples, merge behavior, dangerous side effect, and safety warning are front-loaded in a compact sequence. No filler; each sentence adds necessary operational information.
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?
For a destructive 4-parameter mutation with no annotations and no output schema, this is nearly complete: safety, side effects, merge semantics, and docs link are present. It still omits expected return value and any conditions like node existence or permissions, so it is not fully 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 has no property descriptions (0% coverage), so the description must compensate. It identifies three relevant fields and explains evictionRequested's serious side effect, but does not define allowScheduling or tags, and name is only implied. Partial compensation only.
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?
States a clear verb ('Update') and a specific resource ('Longhorn node record'), with examples of targeted fields (allowScheduling, evictionRequested, tags). It clearly separates from list/get siblings but does not explicitly contrast with node_disk_update, so sibling differentiation is partial.
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?
Gives strong context for when the tool is appropriate by requiring explicit user authorization and prohibiting proactive/speculative calls. Does not name sibling alternatives (e.g., node_get for reads, node_disk_update for disk settings), so alternative routing is left implicit.
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 burden and it explicitly labels the operation 'Destructive.' It also adds the important policy that the tool must not be invoked proactively or as a side effect, which goes beyond the schema and title.
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 short sentences: function first, destructive warning second, documentation link last. The most critical information is front-loaded and 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?
For a one-parameter destructive delete with no output schema, the description covers the action, safety, authorization, and provides a documentation link. It is solid but stops short of noting behavior for nonexistent jobs or clarifying the distinction from volume-scoped recurring job deletion.
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 the 'name' parameter's format, source, or behavior when the job does not exist. The phrase 'a Longhorn recurring job' implies the name identifies the job, but the description does not compensate for the missing schema-level parameter 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?
States a concrete action and object: 'Delete a Longhorn recurring job.' This clearly identifies the verb, resource type, and platform, and distinguishes it from sibling recurringjob_create/update/get/list operations.
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?
Provides an explicit authorization gate: 'Do not call this unless the user has explicitly authorized it in this conversation — never proactively, speculatively, or as a side effect of another task.' This is strong when-not guidance, but it does not name alternatives such as volume_recurring_job_delete for volume-scoped removal.
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 explicitly marks the operation as 'Destructive' and adds the critical authorization constraint. It could go further by describing what is irreversibly removed, but the destructive flag and safety warning are substantial.
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 brief, front-loads the core purpose, then delivers a critical safety warning, then provides a documentation link. Every sentence earns its place with no filler.
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 description covers purpose, destructive nature, and authorization constraints, but it leaves parameter semantics unexplained and does not describe the result or side effects on the backing image. Since there is no output schema and no annotations, a more complete definition would define the two required parameters explicitly.
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 compensate for the missing parameter meaning. It gives a vague hint via 'on the given disks' for the disks parameter, but it never defines what 'name' refers to or how disks should be specified. An agent cannot confidently resolve parameter semantics from this text alone.
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 a specific verb ('Clean up') with a specific resource ('backing image file copies') and scope ('on the given disks'). This clearly differentiates it from sibling tools like backingimage_delete, which would target the backing image itself rather than copies on specific disks.
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 provides explicit authorization requirements: 'Do not call this unless the user has explicitly authorized it in this conversation — never proactively, speculatively, or as a side effect of another task.' This gives strong, unambiguous guidance on when the tool may be invoked.
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 must carry the behavioral disclosure itself. It explicitly labels the operation as 'Destructive' and forbids unprompted use, which is the critical safety-relevant behavior. It does not detail failure modes or side effects on volumes using the image, but the essential risk is clearly stated and supported by a documentation link.
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 terse sentences: the action, the destructive warning, and the documentation reference. The critical information is front-loaded and 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?
For a one-parameter delete tool, the description covers the action, the destructive risk, and the authorization rule, and links to detailed docs. It does not describe return values or downstream consequences, but those are less critical given the explicit destructive warning.
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 parameter meaning. Saying 'Delete a backing image' implicitly identifies `name` as the target resource, but the description never explicitly defines `name` as the unique identifier or explains the expected format.
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 object: 'Delete a backing image.' This clearly distinguishes it from sibling operations like backingimage_list, backingimage_get, and backingimage_create, and matches the title exactly.
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 gives an explicit authorization gate: 'Do not call this unless the user has explicitly authorized it in this conversation — never proactively, speculatively, or as a side effect of another task.' This is strong context for when deletion is permitted, though it does not compare this tool to related maintenance alternatives like backingimage_cleanup.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'List' implies a read-only operation and the scope is stated, but the description does not mention whether a backup target must be configured, what fields are returned, or any pagination/ordering 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 a single, front-loaded sentence that states exactly what the tool does, followed by a helpful documentation link. There is no redundancy or filler.
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?
For a zero-parameter list tool with no output schema, the description is mostly complete: it names the resource and the scope. It does not explain the response format or prerequisites like a configured backup target, but the documentation link helps fill that gap.
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 has zero parameters, so the baseline is 4. There is no parameter semantics needed, and the description's focus on the resource and scope is sufficient for a parameterless list operation.
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 a specific verb ('List') and a specific resource ('backed-up backing images on the backup target'). It clearly distinguishes this tool from the sibling 'backingimage_list', which lists backing images without the backup-target qualifier.
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 gives clear context: this tool is for listing backing images that have been backed up to a backup target. It does not explicitly name alternatives or exclusion criteria, but the scope is specific enough for an agent to select it appropriately.
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 behavioral disclosure burden. It clearly states 'plain read-only GET' and notes availability in '--read-only mode', which transparently indicates the operation has no side effects. It could go further by describing not-found behavior or response shape, but the read-only disclosure is meaningful.
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 extremely concise: one main clause plus a useful parenthetical and a docs link. No filler words. The key identifying information is front-loaded, and the documentation reference is placed at the end without disrupting readability.
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?
For a one-parameter read-only GET with no output schema and no annotations, this description is reasonably complete. It states what is retrieved, how it is retrieved, and points to official documentation. It could mention response contents or 404 behavior, but the docs link partially compensates for those omissions.
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 only parameter is id, and schema description coverage is 0%. The description clarifies that the id identifies a single backup, matching the field name. It does not add detail about the id format or how to obtain valid ids, but for a single simple parameter this is minimally adequate.
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 states a specific verb and resource: 'Get a single backup by id'. It also clarifies the operation is a plain read-only GET, which distinguishes it from mutation-style backup operations in the sibling list. This is clear, specific, and unlikely to be confused with list-based backup tools.
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 clearly implies this tool is for retrieving one backup when an id is known, and its read-only nature is explicitly noted. It does not explicitly name backup_list or other sibling tools as alternatives for listing, but the 'single backup by id' wording gives sufficient contextual guidance.
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 explicitly labels the operation 'Destructive' and requires explicit user authorization, which are essential behavioral traits for a delete action. It does not detail irreversibility or downstream effects on backups, but the warning is strong and clear.
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 short sentences with the core operation first, followed by the safety warning and a documentation link. Every sentence earns its place, and there is 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?
For a one-parameter destructive tool with no annotations and no output schema, the description covers the operation, the destructive nature, the authorization requirement, and points to documentation for further detail. It could explicitly state permanence or effects on backups, but the provided context is sufficient for an agent to act cautiously.
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%, and the description does not explain the `name` parameter. However, the single parameter is reasonably self-evident from context: 'Delete a backup target' implies `name` identifies the target to delete. It adds no extra format or constraints, but ambiguity is low.
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-object pair, 'Delete a backup target,' which clearly states the operation and distinguishes it from sibling tools like backuptarget_update, backuptarget_sync, and backuptarget_create. This is unambiguous and directly matches the tool title.
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 an explicit when-not condition: call only with explicit user authorization in the conversation, never proactively, speculatively, or as a side effect. It does not name sibling alternatives, but for a destructive delete the authorization guardrail is the critical usage guidance.
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 burden of behavioral disclosure. It clearly states the write-access requirement, the volume-scoped nature, and provides a docs link. It does not mention error behavior or whether the operation has side effects, but 'list' plus the access caveat covers the most important behavioral trait.
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?
Two concise sentences with the core purpose front-loaded, followed by a clear caveat and an alternative plus a docs link. No redundant filler.
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?
For a single-parameter list tool with no output schema, the description covers purpose, auth requirements, and provides a reference link. The main gaps are lack of explicit parameter definition and a missing distinction from the similar 'backupvolume_backup_list_by_volume' sibling, but overall it is sufficiently 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?
The schema has one required 'name' parameter with no description, and schema description coverage is 0%. The description implies that 'name' refers to the backup volume, but it never explicitly states the parameter's meaning or expected format. This is inferable but not fully specified.
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 states a specific verb and resource: 'List backups belonging to a backup volume via the volume-scoped action.' This clearly distinguishes the tool from generic backup listing and other siblings. The title reinforces the resource scope.
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 explicitly names an alternative ('use backup_list for read-only introspection') and gives a condition ('requires write access'). However, it does not disambiguate from the closely named sibling 'backupvolume_backup_list_by_volume', so guidance is strong but not complete.
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 discloses a critical behavioral trait: 'Fields you omit are left unchanged (read-merge-write under the hood — the API itself does a full replace on PUT).' This goes beyond the bare operation and helps an agent understand that the tool preserves omitted fields, which is not obvious from the name or schema. With no annotations provided, this disclosure carries significant weight. It does not cover potential side effects or permissions, but the merge behavior is the key risk area.
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 action, the second explains the key behavior, and the docs link adds a resource. No redundant filler exists, and every sentence contributes 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?
For a simple two-parameter update tool with no output schema, the description covers the essential usage nuance (read-merge-write) and provides a docs link for deeper context. It does not explain return values or permissions, but for an update operation these are not critical. The sibling list is vast, yet the description adequately separates this from other backupvolume_* tools without requiring extra context.
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 meaning beyond the schema by explaining that omitted fields are preserved, which directly informs how the 'extra' object should be constructed for partial updates. The schema already describes 'extra' as merged verbatim, but the description augments this with the merge behavior. The 'name' parameter remains undocumented in both schema and description, though its role as identifier is intuitive from the resource context.
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 states a specific verb and resource: 'Update a backup volume record.' This clearly distinguishes it from sibling tools like backupvolume_delete, backupvolume_list, and backupvolume_sync by specifying the update action on the backup volume resource. No ambiguity remains about what operation the tool performs.
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 modifying an existing backup volume record, contrasting with delete or sync siblings, but does not explicitly state when to prefer this over alternatives. The read-merge-write detail hints that partial updates are intended, yet no explicit when-to-use or exclusion guidance is provided.
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 and discloses that the operation is 'Destructive' and that 'image is not validated against a known-good list.' These are meaningful behavioral warnings beyond what the schema conveys.
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 well-structured: it states the action first, then adds the crucial validation warning, the destructive warning, the explicit authorization requirement, and a docs link. Every sentence adds value with no fluff.
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?
For a single-parameter, mutation-only tool with no output schema and no annotations, this description is nearly complete: it covers purpose, safety, validation behavior, authorization requirements, and provides docs. It does not describe the result or postconditions of deployment, but the included warnings and docs mitigate that gap.
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 provides no description for the required 'image' parameter, and the tool description does not explain its format or expected value. However, the description's opening sentence identifies 'image' as a Longhorn engine image, and the warning that it is not validated adds partial semantic context.
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 'Deploy a new Longhorn engine image,' giving a specific verb and resource. This distinguishes engineimage_create from siblings like engineimage_list, engineimage_get, and engineimage_delete, which are all read-only or different operations.
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 gives strong usage guidance: 'Do not call this unless the user has explicitly authorized it in this conversation — never proactively, speculatively, or as a side effect of another task.' This clearly defines when the tool may be used, though it does not mention alternative tools for related actions.
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. Mentioning 'GET /v1/schemas' clearly signals a read-only introspection call, and 'self-described at runtime' conveys that the data is dynamic rather than static. It does not discuss auth or other edge cases, but for a zero-parameter list operation this is sufficient.
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?
Single sentence, front-loaded with the exact scope, and no filler. The endpoint detail earns its place because it tells the agent how the list is self-described at runtime.
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?
For a zero-parameter discovery tool with no output schema, the description identifies the data source and the full scope of result. It does not spell out the response shape, but the tool name plus description provide enough to invite correctly.
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 100% schema coverage, so the schema is already complete and there is little for the description to add. The baseline for zero-parameter tools is 4; the description does not undermine 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 states a specific verb ('List') and resource ('every resource type Longhorn's manager API exposes'), making the action unambiguous. It is clearly distinguished from siblings like longhorn_list_tags and longhorn_describe_resource_type.
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 makes clear this is a top-level discovery call, but it does not explicitly say when to prefer it over longhorn_describe_resource_type or longhorn_raw_request. Usage context is implied by 'every resource type' and the GET /v1/schemas endpoint, but not explicitly spelled out.
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 exist, so the description carries the full burden of behavioral disclosure. It explicitly labels the operation 'Destructive' and forbids unsanctioned use, which clearly communicates the risk profile. It stops short of describing exactly what is affected or whether the deletion is reversible, but it covers the critical safety 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?
Three sentences, all substantive: purpose, destructive warning, and documentation link. No filler or repetition of schema details. The most important safety information is front-loaded immediately after the purpose statement.
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?
For a one-parameter destructive delete operation, the description includes the essential safety warning and a documentation link. It is mostly complete, but it could be slightly stronger by noting that the deletion is permanent and that valid backup names can be found via systembackup_list. These are minor gaps for such a simple 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 schema has a single 'name' parameter with no description, and the description does not explicitly state that 'name' refers to the system backup's identifier or how to obtain valid names. The meaning is inferable from context, but the description adds little beyond what the parameter name already implies.
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 states a specific verb and resource: 'Delete a Longhorn system backup.' This clearly distinguishes it from sibling tools like systembackup_list, systembackup_get, and systembackup_create. The purpose is unambiguous and immediately actionable.
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 when-not guidance: do not call unless the user has explicitly authorized it, and never proactively, speculatively, or as a side effect. It does not name alternatives, but for a destructive operation the authorization constraint is the most important routing information.
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 explicitly flags the operation as 'Destructive' and reinforces the risk with a strict authorization prerequisite, plus a documentation link for context. It does not discuss reversibility or cascade effects on related resources, but the central destructive trait is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences plus a documentation link, with purpose front-loaded and the destructive warning placed immediately after. Every sentence earns its place; there is no filler or repetition of schema information.
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?
For a one-parameter destructive delete with no annotations and no output schema, the description covers the essential invocation context: what is deleted, that it is destructive, when it may be called, and where to find reference documentation. The main gaps are the undocumented 'name' parameter and the lack of routing to related list/get tools, but the critical safety context is 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. It does not explicitly describe the 'name' parameter, but the main clause implies that 'name' identifies the system restore record to delete, which gives the bare string type some semantic grounding. The compensation is partial rather than explicit, hence a 3.
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?
States a specific verb and resource: 'Delete a Longhorn system restore record.' This precisely identifies the operation and entity, and clearly distinguishes it from sibling tools like systemrestore_create, systemrestore_list, and systembackup_delete. Adding 'Longhorn' and 'record' removes ambiguity present in the bare title 'Delete system restore.'
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?
Provides an explicit gate for use: 'Do not call this unless the user has explicitly authorized it in this conversation.' It also excludes proactive, speculative, and side-effect invocation. It does not name alternative tools (e.g., systemrestore_list to find records first), so it falls just short of full when/when-not/alternative routing.
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 clearly labels the operation as 'Destructive' and adds an explicit authorization requirement, which is valuable. It does not detail consequences like data loss or reversibility, but the warning and doc link provide meaningful context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, purposeful sentences: the core action, a blunt destructive warning, and a clear authorization gate. Every sentence earns its place and the most critical safety information is front-loaded.
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?
For a simple two-parameter destructive operation, the description gives the essential safety context and a doc link, but it lacks enough parameter detail to confidently invoke the tool without additional lookup. No output schema exists, and the 0% schema coverage means the description should have compensated further.
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 coverage is 0%, and the description only vaguely maps 'volume' and 'specific replica' to the two parameters name and replicaName. It does not explain what replicaName is, how to obtain it, or any format/constraints, so an agent is left guessing about the exact value required.
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 states a specific action ('Remove a specific replica') and its resource ('from a volume'), clearly distinguishing this from sibling tools like volume_delete or volume_engine_upgrade. The title reinforces the same clear operation.
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 provides strong, explicit usage guidance: it is destructive, must not be called without explicit user authorization in the current conversation, and must never be used proactively or as a side effect. No alternative tools are needed for this clear destructive operation.
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 explicitly flags the operation as 'Destructive' and warns that replica names may be 'potentially stale,' which is meaningful risk context. It stops short of explaining exactly what is destroyed or whether the operation is irreversible, but it gives a clear safety warning.
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 short and front-loaded: the core action comes first, the destructive warning second, and a docs link last. Every sentence contributes. The docs URL is somewhat long and may not be salvage-specific, but the overall structure is efficient and readable.
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 description covers the essential warning and gives a docs pointer, but it omits operational preconditions such as whether the volume must be in a failed/detached state, what exactly happens to the volume, and what the response indicates. For a destructive tool with no annotations and no output schema, a bit more operational context would make it more 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 maps replicaNames to the 'list of (potentially stale) replica names' and implies that 'name' identifies the volume being salvaged. This adds meaning beyond the bare string/array types in the schema, though it could explicitly name the parameters.
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 a specific verb ('Salvage') and a specific resource ('a volume'), and further narrows the action by saying it operates 'from a list of (potentially stale) replica names.' This clearly differentiates it from siblings like volume_delete or volume_replica_remove, and there is no other salvage tool in the sibling list.
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 gives strong when-not guidance: 'Do not call this unless the user has explicitly authorized it in this conversation — never proactively, speculatively, or as a side effect of another task.' This is explicit usage context, though it does not mention alternative tools or conditions that would make a sibling more appropriate.
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 burden of disclosing behavioral traits. It discloses the non-obvious write-access requirement and identifies the action as volume-scoped, which is important context for invocation. It does not describe response shape or error behavior, but for a simple get operation this is a strong level of transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core action and scope, then adds the critical auth caveat and sibling alternative. The docs link is additional but useful. 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?
For a two-parameter tool with no output schema, the description is mostly complete: it identifies the resource, the volume-scoped context, the auth requirement, and the read-only sibling. The only real gap is the lack of explicit parameter role definitions, but the tool name and description together make the mapping reasonably inferable.
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 compensate. It only implies that 'backup volume' maps to name and 'specific backup' maps to backupName; it never explicitly states what each parameter means or what formats/values are expected. This is minimal semantic help.
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 states a specific verb and resource: 'Get a specific backup belonging to a backup volume via the volume-scoped action.' It also differentiates this tool from backup_get by explicitly mentioning the volume-scoped action and the write-access requirement, making its role among siblings clear.
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 clear usage direction: use this volume-scoped action, requires write access, and explicitly names backup_get as the alternative for read-only introspection. This is a concrete when-to-use vs. when-not-to-use signal.
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 present, the description carries the full burden of behavioral disclosure. It goes beyond the title by revealing the unexpected write-access requirement and by warning that this is not a read-only operation. A fuller description might include return behavior, but for a 'get' action the added auth context is meaningful.
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 and front-loads the key facts: what the tool does, the volume-scoped nature, the access requirement, and the sibling alternative. The docs link is brief and adds value without bloating the description.
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?
For a simple two-parameter get operation with no output schema, the description supplies the critical missing context: access requirements, scope, and a link to authoritative documentation. It only falls short by not spelling out parameter semantics, which is already accounted for in that dimension.
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 compensate, but it gives no explicit parameter definitions. The names 'name' and 'snapshotName' are suggestive, and the phrase 'of a volume' hints that one parameter is the volume, but an agent still has to infer the exact meaning of both fields.
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 states a specific verb and resource: getting one snapshot of a volume via a volume-scoped action. It also distinguishes itself from the sibling snapshot_get by noting the difference between the volume-scoped action and read-only introspection. An agent can clearly identify what this tool does and how it differs from similar snapshot 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?
The description explicitly says when to use this tool versus an alternative: this requires write access, while snapshot_get is for read-only introspection. That is direct, actionable guidance with no room for ambiguity.
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 of behavioral disclosure, and it does so well: it explicitly labels the operation 'Destructive,' states that deletion happens from the backup target, and imposes a strict authorization prerequisite. This tells the agent what is at risk and under what conditions the call 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the action comes first, then the critical destructive/authorization warning, then a reference link. Every sentence earns its place and there is no redundancy with the schema or title.
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?
For a one-parameter destructive operation with no output schema, the description is largely complete: it identifies the target, the destructive nature, and the authorization guardrail, and provides documentation. It does not explain how to discover valid names or what a successful call returns, but those are minor given the operation's simplicity.
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 input schema only defines required string `name` with 0% coverage, and the description does not explain the parameter's format or source. However, the context 'Delete a backup backing image' makes it reasonably inferable that `name` identifies which backup backing image to delete, and the single simple parameter limits 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 states a specific action and resource: 'Delete a backup backing image from the backup target.' This clearly distinguishes it from related tools such as backingimage_delete by specifying the backup-target scope, so an agent can tell what is being operated on without inspecting the schema.
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 gives an explicit when-not condition: it must only be called when the user has explicitly authorized it, never proactively or as a side effect. This is strong operational guidance for a destructive tool, but it does not point to alternative tools for discovery or restoration, such as backupbackingimage_list or backupbackingimage_get.
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 burden of behavioral disclosure. It clearly indicates the operation is read-only, uses a simple GET, and works in read-only mode. This is meaningful behavioral context beyond the tool name.
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?
Two concise sentences; the core behavior and read-only nature are front-loaded, and the documentation link is appended as a useful supplement. No redundant 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?
For a simple parameterless list operation, the description covers what it does, its read-only safety profile, and where to find more details. It does not describe the response shape, which could matter without an output schema, but the scope and operation are clear enough for correct invocation.
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?
There are zero parameters, so the schema provides no semantics to cover. The description adds useful scope context ('all backups across all backup volumes') and confirms no input is needed, which is sufficient for a parameterless 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?
States a specific verb and resource: 'List all backups across all backup volumes'. This clearly differentiates from siblings like backupvolume_list or backup_get by specifying scope ('across all backup volumes').
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 explains this is a plain read-only GET and explicitly says it is available in --read-only mode, which helps the agent know it is safe to invoke in constrained contexts. It does not explicitly compare to alternative backup-list tools, but the scope phrasing implies when this tool is appropriate.
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 richly: discloses read-merge-write under the hood, the API's full-replace PUT behavior, the consequence that repointing URL can break restore access, and flags the action as destructive. This goes well beyond minimal disclosure.
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 focused sentences: purpose first, then merge/replace nuance, then risk and authorization constraint. The documentation link adds value without bloat. 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?
Covers the critical decision factors: destructive nature, merge semantics, impact of repointing, and explicit authorization requirement. Lacks detail on return value and doesn't mention every parameter (e.g. maxBackupJobs), but for an update tool with a doc link this is nearly 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 only 20%, so the description needs to compensate. It explains the meaning and risk of backupTargetURL, credentialSecret, and pollInterval, and clarifies that omitted fields remain unchanged. However, it doesn't clarify the required 'name' parameter or 'maxBackupJobs', so not all parameters get 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?
States a specific verb and resource ('Update a backup target') and lists representative fields (backupTargetURL, credentialSecret, pollInterval), making it clear this is a settings-update tool. The merge semantics also distinguish it from backuptarget_update_name and create/delete siblings.
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?
Provides explicit when-not-to-call guidance: only with explicit user authorization, never proactively or as a side effect. Also explains when it applies (updating target settings). It doesn't name sibling alternatives like backuptarget_update_name, so it falls just short of full routing guidance.
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 present, the description carries the full safety burden and does well: it discloses read-only mode behavior, the safety of GET, and the destructive nature of POST/PUT/DELETE. It does not disclose response/error behavior or body-construction expectations, but the core behavioral risks are clearly communicated.
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 primary purpose and remains tight for the amount of safety-critical guidance it conveys. Each clause earns its place, and the message is direct without repeating the schema.
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 intentionally open-ended, so a fully deterministic description is impossible. The combination of schema and description gives enough to select endpoints and understand safety, though it could add a note about response shape or how to form the request body for non-GET calls.
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 already documents method, path, and a generic body object, with only 33% schema description coverage. The description adds meaningful method-level semantics by marking GET as safe and mutating methods as destructive, but it does not explain how or when to populate body beyond the generic 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 that this is an escape hatch for Longhorn API endpoints not covered by a named tool, which distinguishes it from the many sibling tools. The title and description together make the tool's purpose unambiguous: issue a raw request to the Longhorn API.
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 says to use this when an endpoint is not covered by a named tool, which sets the boundary with remaining siblings. It also gives clear usage constraints: GET is safe, mutating methods require explicit user authorization, and read-only mode rejects non-GET requests.
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 full weight and excels: it discloses the read-merge-write client-side behavior versus the server's full-replace PUT semantics, flags 'Destructive,' and warns that lowering `retain` can prune existing snapshots/backups beyond the new limit — a non-obvious side effect an agent would never infer from 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?
Front-loaded with the core action, then merge semantics, destructive flag, and authorization guard in order of decreasing importance. Every sentence earns its place; the docs link is a useful tail rather than a distraction.
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?
For a destructive mutation with 8 params, no annotations, and no output schema, this is nearly complete: safety profile, merge semantics, destructive side effects, and a documentation link are all present. It falls short of 5 only by not describing the return value or the outcome when the named job does not exist.
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 real meaning for `retain` (lowering it can prune snapshots/backups) and for all omitted fields (they stay unchanged), but it leaves cron format, task values, groups, labels, parameters, and concurrency unexplained; the docs link is the only pointer for those.
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?
States a specific verb and resource ('Update an existing Longhorn recurring job') where 'existing' distinguishes it from recurringjob_create. The scope is unambiguous and easily told apart from the sibling list/get/delete variants without opening the schema.
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?
Provides an explicit authorization gate — 'Do not call this unless the user has explicitly authorized it in this conversation — never proactively, speculatively, or as a side effect of another task' — which is strong when/when-not guidance. However, it never names sibling alternatives such as recurringjob_create for new jobs, so routing between related tools is left implicit.
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 and explicitly labels the operation as 'Destructive' and requires explicit user authorization. It could go further by describing irreversibility or data-loss consequences, but the safety-critical behavior is clearly disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: action, destructive warning, authorization condition, and a documentation link. Every sentence earns its place and there is no filler.
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?
For a single-parameter destructive operation, the description covers the safety precondition and points to documentation. It does not spell out what happens to the volume's data or dependent resources, but the simple input schema and clear intent make this adequate in context.
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 single required parameter `name` is not described in the text, and schema description coverage is 0%. However, the parameter's meaning is trivially inferable from the tool name and the one-string schema, so the lack of explicit compensation is a minor gap rather than a serious one.
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 begins with a clear, specific action: 'Delete a Longhorn volume.' This unambiguously distinguishes it from sibling volume tools like volume_create, volume_attach, or volume_snapshot_delete by naming the exact resource and operation.
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 provides explicit authorization guidance: do not call unless the user has explicitly authorized it, and never proactively, speculatively, or as a side effect. This is a strong when-not condition, and because deletion has no meaningful alternative tool, no alternative routing is needed.
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 disclosure burden and exceeds it: it flags 'Destructive,' reveals the specific consequence ('can remove the volume's only backup/snapshot schedule'), and mandates an authorization precondition. This is precisely the kind of risk information an agent needs to safely decide whether to invoke a destructive mutation, and it is delivered directly in the 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 compact and efficiently front-loaded: purpose and consequence in the first sentence, the destructive flag immediately after, then the authorization protocol, then a documentation link. Every sentence earns its place; the doc link adds reference value without bloating the core message.
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?
For a destructive mutation with no annotations, no output schema, and 0% schema coverage, the description covers the critical ground: what the tool does, its damaging side effects, and the authorization gate. The remaining gaps are minor — return value on success is unmentioned and the 'name' parameter is undefined — but these are secondary to the safety-critical information that is well covered.
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, and it partially does: the phrase '(or job group)' maps to the isGroup flag, explaining that jobName may refer to a group. However, it never defines what 'name' refers to (presumably the volume name but left ambiguous), nor does it clarify the distinction between name and jobName, so an agent must guess some 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 opens with a specific verb+resource pairing — 'Detach a recurring job (or job group) from a volume' — which precisely identifies the operation and its scope. It naturally distinguishes itself from siblings like volume_recurring_job_add and recurringjob_delete (the latter deletes the job definition itself rather than removing the volume association), and clarifies that both individual jobs and job groups are in scope.
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 a strong explicit when-not condition: 'Do not call this unless the user has explicitly authorized it in this conversation — never proactively, speculatively, or as a side effect of another task.' This gives clear context for when invocation is appropriate. However, it never names alternatives or explains when to prefer this tool over recurringjob_delete, volume_recurring_job_list, or volume_recurring_job_add, so it falls short of the full 5.
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?
There are no annotations, so the description carries the burden of behavioral disclosure. It surfaces a non-obvious behavioral fact: listing snapshots here requires write access and is volume-scoped. It does not describe output shape or error behavior, but for a list operation the key behavioral risk is addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words: the first packs scope, permission, and the alternative, while the second adds a documentation link. Key information is front-loaded.
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?
For a one-parameter list tool with no output schema, the description covers the access requirement, the correct alternative, and the volume-scoped behavior, and it links to documentation. The exact return format is left unstated, but this is a minor gap for a simple list operation.
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 a single `name` parameter with 0% description coverage, and the description does not explicitly state that `name` is the volume name. However, the phrase 'for a volume' plus the tool name makes the parameter's purpose reasonably inferable, adding only minimal semantic value 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 states a specific action ('List snapshots for a volume via the volume-scoped action') and clearly identifies the resource and scope. It also distinguishes this tool from the global snapshot_list, so an agent can tell them apart.
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 explicitly names the alternative `snapshot_list` and gives the selection condition: use it for read-only introspection. It also warns that this tool requires write access, giving direct when-to-use and 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.
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 and does well by explicitly stating it is a 'plain read-only GET' and safe for use in '--read-only mode.' It does not disclose return format or potential performance implications, but for a zero-parameter list operation this level of disclosure is strong.
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 short sentences with no filler. The core behavior and safety profile are front-loaded, and the documentation link is appended without disrupting the essential message.
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?
For a simple, parameterless read-only list tool, the description covers all the information an agent needs: what is listed, the scope, the safety profile, and where to find further documentation. No essential context appears to be missing.
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, so there is no schema to compensate for, and the description reinforces this by framing the operation as global ('all snapshots across all volumes') with no filtering options. Per the baseline for zero-parameter tools, this is appropriate.
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 states a specific verb ('List'), a precise resource ('all snapshots'), and a scope ('across all volumes'), which clearly distinguishes it from volume-scoped snapshot tools like volume_snapshot_list. The title and description together make the tool's function 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 clearly implies global snapshot listing across all volumes, which is distinct from per-volume snapshot tools, and explicitly notes it is available in read-only mode. It does not name alternatives or give a 'when not to use' rule, so it falls just short of the highest bar.
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 thoroughly: it declares 'Destructive,' discloses that 'image is not validated against a known-good list,' and states the failure consequence ('a bad image can make the volume inoperable'). This is exactly the behavioral context an agent needs before invoking a destructive mutation.
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 tight sentences, each earning its place: purpose, risk, destructive flag, and authorization rule, capped with a docs link. The key safety information is front-loaded before the parameter discussion.
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?
For a two-scalar-param destructive tool with no annotations, no output schema, and no enums, this description covers purpose, danger, validation gap, and the exact conversational consent required before invocation, plus a reference link. Nothing an agent needs to decide whether and how to call it safely is missing.
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 coverage is 0%, so the description must compensate. It adds real meaning to `image` (no known-good validation, risk of inoperability) and implies `name` identifies the target volume, but it does not specify expected formats (e.g., whether image is an image name or URL) or clarify `name` beyond the implication.
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?
States a specific verb and resource: 'Upgrade the engine image used by a volume.' This is distinct from sibling engineimage_create/update (which manage the image catalog) and volume_update_setting (which changes volume settings), so an agent can tell them apart without opening schemas.
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?
Gives explicit when/when-not conditions: only call when 'the user has explicitly authorized it in this conversation' and 'never proactively, speculatively, or as a side effect of another task.' It names no alternative sibling tool, but for a destructive operation the authorization guardrail is the critical 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 disclosure burden and meets it: it explicitly flags 'Destructive,' names the specific failure mode ('Disabling scheduling or shrinking storageReserved on a disk can strand replicas'), and imposes an authorization gate. This goes well beyond a generic destructive hint by telling the agent why and when harm occurs.
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 (~65 words) and front-loaded: core action first, then parameter semantics, then risk, then the authorization constraint, with a docs link last. Every sentence earns its place, and the safety warnings are positioned prominently without padding.
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?
For a destructive mutation with no annotations and no output schema, the description covers the critical context: what it does, parameter shape, the inspect-first workflow, the concrete risk, and the authorization requirement. Minor gaps remain: the name parameter is undescribed and return/response behavior is not addressed, which the absence of an output schema makes slightly more relevant.
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%, and the description compensates substantially for the complex disks parameter by defining it as 'the raw array of Longhorn Disk objects' and listing key fields (path, allowScheduling, storageReserved, tags, diskType). It also instructs inspecting node_get output for the exact shape. The required name parameter, however, is left entirely implicit with no explanation.
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 states a specific verb and resource: 'Update the disk configuration for a node.' This cleanly distinguishes it from the sibling node_update, which targets general node settings, by scoping to disk configuration. The title and description align with no ambiguity about what resource is affected.
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 gives clear contextual guidance: inspect the node via node_get first to see the current disk shape, and a hard when-not-to-call constraint ('never proactively, speculatively, or as a side effect of another task'). However, it does not explicitly name an alternative tool for non-disk node updates or state exclusions versus node_update, so the 'when-not' guidance is behavioral rather than tool-routing.
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 behavioral burden. It discloses the destructive nature of the operation, the irreversible effect of discarding changes, and the need for explicit user authorization. This goes well 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?
Three tightly focused sentences with no filler. The action and consequence come first, the safety warning second, and the documentation link last. 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?
For a destructive two-parameter operation with no output schema and no annotations, the description is nearly complete: it covers the operation, the impact, the consent requirement, and points to docs. It falls just short of explicitly defining the parameters and any prerequisites such as the volume being in a valid state for revert.
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 supply parameter meaning. It implies that 'name' is the volume and 'snapshotName' is the snapshot, but it does not explicitly map or clarify either parameter. The operation sentence adds some context, but the description could be clearer about which identifier refers to what.
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 states a specific verb and resource: 'Revert a volume to a snapshot,' with the meaningful consequence 'discarding all changes made since.' This clearly distinguishes it from sibling snapshot tools like volume_snapshot_create, volume_snapshot_delete, and volume_snapshot_purge.
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 an explicit, high-stakes usage condition: do not call unless the user has explicitly authorized it in this conversation, and never proactively, speculatively, or as a side effect of another task. This is strong when-to-use and 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.

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:

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

Score Badge

Copy to your README.md:

[![longhorn-mcp MCP server](https://glama.ai/mcp/servers/rafaelgaspar/longhorn-mcp/badges/score.svg)](https://glama.ai/mcp/servers/rafaelgaspar/longhorn-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/rafaelgaspar/longhorn-mcp'

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