Track Edit

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotency, so the safety profile is covered. Beyond that the description adds genuinely useful behaviour: mix_new duality of keeping source tracks audible, and the ordering quirk that the new audio track can precede label tracks in the returned list. It does not say whether remove or mix are undoable or what permissions are needed, which keeps it short of a 5.

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?

Front-loaded with the action inventory, then the caveats, with no filler sentences; each line carries information. A few phrasings ("Track scope is explicit", "align ... by start/end/selection") are compressed to the point of ambiguity, which costs a point.

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?

An output schema exists, so return values need no explanation, and the destructive hint is covered by annotations. Still, for a 13-action, 6-parameter, zero-coverage schema the description leaves several enum members (align_together, align_start_cursor, align_end_end) and three parameters semantically opaque, so an agent could pick the wrong action or pass an unintelligible numeric range.

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 carry the parameter burden and it only partially does. It clarifies that add actions can use `name` for the new track and alludes to the `track` scope parameter, and the alignment phrasing hints at start/end usage. However, `trackCount`, the units and limits of `start`/`end` (0-86400), and the precise meaning of the individual align_* enum members remain undocumented anywhere.

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 concrete verbs and resources that map to the action enum: add mono/stereo/label tracks, remove, mix/render, and align by start/end/selection. It implicitly scopes itself to whole-track operations ("Track scope is explicit"), which separates it from clip-level siblings, but it never names a sibling such as audacity_track_set or audacity_clip_move to make the boundary 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?

Gives a real operational rule for the trickiest action: with mix_new the originals stay audible, so the agent should mute them before exporting to avoid doubling. It also tells the agent where to look afterward ("Find the new audio track in returned tracks"). What is missing is explicit when-not guidance or a pointer to an alternative tool for the neighbouring operations.

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