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

Annotations only cover readOnlyHint=false/destructiveHint=false; the description adds the retention nuance (a NEW video row comes back, the draft stays), the four named backend refusals, and the credit-charging rule that avoidable via get_cost with nothing charged on failure. This is substantial behavior beyond the annotations.

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

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

Front-loads the core action and outcome, then conditions, then the anti-pattern warning and cost note. Dense and mostly waste-free, though the 1080p/seed/sound restatement and repeated cost/refusal framing make it slightly longer than strictly necessary.

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

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

With no output schema, the description compensates by describing the returned artifact (new video row, draft retained) and enumerating failure modes. Preconditions, account scoping, and cost behavior are all covered, so an agent has everything needed to call it correctly.

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

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

Schema description coverage is 100%, so every parameter is already fully documented, including get_cost's preflight semantics. The description reinforces get_cost's role as the charge-avoiding path but adds no syntax, format, or constraints the schema lacks, matching the baseline 3 for high-coverage schemas.

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 (finish) and resource (an accepted DRAFT) with the exact outcome (1080p, same motion/seed/sound). It ties the draft back to lab_reference_motion with draft:true and explicitly rules out the common mistaken path (download and re-upload), so it is unmistakable against siblings.

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?

Gives explicit preconditions (draft must still be valid, must be called through the ordering account), names the exact refusal reasons, and tells the agent to call get_cost first and let the human confirm. It also states a clear when-not: never re-upload a draft to reach this operation.

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