add_parallel_compression

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

Annotations only include destructiveHint=false, so the description carries most of the behavioral disclosure burden. It transparently states that a new bus track is created, a send is added from the source track, and heavy compression is applied, which is meaningful beyond the annotation. It does not mention behavior on repeated calls, but the core side effects are clear.

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 compact and well-structured: a one-sentence purpose, a one-sentence mechanism, then clearly labeled Args and Returns. Every sentence earns its place and no redundant filler is present.

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 tool that creates multiple objects, the description covers the essential outcome and return values (bus_track_index, send_index, compressor_fx_index). It lacks details about repeated invocation behavior or edge cases like invalid track_index, but given the simple two-parameter surface and no output schema, it is reasonably 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 description coverage is 0%, so the description must explain the parameters, and it does. It defines track_index as 'Source track index (0-based)' and blend_db as 'Send level in dB for the compressed signal (default -6dB)', adding units, role, and default beyond the raw schema.

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 opens with a specific verb and resource: 'Set up New York style parallel compression for a track.' It then clearly explains the mechanism (new bus track, heavy compression, send from source), which distinguishes it from sibling tools like add_compressor, create_bus, create_send, and setup_sidechain_compression.

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 implies when to use the tool: whenever the user wants New York/parallel compression on a track. However, it does not explicitly contrast with alternatives such as setup_sidechain_compression or add_compressor, nor does it state when not to use it.

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