label_add

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

There are no annotations, so the description carries the behavioral disclosure burden. It does disclose a useful side effect: automatic creation of a label track if none exists. However, it does not explain what happens if both a selection and a playback position exist, whether existing labels are affected, or other mutation consequences.

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 and front-loaded: the main action, position context, and automatic track creation appear first. The Args section is minimal and necessary given the lack of schema descriptions. Every sentence contributes information with no 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?

For a simple tool with one optional parameter and no output schema, the description covers the core behavior well. It could improve by clarifying the precedence between current selection and playback position, but the essential information needed to invoke the tool correctly is present.

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. It defines the only parameter, text, as optional text for the new label, which adds meaning beyond the raw schema's title and default value. No limits or formatting constraints are given, but for a single optional string parameter this is adequate.

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 action: add a label at the current selection/playback position, and it also specifies that a label track is created automatically if none exists. This differentiates it by location from siblings like label_add_at and label_add_batch, though it does not explicitly name those alternatives.

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 gives a clear usage context: adding a label at the current selection/playback position, and implies the tool is convenient because it auto-creates a missing label track. It does not explicitly compare against alternative label tools, but the positional condition provides enough guidance for selection.

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