compressor

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

With no annotations provided, the description carries the full burden. It excellently discloses the critical side effect of normalize=True ('will re-peak your audio to 0 dB') and domain-specific behavior (transient preservation, RMS vs peak detection). Deducted one point because it does not explicitly state whether the operation modifies the current selection in-place or returns new audio data.

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?

Perfectly structured and front-loaded: purpose statement → use-case guidelines → critical warning → parameter reference. No filler text; every sentence provides actionable domain knowledge or safety warnings. Appropriate length for the complexity of 7 parameters.

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?

Given high complexity (7 optional parameters, specialized audio domain, 0% schema coverage), the description is remarkably complete. It covers purpose, domain-specific usage patterns, dangerous flag combinations with alternatives, and full parameter semantics. Absence of output schema is mitigated by clear indication that audio is modified.

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 has 0% description coverage (only titles). The Args section fully compensates by documenting all 7 parameters with units (dB, seconds), semantic meaning ('Level above which compression starts'), format examples ('2.0 = 2:1'), and usage context ('better for voice/podcast'), exceeding what the schema provides.

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?

Opens with specific verb-object pair ('Apply dynamic range compression') and immediate outcome ('Evens out volume differences'). Clearly distinguishes from siblings like limiter or normalize through the detailed WARNING about normalize=True behavior and explicit reference to use loudness_normalize() instead for LUFS-based control.

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?

Provides explicit contextual guidance for two distinct use cases ('For mastering...' vs 'For podcasts/voice...') with specific parameter values. Explicitly names an alternative tool ('Use loudness_normalize() instead') and clarifies when NOT to use certain settings ('Higher ratios... are mixing tools, not mastering tools').

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