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

With no annotations, the description carries the full burden and does well: it discloses the 20-item cap, the per-item ok/data/error return shape, and the metering rule that each item counts as one call. It omits failure semantics (e.g. whether one bad item aborts the batch) and auth/permission requirements.

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?

Four dense sentences, front-loaded with the core action and cap, then return shape, routes, and use cases. No filler; every clause carries operational information.

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 batch dispatcher with no output schema, the description is complete enough: it covers scope (20 items), return structure (per-item ok/data/error), metering, route enumeration, and source types. An agent has what it needs 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 coverage is 100%, so baseline is 3, but the description adds real value the schema does not: it enumerates the valid endpoint routes (mixlab/analyze, check-target, timeseries, spectrum, voicelab/qa, segments, signallab/index) and the source types (https URLs and local paths) that map to the urls/paths parameters.

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 (run one analysis route) and resource (up to 20 audio sources in a single call), and distinguishes itself from siblings by being the batch wrapper that dispatches to the routes those siblings expose individually.

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 concrete use cases (folder QA, library indexing, checking a whole release against a loudness target) and names the default route, so an agent knows when the batch path applies. It stops short of saying when NOT to use it (e.g. single-file work should call the individual sibling tools), so it isn't a full 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses essentially nothing beyond the metric list — no read-only/side-effect profile, no latency or cost characteristics, no auth requirements, and no indication of how large files or failures are handled (the 4 MB inline / 150 MB signed-URL detail lives in the schema, not the description).

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?

Two sentences, front-loaded with the substantive metric list and closing with the input-source clause. Every phrase carries information (specific standards named, concrete metrics enumerated) and there is no filler or repetition.

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 present, the description usefully compensates by enumerating the returned measurements, and the input contract is fully covered by the schema. It is slightly incomplete in that it gives no behavioral context (safe read? latency? cost?) for an analysis operation with zero annotation coverage.

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 both parameters (url and path) are already fully documented in the schema, including the 'exactly one of' constraint and the size thresholds. The description only restates the two source options without adding format or constraint detail beyond the schema, so baseline 3 applies.

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+resource (loudness/dynamics analysis of a track) and enumerates the exact metrics produced — integrated LUFS, true-peak, LRA, crest factor, stereo correlation, mono compatibility, tonal balance — which clearly separates it from siblings like get_spectrum or analyze_voice. It does not explicitly name the nearest sibling compare_loudness, so it falls short of full differentiation.

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 says what it analyzes but never states when to choose this tool over alternatives such as compare_loudness or get_spectrum. There is no when-to-use, when-not-to-use, or prerequisite guidance; the only routing hint is the input source format, which is parameter information rather than usage guidance.

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

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

With no annotations the description carries the full burden and does well: it discloses the paid-plan gating for seven profiles, that only the required passes execute, that results are keyed by stable lens id, and that series:true produces a 'much larger payload' to leave off unless read. It stops short of rate limits, latency, or failure behavior, but the cost/entitlement tradeoffs are unusually well surfaced.

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?

Purpose and profile list are front-loaded and the audio-source note closes it out, so it reads in the right order. It is somewhat dense and run-on (the series sentence and 'values,a much larger payload' are slightly garbled), which costs a point but not much material clarity.

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?

There is no output schema, so the description must describe returns: it explains results are keyed by stable lens id, scoped to only what the profile needs, and optionally augmented with curves, per-block lanes and per-phrase values. That covers the shape at a high level, though it does not enumerate per-lens fields, so an agent can call it correctly but not fully predict the payload.

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 100%, so baseline would be 3, but the description adds real semantic value the schema lacks: the enum's terse 'Which question to answer' is expanded into a concrete question per profile value, and the series flag's payload consequence is explained rather than merely described.

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 concrete verb and resource ('Measure a file against a named working set of lenses') and then enumerates the eight profiles with the exact question each answers, which lets an agent distinguish this multi-lens entry point from single-purpose siblings like analyze_loudness or analyze_voice.

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 per-profile question list implies when each profile is appropriate, and it notes 'only the analysis passes the profile needs are run', which is useful routing context. However it never states when to prefer this tool over sibling analyzers (analyze_voice, analyze_loudness) or when a profile is the wrong entry point, so guidance remains implied rather than explicit.

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

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

With no annotations, the description carries the full burden. It usefully discloses the ~3s analysis window, the EBU R128 standard, and that the waveform is downsampled, but says nothing about response size limits, error behavior, or processing cost. Partial disclosure for a read-only analysis tool.

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 sentences that front-load what is returned, then the applicability, then the input sources. No filler, though the last sentence partially duplicates what the schema already documents.

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?

There is no output schema and no annotations, so the description should fully explain the return shape. It names the arrays and time-base but omits units, ordering, or pairing format between samples and timestamps, leaving moderate gaps for an agent consuming the result.

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 baseline is 3. The description restates the two audio-source options (public https URL or local path) but adds no syntax or format detail beyond the schema, and the `waveformPoints` parameter is only hinted at via 'downsampled waveform peaks' without naming the default or unit.

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 names a specific resource (short-term LUFS samples with time-base, plus downsampled waveform peaks) and specifies the measurement standard and window (EBU R128, ~3s). It implicitly distinguishes itself from analyze_loudness by framing output as arrays for charts/meters rather than summary metrics, but never names the sibling explicitly.

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?

It gives use-case context (loudness-over-time charts, level meters, waveform UIs) and lists both audio sources, but there is no explicit 'use this instead of analyze_loudness when...' routing and no when-not guidance. The consumer must infer that this tool is for time-series data versus summary statistics.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the metric set and the acceptance-gate framing plus how audio is sourced (public URL vs local path with size-based handling). It omits permissions, rate limits, failure behavior, and output shape, leaving real gaps for a no-annotation tool.

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?

Two tightly packed sentences, front-loaded with the metric list and the gating purpose, with the source note last. Efficient with no filler, though the metric enumeration is dense enough that it borders on a spec dump.

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 annotations and no output schema, the description does the necessary work by enumerating the returned metrics and the gate semantics, which serves as an implicit output description. It lacks detail on thresholds, scoring, or error cases, but is largely sufficient for a two-parameter analysis tool.

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 both parameters are already fully documented in the schema including the 'exactly one of url or path' rule. The description restates the source options without adding syntax or format detail beyond the schema, so baseline 3 applies.

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 and resource (speech-quality QA for a voice recording) and enumerates the exact metrics computed, which distinguishes it clearly from siblings like analyze_loudness and get_spectrum. An agent can tell what this tool returns without opening any schema.

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 phrase 'Gates a voice take' implies the context of use (a pass/fail QA gate for a voice recording), giving implied guidance. However, it names no alternative and gives no explicit when-not or sibling-routing guidance, so an agent must infer the boundary against analyze_loudness or check_target.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return content (pass/fail with per-metric deltas and a fix command), the preset set, and the url-vs-path input modes. It omits auth/rate-limit or cost context, keeping it short of a 5.

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-loaded purpose in the first clause, then outputs, then presets, then source options — no filler. Dense but readable; the preset list is long yet functional.

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 usefully explains the return shape and even the corrective ffmpeg command, and it covers target semantics. It leaves sibling routing and the missing 40% of parameter docs unaddressed, so not fully complete.

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 60% and the description meaningfully compensates: it enumerates the valid preset ids and explains the custom path (target="custom" with lufs+tp), which the schema only gestures at with 'Preset id or "custom"'. The url/path exclusivity is also reinforced.

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 and resource ('Verify whether audio hits a delivery target') with concrete scope (presets, LUFS values). However, it never differentiates itself from siblings like analyze_loudness or compare_loudness, which occupy adjacent territory in the same tool family.

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?

Usage context is implied by 'delivery target' and the preset list, so an agent can infer this is a compliance check versus a raw measurement. But there is no explicit when-to-use guidance or exclusion naming analyze_loudness or compare_loudness as alternatives.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that both results are returned for comparison and that sources may be public https URLs or local file paths, but says nothing about pairing requirements, failure modes for mismatched formats, duration limits, or permissions.

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-loaded with the core action and scope, followed by compact scenario examples and an input-format note. The trailing fragment ('Audio source: ...') is slightly clipped but short and load-bearing.

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 4-param tool with no output schema and no annotations, the description covers purpose, scope, and input forms adequately, and notes that both results are returned. It leaves ambiguous whether the A/B pairs are strictly required and how the pairing of url/path variants is enforced.

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 already 100%, so the baseline is 3, but the description adds a genuine constraint beyond the schema: the URL must be a *public https* URL, whereas the schema only declares format=uri. The urlA/urlB vs pathA/pathB pairing is also hinted at.

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+resource ('Run loudness analysis on TWO sources') and makes the two-source/A-B scope explicit with named scenarios, which readily separates it from the single-source analyze_loudness sibling. It stops short of naming that sibling directly, so differentiation is inferred rather than stated.

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 concrete use contexts (master vs reference, before vs after a fix, two encoders, two cuts) that tell an agent when this tool is the right choice. There are no exclusions or explicit when-not-to-use conditions, and no mention of the single-source alternative.

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

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

With no annotations, the description carries the full burden and does more than most: it describes the response shape and explicitly warns that a commonly expected field (dominant band) is absent, which prevents downstream hallucination. It still omits cost/latency, auth requirements, and whether this is a non-destructive read, so it is not fully transparent.

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 sentences with no filler, and the most decision-relevant information (what the payload contains) is front-loaded. The input-source sentence at the end duplicates the schema, but the overall length is proportionate to the tool's complexity.

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?

There is no output schema, and the description compensates well by enumerating the return contents (paired arrays, seven bands) and one notable absence. Authorization, cost, and latency remain unstated for an annotation-free tool, but the largest gap, the response shape, is covered.

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%; both parameters already document the URL vs. local path choice, the exactly-one requirement, and the 4 MB inline / 150 MB signed-URL limits. The description only restates the source options, adding no syntax or format detail beyond the schema, so the baseline 3 is correct.

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 states exactly what the tool produces: frequency-domain magnitude data as paired frequency/magnitude arrays, plus energies in seven named bands. This clearly separates it from loudness- and timeseries-oriented siblings, though it never names an alternative tool. The negative disclosure ('no dominant-band field') sharpens the identity further.

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?

'For spectrum-analyzer UIs and tonal-balance analysis' gives implied usage context but no explicit when-to-use/when-not-to-use rules. Across nine sibling analysis tools it never says when get_spectrum is preferred over analyze_loudness or analyze_timeseries. The context is real but thin.

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

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

No annotations exist, so the description carries the full burden, and it does well: it discloses the detection method (RMS-based voice-activity, not diarization) and the return contents. It omits auth requirements, failure modes for non-speech audio, and rate/size limits beyond what the schema already states.

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 compact sentences; result description and use cases are front-loaded, with the scope caveat and input options following. No filler.

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 correctly specifies returns (timestamps and per-segment RMS), and it covers inputs and the diarization exclusion. Missing only minor operational detail such as error behavior on silent input.

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 100%, so the schema already documents both url and path in full detail, including the mutually-exclusive constraint and inline/upload size thresholds. The description only restates the source options ('public https URL, or a local file path'), adding no syntax beyond the schema. Baseline 3 applies.

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+resource ('List voiced speech regions') and enumerates the output (start/end timestamps, per-segment RMS), plus explicitly distinguishes itself from speaker diarization. An agent can tell it apart from analyze_voice and similar siblings without opening a schema.

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?

Names concrete use cases ('auto-trim, chapter generation, speaker-turn detection') and an exclusion ('not speaker diarization'), which is strong context. It doesn't name a sibling alternative to use instead, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden. It does disclose the nature of the result (a non-destructive summary index) and lists the derived buckets, which is genuinely useful, but it says nothing about processing cost, latency, rate limits, or whether remote fetching has side effects. It adds context but leaves real operational traits unstated.

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 sentences, front-loaded with what the tool produces before the usage note and input summary. Slight redundancy in re-listing the audio source, which the schema already covers, keeps it from a 5.

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?

There is no output schema, so the description must describe return values, and it does so thoroughly with the enumerated buckets and tag suggestions. What it omits — latency, remote-fetch behavior, failure modes — is minor for a local metadata-indexing tool with no annotations.

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 100% and both parameters are fully documented in the schema, including the 'exactly one of url or path' constraint and inline-vs-signed-URL size limits. The description only restates the source options, adding no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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 resource ('metadata index for any audio file') and enumerates the concrete outputs (content-type guess with confidence, brightness/dynamics buckets, dominant band, clipping/silence regions, tag suggestions), which lets an agent separate it from siblings like analyze_loudness or get_spectrum. It does not explicitly name the siblings it is not, so it stops short of a 5.

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?

'For triage or auto-tagging a library' implies the use case but gives no when-not guidance and never references the alternative tools in the sibling set. The agent must infer that this is the broad triage tool rather than a targeted analysis tool.

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