effect_change_tempo

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

No annotations are provided, so the description carries full burden. It discloses that pitch is preserved (a key behavioral trait) and gives percent range semantics. However, it doesn't disclose that altering tempo changes the duration of audio, whether the operation is destructive to the original clip, whether it affects clip boundaries or waveform data, or how it handles selections vs. whole clips. For an effect that modifies audio, this is a significant transparency gap.

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: one title line plus one parameter explanation. The key behavioral point (without changing pitch) is front-loaded in the first sentence. The Args section is terse and useful. Minor credit loss because the title/tool name and description overlap, and 'without changing pitch' is the only behavioral context beyond the parameter spec.

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 single-parameter effect tool, the description handles the parameter semantics well and states the core behavior. But it lacks any context about what the operation does to the audio file (duration change, destructuring), what the user should expect, or how to undo/revert. Given there's no output schema and no annotations, an agent has to infer side effects. The presence of sibling effect_change_speed and effect_change_pitch suggests this tool needs more differentiation to be 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 has only one param 'percent' with default 0 and 0% coverage, so description must compensate. It does: explains percent is a percentage change, gives a valid range (-95 to 3000), and provides concrete examples for both positive and negative values. This adds substantial meaning beyond the bare schema. It doesn't clarify whether 0 means no change or is invalid, but the range and examples largely compensate for the schema gap.

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 clearly states the tool changes tempo of selected audio while preserving pitch, using a specific verb ('Change') and resource ('tempo of the selected audio'). It is well-differentiated from siblings like effect_change_pitch and effect_change_speed by explicitly noting pitch is preserved. However, it doesn't explicitly contrast with effect_change_speed, which also changes tempo-like timing, so a very minor distinction gap exists.

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 usage on selected audio ('Change the tempo of the selected audio'), so an agent knows selection is a prerequisite. It provides percent semantics with examples, but doesn't explicitly state when to prefer this over effect_change_speed or effect_change_pitch, nor does it describe what qualifies as selected audio or how selection is made. The implied usage is adequate but not explicit.

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