effect_reverb

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

With no annotations, the description carries the full burden of behavioral disclosure. 'Apply reverb' implies a modifying operation, but it does not state whether it destructively edits the selected audio, whether it creates a new clip, whether it is undoable, or how it interacts with existing effects. The parameter list adds numeric context but not behavioral side effects.

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 front-loaded with a clear one-sentence purpose and then a structured, readable Args block. Each parameter line provides useful information that the schema lacks. It is somewhat long due to ten parameters, but the length is justified; a slightly tighter grouping or cross-reference to schema defaults would make it leaner.

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?

The description is minimally viable for invoking the tool: it names the operation and documents all parameters. However, with no output schema and no annotations, it leaves out context about what happens to the selected audio, whether the process is destructive or reversible, and what the tool returns or reports. For a 10-parameter audio effect, this is a clear but not severe gap.

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?

The input schema has 0% description coverage, so the description must compensate, and it does. Every parameter is documented with units, ranges, and defaults, e.g. 'room_size: Room size percentage (0-100). Default: 75' and 'wet_only: Output only the wet (reverb) signal.' This goes well beyond the bare schema titles and defaults.

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 a specific operation and resource: 'Apply reverb to the selected audio.' This clearly identifies the tool's purpose and distinguishes it from sibling effects like effect_reverse or compressor. It does not explicitly contrast itself with realtime effect tools, but the core purpose is unambiguous.

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?

There is no guidance about when to use this tool versus the many sibling effect tools, realtime effect tools, or preset application tools. The description only says what it does, not how to decide between it and alternatives like apply_effect_preset, list_effects, or suggest_and_add_effect.

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