preview_mix

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

Annotations provide readOnlyHint=false (mutation), idempotentHint=true, destructiveHint=false. The description adds meaningful context: it writes a NEW file (output_path description explicitly says 'source renders are never modified'), and confirms it operates fully offline. However, the description doesn't dwell on behavioral details that annotations already cover, and the added content (WAV creation, normalization behavior) is genuinely useful beyond the schema.

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 front-loaded with a clear action sentence followed by parameter explanations in a structured list format. It's moderately long but every sentence earns its place - context for max_duration and sidechain_db adds real value. Slight redundancy with schema parameter descriptions, but the overall structure is well-organized.

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 7-parameter tool with 100% schema coverage and an output schema present, the description is comprehensive. It covers the workflow context (preview before applying in Live), offline capability, normalization behavior, and the key nuance around mismatched render lengths. The contrast with auto_mix rounds out the tool's place in the broader workflow.

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 the schema already documents all 7 parameters. The description adds some value by explaining the max_duration and sidechain_db semantics in context (loops vs full arrangement mismatch), but most parameter meanings are already clear from the schema field descriptions. Baseline 3 is appropriate since the schema does the heavy lifting.

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 clearly states that the tool applies style corrections to rendered WAVs and bounces a stereo preview mix, specific verb+resource (Apply+Bounce) with clear scope ('volumes + pans applied to audio, summed, normalized'). It distinguishes itself from siblings by explicitly contrasting with auto_mix with dry_run=True for recommendations.

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 gives explicit when-to-use guidance: 'Use this to listen to the mix before applying anything in Live; for recommendations only, use auto_mix with dry_run=True.' It also names the alternative, making it clear this is for listening/previewing rather than recommendations, and explicitly notes it works fully offline as long as render WAVs exist.

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