Remove recurring job from volume

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.

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.

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.

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.

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.

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.