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

Annotations already declare idempotentHint=true and destructiveHint=false, and the description concretely explains that behavior ('repeated requests reuse an existing current export or its running job'). It also adds non-obvious context: the checks inherited from Studio, and the crucial warning that a queued job is not a finished video, plus the delivery gating rule. This is context an agent cannot infer from structured fields.

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 action and trigger, then layers prerequisites, behavioral notes, and the follow-up workflow. Every sentence carries distinct, actionable information with no padding.

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?

Despite no output schema, the description covers what the tool returns operationally (a queued job vs. a delivered file), the follow-up tools required, and the condition for claiming success. Nothing an agent needs to call and correctly interpret this tool is missing.

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 0%, so the description must carry both parameters. It names both and adds meaningful semantics ('explicit project_id', 'reviewed edl_version'), clarifying that the version must be the reviewed one. It stops short of describing valid ranges or how to obtain an edl_version.

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 (export) and resource (reviewed edit as full-resolution MP4), and scopes it to the trigger condition 'when the user asks for the finished video'. This distinguishes it from render_preview and upload_finish without needing their schemas.

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 an explicit usage trigger and a required follow-up workflow (wait_for_job, then download_url), plus the rule 'Never claim delivery until a download link is returned'. It does not explicitly contrast with render_preview as the lighter alternative, but the 'full-resolution finished video' framing implies the distinction.

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