Labels File

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

The description adds real behavior beyond the annotations: export is blocked when the target file already exists, and point-label subtitle ends are derived from the next marker or project end. That is valuable for the export path. But annotations declare destructiveHint=true and idempotentHint=false, and the description never says whether importing into an existing named track replaces its labels or merges with them, which is exactly the destructive risk an agent needs disclosed.

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?

Three tightly packed clauses front-load the core import/export capability before the two edge-condition notes; there is essentially no filler. The point-label subtitle sentence is niche but relevant to format selection rather than padding.

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 overwrite-refusal rule covers the export side well. For a destructive, non-idempotent import that writes into a named track, the description does not close the loop on replacement vs merge behavior or on what happens to an existing track of the same name.

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?

With 0% schema schema-level parameter documentation, the description carries the load and does meaningfully clarify that import only accepts TSV or JSON while export covers subtitles, chapters, CUE, Podlove and ffmetadata — a non-obvious mapping onto the format enum. It also clarifies that trackName names a track, but it leaves path semantics, defaults (format=tsv, trackName='Labels'), and the required-vs-optional relationship unexplained.

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 uses specific verbs (import/export) with a concrete resource (Audacity label files/tracks) and enumerates the supported formats, so it is far more than a restatement of the title. It does not explicitly position itself against siblings such as audacity_labels or audacity_label_regions_export, so an agent must infer the split from the action/format wording.

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 two modes (import vs export) and their format families imply when each is applicable, and 'Existing output files are refused' gives a usable precondition. However there is no explicit statement of when to choose this tool over audacity_labels, audacity_label_regions_export, or audacity_export, and no guidance on prerequisites for a destructive import.

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