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

Goes well beyond the annotations: discloses the background-job execution model (immediate job_id, poll lab_get_job, result in job.result), the 409 staleness behavior, the estimate caveat for stem levels inside the master, and the no-write/no-cost profile. This is exactly the kind of contract an agent cannot infer from readOnlyHint/idempotentHint alone.

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 deliverable (what is measured) before the prerequisites and job mechanics, and every sentence carries information. It is dense and long but not padded; the density is justified by the measurement detail rather than extraneous prose.

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?

No output schema exists, yet the description explains what the result contains and where to find it (job.result via lab_get_job), plus staleness and estimate caveats. Nothing an agent needs in order to invoke and interpret this call 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?

Only one parameter (seq_id) and schema description coverage is 100%, so the schema fully documents it ('Sequence id — positive integer as string'). The description adds no extra syntax or format guidance, which is the expected baseline when the schema does the work.

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?

Names a precise verb+resource (measure the rendered mix) and enumerates exactly what is produced: integrated LUFS, true peak dBTP, loudness range LU, plus per-stem speech-gated values. It is clearly separable from voiceover/mix siblings like lab_mix and lab_stems_export.

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?

States the operating context ('measure before and after a change to prove what it did'), the prerequisite ('needs a current render whose stems are still the ones it was made from'), and the failure mode that selects a different action ('any change with lab_mix discards it ... render first'). The lab_mix sibling is named as the invalidating operation.

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