release_check

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

Annotations declare idempotentHint=true and destructiveHint=false, and readOnlyHint=false. The description complements these by explicitly stating 'Read-only for your audio files; it may write a preview WAV when output_path is omitted,' which clarifies the actual write behavior and resource effects beyond what annotations convey. It doesn't detail authorization needs or rate limits, but the read-only caveat plus idempotency is solid disclosure.

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?

Three tight paragraphs, zero filler. Each paragraph earns its place: first explains the core operation and metrics, second clarifies the read/write behavior, third gives sequencing guidance. Front-loaded with the core purpose in the first sentence.

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 complex tool with 4 parameters, conditional behaviors (output_path vs. style), and a quality-gate semantic, the description covers the key decision points: metric targets measured, read/write footprint, when to run, and parameter interactions. The output schema exists to convey return structure, and sibling differentiation is handled. No significant gaps remain.

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 all four parameters are documented in the schema. The description adds behavioral context about how style and output_path interact (style optional when output_path points at existing WAV), which supplements the schema meaningfully. However, there's no information about acceptable glob formats for pattern or how render_dir interacts—beyond what the schema's own descriptions already state.

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 it runs a quality gate measuring the mix against top-label targets (LUFS, LRA, true peak, RMS, spectral tilt) and returns a ready/needs_work verdict. This distinguishes it from siblings like analyze_audio (generic analysis) and preview_mix (rendering) by framing it as a label-standard qualification gate.

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 explicitly says 'Run this last, after preview_mix, to decide whether the mix is release-ready,' providing clear sequencing guidance relative to siblings. It also explains the output_path conditional behavior—when to provide an existing file vs. when preview rendering occurs—giving concrete decision criteria.

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