volume_recurring_job_addAttach a recurring job or job group to a volume to automate scheduled snapshots and backups. This ensures consistent data protection without manual intervention.
Attach a recurring job (or job group) to a volume. Longhorn docs: https://longhorn.io/docs/1.12.1/snapshots-and-backups/scheduling-backups-and-snapshots/
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| isGroup | No | ||
| jobName | Yes |
Changes observed during successful MCP inspections.
v0.1.6Does 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.
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.
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.
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.
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.
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.