effect_adjustable_fade

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

No annotations are provided, so the description must carry the full behavioral burden. It communicates that this is an effect application, but does not disclose whether the operation is destructive, whether it requires a selection, whether it is undoable, or what happens when no audio is selected. Parameter semantics are useful but are not behavioral disclosure.

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 short, front-loaded with the one-sentence purpose, and uses a clear Args block. Every sentence contributes either purpose or parameter meaning, with no filler or redundant restatement of the tool name.

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 simple two-optional-parameter effect, the parameter documentation is adequate. However, the description omits the operational context: what the effect applies to, any preconditions, and what consequences or errors may result. This is a moderate gap, especially with no annotations or output schema to fill it.

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 compensate, and it does by explaining both parameters: fade_type maps 0/1 to fade up/down and curve maps 0/positive/negative to linear/exponential/logarithmic. The curve explanation is somewhat coarse, but it adds real meaning 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 clear action ('Apply') and resource ('an adjustable fade'), with 'curve control' signaling a distinct capability beyond simple fade-in/out siblings. It does not explicitly name sibling alternatives, but the wording and parameter hints differentiate it from tools like effect_fade_in and effect_fade_out.

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 only implied by 'adjustable fade' and 'curve control'; an agent can infer it is for custom fades rather than fixed ones. However, the description does not explicitly say when to choose this vs effect_fade_in, effect_fade_out, or effect_studio_fade_out, and it offers no exclusions.

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