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

Annotations only say this is a non-readonly, non-destructive, non-idempotent operation; the description adds the actual id-retention rule, what the response reports (new quality verdict and flagged ranges), and that the call is free. It does not state reversibility or permission requirements, which would be the remaining 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?

Front-loaded with the core split semantics before the usage guidance, and the verification hint and cost note come last. Four sentences, each carrying information; the trailing "Free." is terse but is real decision-relevant data rather than filler.

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?

There is no output schema, so the description compensates by describing what the answer returns and pointing to preview_range with overlays ["tracks"] for verification. Missing only peripheral details such as what happens to downstream references or effects attached to the original track.

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 100%, so every parameter is already fully documented in the schema, including atSpace semantics and the label/id relationship. The description only echoes the "at a second" split point and adds no new parameter-level detail beyond that, so baseline 3 applies.

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?

States the exact verb and resource plus the non-obvious semantics that make the operation unambiguous: frames before the split keep the track id, frames at/after become a new track. This clearly separates it from siblings like merge_tracks, offset_track and edit_track.

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?

"Use it at a cut, or where the tracker jumped to another object, then fix or remove the part that is wrong" gives concrete triggering conditions and the follow-up workflow. It does not name a sibling alternative for the cases where splitting is the wrong choice, so it stops short of full when-not guidance.

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