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

Annotations only supply the safety profile (readOnly false, destructive false, idempotent false), while the description adds substantive context: credits billed at the site's price, the free quote_job pre-check, the approval_required gate that halts execution until the person answers, results landing in their library, and a content policy that refuses minors/public figures before any charge. It also confirms the original is preserved, consistent with destructiveHint=false.

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 lead clause is front-loaded on what the tool does and the operation list follows immediately. It is a dense single paragraph carrying seven actions plus billing and approval semantics, which is justified by the tool's complexity, though breaking the billing/approval sentences out would improve scanability.

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 an 11-parameter, zero-required, multi-action tool with no output schema, the description covers operations, cost, approval flow, policy refusals, and result persistence well. The one real gap is that it never says what a successful call returns (a job to poll via get_job), leaving the agent to infer the completion loop.

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 coverage is 91%, so the schema already documents each parameter thoroughly, including action and voice enum meanings. The description's action list largely restates the enum descriptions, and it adds no syntax or formatting detail beyond what is already in the schema. Baseline 3 applies.

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 names a specific verb-plus-resource ('Work on a song the account made, or on the person's own audio from a link') and then enumerates every supported operation: remix, extend, stems, replace_section, add_vocals, add_backing. That map is precise enough to separate the tool from create_song, keep_song, and extend_video without opening a schema.

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?

It clearly frames when to use it: an existing track or the person's own uploaded audio, with 7 concrete transformations listed. It also routes the agent to quote_job for pricing and back to the approval card when approval_required returns. It never states the inverse — e.g. to start a brand-new song use create_song — so the exclusions remain implicit.

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