Server Quality Checklist

Tool Scores

• label_delete_audio_atB
  3.2/5.0
  Behavior2/5

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

  With no annotations, the description carries the full disclosure burden. It states the destructive action and the 'closing the gap' consequence, but it never addresses whether the deletion is permanent or undoable, whether the label itself remains, or what happens on a missing key or empty region. For an annotation-free destructive audio operation, 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.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The definition is minimal and well-ordered: a one-line behavior summary up front, followed by a tight Args block. There is no filler, and the parameter documentation is placed exactly where the reader needs it.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter tool with no output schema, the description covers the essential invocation: what it performs and how to build the key. However, it omits execution-critical context — reversibility, the fate of the label, invalid-key behavior — that an agent should know before issuing a destructive command. Adequate for calling it, incomplete for confident autonomous use.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the schema's 'key' property carries no meaning. The description compensates fully by specifying the exact format ('trackId:itemId') and the source (label_list). This makes the single parameter actionable on its own; only a concrete example would raise it to a 5.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource — 'Delete the audio under a single label' — plus a distinctive outcome, 'closing the gap,' which implies ripple-delete semantics. This implicitly separates it from siblings like label_remove or label_delete_regions that act on labels rather than the audio beneath them. Because the sibling differentiation is implicit rather than explicit, it stops short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No when-to-use guidance is given relative to the many nearby label tools (label_delete_regions, label_remove, edit_delete), and no exclusions or alternatives are named. The only hint, '(from label_list),' tells the agent where to get the key, not when this tool is the right choice. Usage must be inferred from the name and sibling list.

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

• transport_pauseB
  3.2/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It discloses no behavioral traits beyond the action itself – it does not say whether pause is idempotent, whether it retains the playhead position, or how it differs from stop. For a mutation-like transport command at zero annotaton coverage, this is a gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two words – 'Pause playback.' – with zero wasted content. It is appropriately sized for a zero-parameter tool and earns its place as a clearly stated action.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple transport action, the description is minimal but understandable. However, the sibling set includes transport_stop and transport_play_stop, and the description does not clarify what makes 'pause' different (e.g., retaining playhead position vs stopping). This incomplete distinction weakens selection accuracy.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has 0 parameters, so the schema covers everything vacuously. The description needn't explain any parameter semantics, and the baseline of 4 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description 'Pause playback' clearly states a specific verb and resource – it pauses playback. It is clear what the tool does, though it does not explicitly differentiate itself from sibling tools like transport_stop or transport_play_stop.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus the many transport siblings (transport_stop, transport_play_stop, transport_play_region). The description implies usage by naming the action, but offers no context or exclusions.

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

• bass_and_trebleB
  3.3/5.0
  Behavior2/5

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

  This 'annotation_placeholder' has no annotations, so the description must disclose behavioral traits. It mentions dB ranges and defaults but does not say whether the operation is destructive, whether it applies to the current selection, or what the audible/state impact is beyond adjusting frequencies. This is a mutation-style effect tool with too little behavior disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loads the purpose before listing parameters. It could be slightly tighter since defaults are already present in the schema, but the format is clean and readable without unnecessary prose.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description captures the essential parameter semantics and is reasonably self-contained for a simple three-parameter tool. However, it lacks any statement about the target of the adjustment (e.g., selected audio, active track, entire project) and does not mention the effect's destructive/preview nature, which is relevant for an audio-editing tool invoked by an agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, and the input schema only provides parameter names, types, and defaults. The description adds crucial meaning: units (dB), valid ranges (-30 to 30), and the role of each parameter (bass adjustment, treble adjustment, output gain). This fully compensates for the schema's lack of descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear action ('Adjust bass and treble frequencies') and identifies the tool as a 'simple tonal shaping tool,' which conveys its purpose and scope. It does not explicitly differentiate it from sibling effects like effect_notch_filter or effect_tremolo, but the bass/treble focus is distinct enough.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to use this tool versus alternative effects, nor any mention of the expected context (e.g., selected audio, track, or clip). The description only explains what the tool does and its parameters, leaving the agent to infer usage conditions.

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

• effect_change_pitchB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description must fully disclose behavior. It does explain that pitch changes without tempo and that high-quality stretching uses a slower SBSMS algorithm, but it omits critical behavioral traits: whether the change is destructive, whether it can be undone, what happens if nothing is selected, and whether the effect is applied permanently to the audio.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Compact and efficient: a one-sentence purpose plus a clean parameter list. Every sentence adds value and there is no redundant boilerplate. The core behavior is stated first, followed by parameter details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an effect tool with no annotations and no output schema, the description is incomplete. It does not state prerequisites (e.g., selected audio), side effects (destructive vs. reversible), or what the operation returns. An agent could invoke it without knowing whether the change is permanent or whether it needs a selection.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries full responsibility for parameter meaning. It does so excellently: semitones is explained with direction (negative = lower, positive = higher), and use_high_quality_stretching is clearly tied to the SBSMS algorithm and a performance tradeoff. Both parameters are fully clarified beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource: 'Change the pitch of the selected audio without changing tempo.' This clearly distinguishes the core function from generic edits. However, it does not differentiate itself from sibling tools like clip_set_pitch or clip_reset_pitch, which may overlap in purpose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance on when to use this tool versus alternatives. It does not mention that the user must have audio selected, nor does it compare to clip_set_pitch or other pitch-related tools. The usage context is only implied by the phrase 'selected audio.'

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

• effect_reverbB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. 'Apply reverb' implies a modifying operation, but it does not state whether it destructively edits the selected audio, whether it creates a new clip, whether it is undoable, or how it interacts with existing effects. The parameter list adds numeric context but not behavioral side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a clear one-sentence purpose and then a structured, readable Args block. Each parameter line provides useful information that the schema lacks. It is somewhat long due to ten parameters, but the length is justified; a slightly tighter grouping or cross-reference to schema defaults would make it leaner.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description is minimally viable for invoking the tool: it names the operation and documents all parameters. However, with no output schema and no annotations, it leaves out context about what happens to the selected audio, whether the process is destructive or reversible, and what the tool returns or reports. For a 10-parameter audio effect, this is a clear but not severe gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has 0% description coverage, so the description must compensate, and it does. Every parameter is documented with units, ranges, and defaults, e.g. 'room_size: Room size percentage (0-100). Default: 75' and 'wet_only: Output only the wet (reverb) signal.' This goes well beyond the bare schema titles and defaults.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific operation and resource: 'Apply reverb to the selected audio.' This clearly identifies the tool's purpose and distinguishes it from sibling effects like effect_reverse or compressor. It does not explicitly contrast itself with realtime effect tools, but the core purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to use this tool versus the many sibling effect tools, realtime effect tools, or preset application tools. The description only says what it does, not how to decide between it and alternatives like apply_effect_preset, list_effects, or suggest_and_add_effect.

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

• generate_noiseB
  3.3/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden of behavioral disclosure. It reveals that the tool fills the selected time range and depends on a prior selection, but it does not disclose whether existing audio in that range is overwritten, whether the operation is destructive or undoable, or what the tool returns. For a generation/mutation tool this is a significant gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loads the most important behavioral fact about the selected time range. Every sentence earns its place, though 'Generate noise' is mildly redundant with the tool name and the Args block partially duplicates the schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter generator with no output schema or annotations, it covers the key invocation setup: how duration is determined and what parameter values are allowed. It leaves gaps around side effects (whether existing audio is replaced or mixed), behavior when no selection exists, and the call result/status, which prevents it from being fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides only types and defaults, so the description adds meaningful value by listing the exact allowed values for noise_type ('White', 'Pink', 'Brownian') and the numeric range for amplitude (0-1). Amplitude's precise meaning is still not fully explained, so this is not a 5.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description states a specific action ('Generate noise') and a concrete resource/effect ('fills the currently selected time range'), with allowed noise types that distinguish it from tone/chirp/silence generators. It does not explicitly name sibling alternatives, so it stops short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives a clear procedural prerequisite ('call select_region first to control duration') and implies this is the tool for noise rather than tones or silence. However, it never explicitly mentions when to prefer this over sibling generation tools or states any exclusions, so the guidance is mostly implied.

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

• label_add_batchB
  3.3/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full behavioral disclosure burden. It only states that labels are added and lists the label shape; it does not mention side effects, whether labels are appended or replace existing ones, what label track is targeted, or any validation behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely concise and front-loaded with the core purpose. The Args section adds the essential parameter detail without unnecessary prose, making it easy to scan and parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness2/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given no output schema and no annotations, the description is not complete enough for confident invocation. It omits the coordinate system, target label track, interaction with existing labels, return value, and any restrictions on label ranges, which are significant contextual gaps for a write operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema is nearly empty, with labels as an array of objects and additionalProperties allowed. The description compensates by specifying the exact expected object shape: start (float), end (float), and optional text (str). It does not clarify the meaning of start/end coordinates or units, but the core parameter semantics are clearly provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool adds multiple labels in one call, identifying both the verb and the resource. It implicitly differentiates from the sibling label_add by emphasizing the batch aspect, though it does not explicitly compare against label_import or other label-related tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'in one call' implies this tool is for adding multiple labels at once, which offers some usage context. However, it does not explicitly state when to choose this over label_add, label_import, or other label tools, leaving the decision largely to inference.

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

• label_update_textB
  3.3/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the label must already exist, implying a mutation, but does not describe failure behavior, whether text is overwritten, or any side effects on associated label data. This is thin for a mutating tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence summary followed by an Args block. Every line earns its place, and the key format detail is important and immediately useful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter mutation tool with no output schema and no annotations, the description adequately explains the operation and both arguments. Minor missing context includes return value/confirmation and error behavior when the key does not exist, but the tool is straightforward enough that these are not critical gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema provides only field names with no descriptions, so this is a 0% schema coverage case. The description compensates by documenting both parameters: key uses 'trackId:itemId' format and text is the replacement label text. It could add more detail about how to obtain a valid key, but it covers the essential semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the operation as changing the text of an existing label, naming the specific resource and action. It does not explicitly distinguish itself from the sibling label_edit, which may cover similar label-editing behavior.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to use this tool versus alternatives such as label_edit, label_add, or label_remove. The description does not mention prerequisites, such as verifying the label key exists, or any conditions under which this tool is preferred.

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

• apply_effect_presetB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, and the description does not disclose behavioral consequences such as overwriting the effect's current parameter values, reversibility, failure modes, or required permissions. 'Apply' implies mutation, but the side effects and error behavior are left unspecified.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tight: one action sentence followed by a compact, well-organized Args list. Every line adds new information and nothing is wasted or repeated from the schema.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a straightforward 3-parameter mutation, the parameter sourcing and the Master bus special case are adequately covered, and the dependency on list_realtime_effects and list_effect_presets is made clear. However, the description omits behavioral details like what happens on success or failure, and there is no output schema to fill that gap, so completeness is only adequate.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 documentation burden. It does so well: each parameter is explained with its source, and the special -2 value for the Master bus is called out. It could add details like zero-based indexing, but 'position in the chain' is reasonably clear.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The opening line names a specific action ('apply') and a specific resource ('a realtime effect's factory presets') by id. This distinguishes it from sibling tools like list_effect_presets or set_effect_parameter, 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.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The Args section gives clear guidance on where to obtain each parameter: track_id from project_get_info, index from list_realtime_effects, and preset_id from list_effect_presets, including the special -2 Master bus case. However, it does not explicitly explain when to use this tool versus setting individual effect parameters or other sibling operations.

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

• edit_cutB
  3.4/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It states that audio is cut to the clipboard, but it does not disclose that the source audio is removed, that the clipboard is overwritten, or anything about undo behavior. This is a mutation tool, so those missing details matter.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no filler. The action comes first, and the prerequisite is stated immediately after, making it easy to parse and act on.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple selection-based command with no parameters and no output schema, the description is mostly adequate. However, it lacks explicit mention of the destructive nature of cutting and clipboard overwrite, which leaves a meaningful gap for an agent invoking a mutation without annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description adds useful context by explaining that the tool operates on the current selection of tracks and a time range, which compensates for the empty input schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Cut') and resource ('selected audio to clipboard'), making the tool's core function easy to understand. It implicitly distinguishes from related siblings like edit_copy and edit_delete by specifying the clipboard destination, though it does not explicitly name any sibling.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear prerequisite: 'Select tracks and a time range first.' However, it does not explain when to choose this tool over alternatives like edit_copy, edit_delete, or edit_split, leaving the selection context implied rather than explicit.

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

• transport_play_regionB
  3.4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the core action and the start-position behavior, but it does not disclose whether the current selection is changed, whether ongoing playback is stopped, how invalid ranges are handled, or whether any state is modified beyond playback.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short and front-loaded: the main behavior is stated in the first sentence, followed by a compact parameter list. Every sentence adds necessary information with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter transport tool, the description is mostly adequate, but with no annotations and no output schema it leaves some important context unstated, such as interaction with existing playback and whether the region selection becomes the active selection. An agent could still invoke it correctly, but a bit more clarity would improve confidence.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only provides parameter names and types, while the description adds needed semantics: start and end are in seconds, and end must be >= start. This meaningfully compensates for the 0% schema description coverage, though it leaves out details like whether end is exclusive or whether bounds are validated against project length.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the operation: select a time region and play it starting from its beginning. It identifies the resource (time region) and the behavior, which distinguishes it from generic transport commands like transport_play. However, it does not explicitly contrast itself with sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended usage is implied: use this when you want to play a specific time range from its start. There is no explicit guidance on when not to use it or which sibling tool to prefer instead, such as transport_play for normal playback.

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

• auto_cleanup_interviewA
  3.5/5.0
  Behavior3/5

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

  The description discloses that it runs asynchronously (returns job_id immediately) and specifies the exact processing stages (DC offset, noise reduction, compression, LUFS loudness). It also explains the optional noise reduction parameter's behavioral requirement (first 0.5s must be room tone/silence). Since no annotations are provided, the description carries the full burden, and while it covers the key behavioral aspects, it doesn't address reversibility, permissions, or failure modes.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness3/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is clearly formatted with a summary line, pipeline, and args section, making it scannable. However, it's somewhat verbose with the ALL-CAPS headline and trailing sentence about natural dynamics, which could be tightened. The structure is good but not maximally efficient.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter background tool with an explicit pipeline description and monitoring pointer, the description covers the essential operational context. It lacks details about failure behavior, what happens after processing completes, and how to interpret the job_id, but given the simplicity and the check_pipeline_status reference, it's reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must carry the parameter meaning, and it does. The remove_noise parameter is explained in plain language ('Apply noise reduction using the first 0.5s as a noise profile'), including its default value and a critical usage warning about what the first 0.5s of audio must contain. This goes beyond the bare schema and adds actionable guidance.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states this is a one-click interview cleanup tool that applies light-touch processing for dialogue and multiple speakers, with an explicit pipeline listing. It distinguishes itself from sibling tools by name ('Lighter than podcast') and by function (interview-specific processing), though it doesn't name a specific sibling tool directly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states it runs in background and points to check_pipeline_status for monitoring, which gives clear usage context. It notes this is 'Lighter than podcast' and preserves natural conversation dynamics, which implies when to prefer this over podcast or other cleanup tools, but doesn't explicitly state when NOT to use it or name an alternative.

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

• effect_fade_outA
  3.5/5.0
  Behavior2/5

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

  There are no annotations, so the description carries the full burden of behavioral disclosure. It states that the tool applies a fade-out and requires a selection, but it does not mention whether the operation is destructive, reversible, or what actually happens to the audio beyond 'fade-out.' For a mutation tool, this leaves important behavior undisclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences: one states the action, one states the required precondition. There is no filler, and the essential usage requirement is included.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema, the description is mostly complete: it says what the tool does and what must be done first. It lacks explicit safety or reversibility guidance, but the operation is simple enough that this is a minor gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  This tool has no parameters, so there is nothing for the schema to document. The description appropriately refers to the selection prerequisite instead, which is the meaningful input the agent needs to understand.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action and resource: 'Apply a fade-out to the selected audio.' It distinguishes the tool from fade-in by direction, though it does not explicitly differentiate it from similar sibling tools like effect_studio_fade_out or effect_adjustable_fade.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an explicit prerequisite: 'Select the region to fade first.' This gives usable context for when to use the tool, but it does not mention alternatives, when not to use it, or how it compares to other fade-related tools.

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

• label_findA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It does disclose case-insensitive substring matching, but it does not explain the return format, search scope, or behavior with no matches or an empty query. 'Find' implies a read operation, but that is never made explicit.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the core behavior appears in the first sentence, followed by a short Args block. Every word earns its place with no unnecessary filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter search tool, the description covers the essential invocation details. However, with no output schema and no annotations, the return shape and project scope are left unspecified, so the definition is adequate but not fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only names the parameter as 'query' with type string. The description adds meaningful semantics by defining query as a substring to search for in label text, and the main sentence clarifies case-insensitive matching. This compensates for the 0% schema_description_coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific operation — 'Find labels whose text contains the given (case-insensitive) substring' — with a clear resource (labels), verb (find), and matching criterion. This distinguishes it from sibling label list/export/get-all tools, even though those alternatives are not named.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to use label_find versus label_list, label_get_all, or other label-related tools. The description only states what the tool does; no exclusions, prerequisites, or alternative routing are provided.

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

• select_cursor_to_track_endA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burnden and it does accurately describe the state-changing behavior: it creates a selection from the current cursor position to the track's latest clip. It does not disclose side effects such as whether the previous selection is replaced or how edge cases like a cursor after the last clip are handled, but for a simple selection tool the core behavior is present.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: one operation sentence followed by the only argument's origin. No redundant words or schema boilerplate, and the most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter selection action with no output schema, the description covers the essential invocation details: what the tool does and where to obtain track_id. It lacks usage guidance and some side-effect detail, but the tool is simple enough that an agent can mostly call it correctly from this description.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 does by explaining that track_id comes from project_get_info's track list, which gives the agent a concrete way to obtain a valid value. It does not add detailed format/range constraints, but it meaningfully goes beyond the bare integer type.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific operation: select from the current cursor position to the end of a track's latest clip. It clearly identifies the resource and the selection range, though it does not explicitly distinguish itself from sibling selection/cursor tools like select_region or cursor_to_track_end.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to choose this tool over the many sibling selection and cursor tools, and there are no exclusions or prerequisites. The operation is clear, but the agent receives no support in deciding between alternatives.

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

• select_tracksA
  3.5/5.0
  Behavior2/5

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

  With no annotations, the description carries the full behavioral burden. It states the basic selection operation and parameter meaning, but does not disclose whether the selection replaces the existing selection, whether tracks must already exist, or what happens on invalid indices. Silent on side effects beyond the bare selection action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose, followed by a clean Args block. Every sentence contributes necessary information, with no redundant or marketing language.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter selection tool, the description is moderately adequate but not fully complete. It does not explain selection replacement behavior, bounds, invalid track handling, or whether the count selection is contiguous, and there is no output schema or annotations to fill these gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must supply semantics for both parameters. It does: 'track' is clearly the starting index with 0-based convention, and 'count' is identified as the number of tracks to select. This is meaningful beyond the bare schema titles 'Track' and 'Count'.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Select'), names the resource ('tracks'), and provides the indexing mechanism ('by index'). This clearly distinguishes it from sibling tools like select_all, select_none, select_region, and select_clip, which operate on different scopes or selection modes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to use this tool versus alternatives. There is no mention of selecting all tracks, selecting clips, or using region-based selection, so the agent receives no explicit decision support for choosing among the many sibling selection tools.

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

• track_add_stereoA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It clearly communicates the mutative outcome (a new stereo track is created), but does not disclose whether the new track becomes selected, how it is positioned, or whether it is undoable. This is adequate but not rich for a creation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, front-loaded sentence with no filler. Every word contributes to the meaning, and it is appropriately sized for a zero-parameter tool.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the zero-parameter schema, simple behavior, and low complexity, the description is mostly complete. It covers what the tool does and the resource involved, though it could mention common side effects like selection changes for full completeness.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so according to the rubric the baseline is 4. The description adds meaning by specifying the type of track being created ('stereo'), leaving no ambiguity about what is added.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Add'), a specific resource ('new stereo audio track'), and the destination ('to the project'). It is clear and the word 'stereo' differentiates it from the sibling track_add_mono, though it does not explicitly name that alternative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to use this tool versus alternatives such as track_add_mono or when a stereo track is preferred. The description only states what it does, not the conditions under which an agent should choose it.

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

• transport_rewind_startA
  3.5/5.0
  Behavior3/5

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

  The core behavior is disclosed, but no annotations exist and the description does not state whether playback stops, whether selection is preserved, or how the command behaves during active playback. For a simple cursor-move command this is acceptable but not richly transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single declarative sentence with a front-loaded verb and target, no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter command with no output schema and no annotations, the description covers the essential action. It lacks side-effect details and sibling differentiation, but nothing needed to construct a valid call is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema is empty and there is nothing for the description to clarify beyond the action itself. The baseline of 4 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a concrete verb and resource: moving the playback cursor to the start of the project. It is clear on its own, but it does not differentiate from the close sibling cursor_to_project_start, which plausibly performs the same action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given about when to use this tool versus transport_play_stop, cursor_to_project_start, or other transport commands. The context is implied at best.

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

• check_pipeline_statusA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the basic action ('check status') and job_id provenance; it does not disclose whether the call is read-only, whether polling is expected, what statuses are returned, or how the job lifecycle behaves.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely compact: one clear opening sentence plus a one-line parameter explanation. Every word earns its place, and the key information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers how to get job_id and what to check, which is adequate for a simple tool. However, without annotations or an output schema, it omits the return format and status semantics, leaving an agent to guess what 'status' actually looks like.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Even though schema coverage is 0%, the description adds important meaning to job_id by explaining it is 'the job ID returned by an auto_ pipeline tool.' This tells the agent where to obtain the parameter, going beyond the schema's bare 'Job Id' string.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Check the status of a running cleanup pipeline.' This distinguishes it from check_transcription_status, though it does not explicitly name that sibling or otherwise call out the distinction.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: it is for cleanup pipelines and the job_id comes from an auto_ pipeline tool. It does not explicitly say when not to use it versus check_transcription_status or command_status, but the cleanup-pipeline wording makes the intended use reasonably clear.

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

• compressorA
  3.6/5.0
  Behavior3/5

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

  The description goes beyond the bare tool name by explaining each parameter's role, e.g., 'threshold_db: Level above which compression starts' and 'makeup_gain_db: Makeup gain applied after compression.' However, with no annotations at all, it does not disclose whether the operation is destructive/in-place, whether undo is available, or what happens if no audio is selected.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose, followed by a clean, well-organized parameter list with defaults. Every line earns its place with no redundant or promotional language.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers the tool's purpose and all parameters, which is adequate for calling it. But because there is no output schema and no annotations, it should also clarify the operational side effects — whether the selected audio is replaced, whether processing is applied non-destructively, and what a successful invocation returns.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description carries the full burden for parameter meaning. It successfully provides a plain-language definition, unit, and default for all six parameters, adding meaningful context the schema's bare numeric types and titles do not convey.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific operation — 'Apply dynamic range compression' — and identifies the target as 'the selected audio.' It is easily distinguishable as an audio effect, though it does not explicitly differentiate itself from sibling tools like limiter, normalize, or loudness_normalize.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is provided about when to use this tool versus alternatives such as limiter, normalize, or loudness_normalize. There is also no mention of prerequisites like having audio selected or whether it should be used on a clip versus a track.

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

• effect_clip_fixA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains what the effect does but does not disclose whether the operation is destructive, whether a selection is required, whether it returns a status, or how it affects existing audio. This is a meaningful transparency gap for a processing tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence purpose statement followed by a terse argument list. There is no filler, and the primary behavior is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with no output schema, the core invocation information is present. However, the absence of annotations and lack of any mention of side effects, selection requirements, return/status behavior, or alternative tools leaves clear gaps. It is minimally usable but not fully complete for confident selection among similar effect tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description fully compensates: it defines threshold as a clipping threshold percent with a 0–100 range and default 95.0, and gain_db as a gain adjustment in dB with a -30 to 0 range and default -9.0. This adds units, ranges, and defaults that the JSON schema lacks.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action and object: repairing clipped/distorted peaks in selected audio. The phrase 'clipped (distorted)' clarifies the exact problem and 'selected audio' scopes the operation. It does not explicitly differentiate it from similar siblings like effect_repair or limiter, but the verb+resource combination is clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use the tool: when the selected audio has clipped or distorted peaks. However, it provides no explicit when-not-to-use guidance and names no alternatives, even though siblings such as effect_repair, limiter, and auto_cleanup_audio may overlap. The usage context is present but only implicit.

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

• effect_sliding_stretchA
  3.6/5.0
  Behavior2/5

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

  No annotations are provided, so the description must carry the behavioral disclosure burden. It says 'change tempo and/or pitch gradually' but does not clarify whether the effect is destructive, whether a selection is required, how it interacts with existing audio, or what happens after application. This is a meaningful gap for an effect tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The one-sentence purpose is front-loaded and concise, and the Args block is structured and worth including because it supplies ranges, units, and defaults absent from the schema. No wasted words or redundant filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a four-parameter effect tool with no annotations and no output schema, the description covers the core behavior and all parameters. It remains incomplete on operational context such as whether the effect is applied destructively to the selection, whether a selection must exist, or what the resulting state is.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, and the description fully compensates by documenting all four parameters with units, ranges, and defaults: 'Tempo change at start in % (-90 to 500)' and 'Pitch change at start in semitones (-12 to 12)'. This adds real semantic value beyond the bare schema titles and defaults.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action—'Change tempo and/or pitch gradually across the selection'—with a clear resource (the selection) and a distinctive mechanism ('sliding time stretch'). It is clear and tells an agent what the tool does, though it does not explicitly name or contrast with closely related sibling tools like clip_stretch or effect_change_pitch.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case: apply this when you need gradual tempo and/or pitch changes across a selection. However, it provides no explicit guidance about when not to use it or which alternative tools might be better for fixed pitch or speed changes.

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

• label_listA
  3.6/5.0
  Behavior4/5

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

  Since no annotations are provided, the description carries the behavioral burden itself. It clearly indicates a read-only listing operation, scopes it to the first label track, and discloses what each result contains. It does not cover edge cases like a missing label track, but this is adequate for a simple list tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single front-loaded sentence that states the action, scope, and returned fields with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter listing tool, the description covers the essentials: scope and return fields. However, with no output schema, no annotations, and many sibling label tools, an agent would benefit from clarification on how label_list differs from label_get_all and what happens if no label track exists.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and 100% schema coverage, so there is no parameter documentation burden. The description supplies the relevant return-value detail that would otherwise be missing without an output schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('List') and names the exact resource: labels on the project's first label track. It also states the returned fields (key, text, time range), making the purpose clear. However, it does not explicitly distinguish itself from the similar sibling label_get_all.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance about when to use this tool versus label_get_all, label_find, or label_export. The only implicit context is the restriction to the first label track; no exclusions, conditions, or alternatives are provided.

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

• transport_stopA
  3.6/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden and does state the primary effect: playback is halted. It does not mention whether the cursor position is preserved, whether the call is a no-op when not playing, or any other side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two words and exactly captures the operation with no filler or repetition. Every part earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter transport action, this covers the basic invocation and intent. It is not fully complete because it leaves the sibling distinction and behavioral details unarticulated, which matter in a large tool set with transport_play_stop nearby.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema confirms this, so there are no parameter semantics to explain. The description does not need to add anything beyond the input schema for an agent to invoke it correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Stop') and a clear resource ('playback'), so an agent can tell what action is performed. It does not explicitly contrast with the sibling transport_play_stop, so the sibling differentiation is weaker than ideal.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  'Stop playback' implies the tool should be used when playback needs to be halted. However, it gives no explicit guidance about when not to use it or why it should be preferred over the similar-sounding transport_play_stop.

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

• cursor_to_track_endA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of explaining behavior. It clearly states the cursor is moved to the end of a track's latest clip, but it does not disclose edge-case behavior (e.g., empty track, multiple clips, invalid track_id) or whether selection/playhead state is affected. This is adequate but minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with the action stated first and the parameter guidance second. Every sentence earns its place and there is no filler or redundant restatement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with no output schema, the description covers the core behavior and the parameter provenance. Minor gaps remain around what qualifies as the 'latest clip' and what happens when a track has no clips, but the description is nearly complete for this simplicity level.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 for the sole parameter. It does so by explaining that track_id is the track's id from project_get_info's track list, providing the key semantic context missing from the schema. It could add error-handling detail, but for a single parameter this is strong.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Move the cursor') and a specific target ('the end of a track's latest clip'), which makes the tool's purpose unmistakable. It is distinguishable from siblings like cursor_to_track_start, though it does not explicitly name alternatives and could define 'latest clip' more precisely.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides no explicit when-to-use or when-not-to-use guidance compared with siblings such as cursor_set or cursor_to_track_start. However, it does tell the agent where track_id comes from ('project_get_info's track list'), which is useful operational context for invoking the tool correctly.

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

• edit_disjoinA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral disclosure burden. It states the primary effect (splitting selected audio into separate clips) and the necessary selection, which is useful. However, it does not disclose whether the operation is destructive, whether original clips are replaced or new clips are created, what silence-detection threshold is used, or how the result relates to undo/redo.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences with no filler. The action is front-loaded, and the prerequisite is stated immediately afterward. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema and no annotations, the description gives the essential operating steps: what the tool does and what the user/agent must do first. It is slightly weakened by the large set of near-sibling silence-splitting tools, but it is still complete enough for basic correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema is empty, so the baseline is 4. The description adds meaningful semantic context beyond the schema by explaining that the operation relies on the current track selection and time range, which is essential given there are no formal arguments.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Split') with a clear resource ('selected audio') and mechanism ('at detected silences'), and adds a prerequisite ('Select tracks and a time range first') that scopes the action. However, it does not distinguish itself from similarly named siblings like clip_split_at_silences or split_range_at_silences, leaving some ambiguity about which splitting tool to choose.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete precondition: select tracks and a time range first. This implies the intended usage context but gives no guidance about when to prefer this tool over sibling splitting/editing tools, nor does it mention any exclusions or alternative workflows.

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

• edit_undoA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral burden. It does disclose an important behavior: the tool fails cleanly when there is nothing to undo, which is useful for an agent deciding to call it. However, it does not explain what happens on success, whether multiple undos are supported, or how this interacts with project state and history.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no filler. The core action is stated first, and the failure behavior is a meaningful second sentence. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, low-complexity tool, the description covers the main action and a key edge case. It lacks detail on return values or the scope of an undo, but those are relatively minor given the simplicity of the operation and the availability of sibling edit_redo for context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the schema is trivially complete and the description has no parameter semantics to convey. Per the baseline for zero-parameter tools, this dimension deserves a solid score.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a clear verb ('Undo') and a specific resource ('the last edit'), making the tool's purpose immediately understandable. It does not explicitly differentiate from sibling edit_redo, though the opposite meaning is implicitly clear from the name and wording.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage by stating what the tool does, but it does not explicitly say when to prefer this over alternatives or mention any prerequisites. The note about failing cleanly provides a small amount of situational guidance, but there is no explicit when-to-use or when-not-to-use framing.

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

• label_removeA
  3.7/5.0
  Behavior2/5

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

  No annotations exist, so the description carries the full burden of behavioral disclosure. It only states the action itself, disclosing nothing about error behavior for invalid keys, reversibility/undo, whether the operation is destructive to associated audio, or what a successful removal returns. For a deletion tool with zero annotation coverage, this is a real gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two compact sentences, front-loaded with the action and followed by only the essential parameter detail. No filler, no repetition of schema structure. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter deletion tool, the core calling contract is covered: what it does, what the key looks like, and where to get it. However, it omits expected outcomes — success/failure behavior, side effects on audio, and whether removal is undoable. Adequate but with a clear behavioral gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 — and it does. It explains the key's exact format ('trackId:itemId') and its provenance (label_list/label_add), which is precisely the information an agent needs to construct a valid argument. Strong parameter-level guidance despite the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource — 'Remove a label' — with a precise mechanism ('by its key'). The key-format detail and the action verb clearly separate it from siblings like label_add, label_edit, label_update_text, and the region-deletion tools. Purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Implies a workflow: obtain a key from label_list/label_add, then remove. However, it never explicitly distinguishes this from similar-sounding siblings such as label_delete_regions, label_delete_audio_at, or label_edit, nor states when not to use it. Usage is inferable but not spelled out.

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

• normalizeA
  3.7/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the operation semantics (peak adjustment, DC offset removal, per-channel normalization) and gives the dB range, which is useful. However, it does not disclose whether the edit is destructive/in-place, whether it is reversible via undo, or how it interacts with the current selection beyond 'selected audio.'

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is one purpose sentence followed by a compact, uniformly formatted args block. It is front-loaded with the core action, and every line earns its place with no verbose filler. The structure is easy to scan and parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple tool with 3 optional parameters and no nested objects or output schema, the description covers everything needed to invoke it correctly: what it does, what each parameter means, valid ranges, and defaults. The main gaps are the absence of sibling differentiation and destructive-nature disclosure, both of which are already penalized in other dimensions.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must fully compensate, and it does. Each parameter gets a meaningful semantic explanation beyond its bare schema type: peak_level_db gets a range and default, remove_dc gets its behavioral purpose, and stereo_independent gets its effect on channel processing. The defaults are also restated inline for convenience.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear verb+resource+goal: 'Normalize the selected audio to a target peak level.' The phrase 'target peak level' gives the operation a specific target, and this mildly distinguishes it from loudness_normalize. However, it never explicitly names or differentiates the tool from its close siblings, so it stops short of full differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No guidance is given on when to choose this tool over alternatives. With 130+ siblings including loudness_normalize, effect_amplify, and effect_remove_dc_offset, the description provides no exclusions or conditions that would help an agent route to this tool correctly. Usage context is entirely absent.

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

• transcribe_selectionA
  3.7/5.0
  Behavior3/5

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

  No annotations are present, so the description carries the full burden. It discloses 'Requires separate setup', 'Runs in BACKGROUND - returns a job_id immediately', and '[EXPERIMENTAL]', which are useful behavioral traits. It does not explain how to retrieve the transcription result or what happens if no region is selected, leaving a notable gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the experimental warning and core scope before moving to prerequisites and parameters. Every sentence contributes, though the Args formatting uses a little extra space.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers setup, scope, background behavior, and parameter semantics, which is good for a 3-parameter tool. However, with no output schema or status-tool reference, an agent doesn't know how to retrieve the result or verify success; mentioning a status-checking sibling would make it complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, but the description's Args section fully compensates: model_size lists valid model choices, language explains ISO codes or None, and task lists 'transcribe' or 'translate'. This adds the semantic meaning entirely absent from the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Transcribe only the currently selected audio region', naming a specific verb, resource, and scope. It clearly distinguishes from broader transcription tools by emphasizing 'only' the selected region, though it does not name sibling alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives a concrete prerequisite: 'Select a region first, then call this tool' and notes background execution, which implies the right workflow. However, it does not explicitly compare against siblings like transcribe_audio or transcribe_to_file, nor state when not to use it.

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

• truncate_silenceA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It reveals the core operation and parameter behavior, including thresholds and durations, but does not state whether the operation is destructive/permanent, whether a selection is required beyond 'selected audio', or what the result/output will look like.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and efficient: one clear purpose sentence followed by a concise parameter list. Every line adds useful information, and there is no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 5-parameter tool with no annotations and no output schema, the description documents the operation and all parameters well. It is slightly incomplete in not addressing usage context relative to sibling tools or clarifying expected output, but it is largely sufficient for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description fully compensates by documenting all five parameters with units, ranges, and meaning. Each parameter gets a clear explanation: threshold_db, minimum_silence, truncate_to, compress_ratio, and independent_channels.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Find and shorten') and a clear resource ('runs of silence in the selected audio'). It clearly communicates what the tool does, though it does not explicitly differentiate it from sibling silence-related tools like edit_silence or auto_cleanup_audio.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives. The sibling list includes several silence-related operations, but the description provides no exclusions or selection criteria to help an agent choose between them.

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

• effect_crossfade_tracksA
  3.8/5.0
  Behavior2/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It states the operation and the curve types, but does not mention whether the effect is destructive, reversible via undo, or what happens to the underlying clips. This is a meaningful gap for an effect that modifies audio.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the actual behavior, followed by a clear parameter breakdown. Every sentence earns its place with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool, the description is reasonably complete: it states the operation, the target context, and the parameter options. However, it omits prerequisites such as needing an active selection and two overlapping tracks, and it does not clarify relationship or distinction from effect_crossfade_clips.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description fully compensates by documenting the only parameter with all meaningful values: 0=Constant Gain, 1 and 2 as Constant Power variants, 3=Custom Curve, plus the default. This provides real value beyond the bare schema field.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the operation as a crossfade applied to a selected region between two overlapping tracks. This is specific enough to distinguish it from the sibling tool effect_crossfade_clips, which targets clips rather than tracks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when you have two overlapping tracks and a selected region to crossfade, but it does not explicitly state when to use this tool versus alternatives like effect_crossfade_clips. No exclusion criteria or alternative routing is provided.

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

• effect_tremoloA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full behavioral disclosure burden. It says 'apply' but does not state whether the operation destructively modifies the audio, whether it is reversible, what happens if no audio is selected, or what the tool returns. This is a significant transparency gap for a mutating effect tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well structured: a one-sentence purpose statement followed by a clean parameter list. Every line provides necessary information, and there is no filler or repetition of schema metadata that would be redundant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Parameter documentation is complete and the target 'selected audio' is stated, which covers the main calling context. However, with no annotations and no output schema, the description omits behavioral context such as side effects, prerequisites beyond selection, and success/failure behavior, leaving the tool less than fully self-contained.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description fully compensates by documenting all four parameters: wave_type with exact value-to-waveform mapping, phase_degrees with range, wet_percent with range, and lfo_hz with units and range. It also provides defaults for every parameter, going well beyond the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action and target: 'Apply a tremolo (amplitude modulation) effect to the selected audio.' The parenthetical defines the effect, and the tool name plus effect type clearly distinguish it from sibling effect tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool—when a tremolo effect is desired on selected audio—but it does not explicitly explain when not to use it or how it compares to alternative effect workflows such as add_realtime_effect. Usage guidance is present but only implied through the effect name.

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

• label_add_trackA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It states the core action and result—creating a new empty label track—but does not mention side effects like whether it requires an open project, whether it selects the new track, or whether the operation is undoable. The 'empty' qualifier adds some useful behavioral context, but the disclosure is minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, efficient sentence that front-loads the action and the resource. Every word earns its place, with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's simplicity (zero parameters, no schema, no output schema), the one-sentence description is mostly complete: it tells the agent exactly what will happen. It could additionally clarify that the track is created in the current project or that no labels are added, but such context is readily inferable and not a significant gap for a no-argument command.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool takes zero parameters, so the schema is empty and the description does not need to document any inputs. The description 'Create a new, empty label track' adds meaningful context about the outcome, which is sufficient for a parameterless tool; the baseline for zero parameters is 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Create') and a clear resource ('new, empty label track'), which unambiguously distinguishes it from siblings like label_add (which adds labels) and track_add_mono/stereo (which add audio tracks). The word 'empty' also clarifies the initial state of the created track.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines2/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  There is no guidance on when to use this tool versus alternatives such as label_add, label_add_at, or track_add_mono. The description simply states what the tool does without providing selection criteria, prerequisites, or exclusions, leaving the agent to infer usage solely from the name.

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

• noise_reductionA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden. It discloses the prerequisite but not whether the operation is destructive/reversible, how it affects the selected clip, what errors occur if no profile or selection exists, or what the tool returns. This is a significant transparency gap for a tool that modifies audio.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: one prerequisite sentence and a short parameter list, with no filler. The critical workflow is front-loaded before parameter details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The prerequisite and parameter ranges make the tool callable, but the absence of any output-schema or behavioral notes leaves gaps around side effects, success/failure signals, and selection requirements beyond 'selected audio'. It is adequate but not fully self-sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description supplies meaning for all three parameters, including value ranges and defaults (sensitivity 0.01–24, noise_gain_db 0–48, frequency_smoothing_bands 0–12). This fully compensates for the schema's bare titles/defaults.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a concrete verb ('Apply') and resource ('noise reduction' to the selected audio), and clarifies that it is the application step after get_noise_profile. It doesn't explicitly contrast with sibling cleanup effects like click_removal or auto_cleanup_audio, but the operation is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides an explicit ordered workflow: call get_noise_profile on pure noise first, select the audio, then call this tool. This gives clear context for invocation. It does not state when to prefer this over similar cleanup/effect tools, so it stops short of full alternative routing.

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

• track_add_monoA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the core action but does not mention side effects, whether the new track becomes selected, or whether it is added at the end of the track list. 'Add' implies non-destructive, but the description stops short of explaining any observable outcomes beyond the bare action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence with no extraneous words. The action, object, and target are all front-loaded and clearly stated. The description earns its place and nothing more is needed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema, the description is nearly complete: an agent knows exactly what action will occur. It does not mention return values or post-conditions, but for a simple 'add track' operation these are largely self-evident. A minor omission is the lack of detail about where the track is added (e.g., end of session), but this does not significantly hinder correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0 parameters and 100% schema description coverage (trivially, since there are no properties), the description does not need to add parameter details. The baseline for 0-parameter tools is 4, and nothing in the description is missing or misleading on this front.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Add'), a specific resource ('mono audio track'), and a clear target ('to the project'). It also differentiates from the sibling `track_add_stereo` by explicitly naming the mono variant, leaving no ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when a mono track is needed. However, it does not explicitly state when not to use it or reference `track_add_stereo` as the alternative. The distinction is left to inference from the tool name and sibling list, so guidance 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.

• check_transcription_statusA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the behavioral burden. It discloses polling expectations and terminal statuses ('complete' or 'error'), which is useful. However, it does not describe the full response shape, behavior on invalid job IDs, or whether repeated calls are idempotent, leaving some ambiguity for a no-annotation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and scannable: a label, a short usage direction, a polling instruction, and a one-line args section. Every sentence is functional, and the critical usage context is front-loaded. No filler or repetitive content exists.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter polling tool with no output schema, the description covers the essential workflow: when to call, how often to poll, and when to stop. It implies a status field with values 'complete' or 'error,' which is likely enough for an agent. It could be more complete by stating exact response fields or error behavior, but it is adequate for its simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 does so by explaining that job_id is 'The job ID returned when you started the transcription,' which adds provenance and meaning beyond the bare schema property name. This is sufficient for the single required parameter, though a bit more detail on format or where to find it could push it higher.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Check the status of a running transcription job.' It also references the transcription-starting siblings, which clarifies its role in the workflow. However, it does not explicitly distinguish itself from check_pipeline_status or command_status, so it falls just short of full differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear when-to-use guidance: 'Call this after starting transcribe_audio, transcribe_to_labels, or transcribe_to_file.' It also provides a polling cadence and termination conditions. It does not mention when not to use it or name alternatives, so it lacks the exclusionary guidance of a perfect score.

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

• click_removalA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full disclosure burden. It does state the operation and scoping ('from the selected audio') and explains how threshold and spike_width affect detection, but it does not disclose whether the edit is destructive, reversible, or whether a selection is strictly required before invocation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: one clear purpose sentence followed by a minimal, well-structured Args block. Every line provides useful information, with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter effect tool with no output schema or annotations, the description covers the operation, scope, parameter ranges, defaults, and parameter effects. It could be slightly more complete by noting what happens if no audio is selected or whether the operation modifies the clip in place, but as a simple effect it is largely sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, yet the description fully compensates by explaining each parameter's meaning, valid range, and default: threshold (0-900, higher = fewer clicks removed) and spike_width (0-40, maximum click width). This goes well beyond the bare schema properties.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource: 'Remove clicks and pops from the selected audio', which is clear and actionable. It also gives a helpful example context ('vinyl recordings'), though it does not explicitly distinguish itself from sibling repair/cleanup tools like effect_repair or auto_cleanup_audio.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool should be used when clicks or pops are present in selected audio, but it does not state when not to use it or compare it to alternatives. There is no explicit routing guidance among the many sibling cleanup/effect tools, so the usage context is only implied.

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

• effect_remove_dc_offsetA
  3.9/5.0
  Behavior3/5

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

  With no annotations present, the description carries the burden of behavioral disclosure. It explains the core effect, the peak-level preservation, and the fact that it takes no parameters. However, it does not disclose whether the operation is destructive, whether a selection is required, or what happens if no audio is selected.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is reasonably concise and front-loaded: the first sentence states the core purpose and the second provides implementation context. The second sentence is slightly verbose with versioning/verification details, but it still earns its place by clarifying the relationship to normalize().

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, parameterless effect tool, the description covers the main operational facts: what it does, what it preserves, and that no parameters are needed. It could be more complete by clarifying selection requirements and side effects, but the low complexity keeps the gap modest.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema already reflects that, but the description explicitly confirms 'Takes no parameters.' This removes any ambiguity and meets the baseline for a no-parameter tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: 'Remove DC offset from the selected audio'. It also adds a meaningful constraint ('without changing its peak level') and distinguishes this tool from the related normalize() tool by describing it as the DC-only variant with volume normalization disabled.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives useful context by relating the tool to normalize() and specifying the exact parameter mode (ApplyVolume=0), but it does not explicitly state when to prefer this tool over normalize() or other effects. The intended use case is implied by the name and first sentence rather than stated as selection guidance.

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

• effect_reverseA
  3.9/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden of explaining behavior. It does state the core behavior and the selection requirement, but it does not disclose whether the effect is destructive/in-place, whether it can be undone, or what happens if no region is selected. These are meaningful gaps given the absence of annotations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences deliver the action and the key prerequisite with no filler. The description is front-loaded, easy to parse, and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-output-schema effect tool, the description is nearly complete: it names the operation and the precondition. It could add notes about undoability or in-place modification, but those are not required for an agent to invoke it successfully after selecting a region.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so the baseline is 4. The description sensibly treats the selected region as the implicit operand and gives the prerequisite for it, which is sufficient since no formal parameters exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Reverse') on a specific resource ('the selected audio'), so an agent can understand the tool's core purpose. It does not explicitly distinguish itself from audio-inversion siblings like effect_invert, but 'reverse' is unambiguous enough in the audio context.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  'Select a region first' provides an explicit, actionable prerequisite and tells the agent the required precondition before invoking the tool. It does not mention alternatives or when-not-to-use, so it falls short of a 5, but it gives clear context beyond the tool name.

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

• label_addA
  3.9/5.0
  Behavior3/5

  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.

  Conciseness5/5

  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.

  Completeness4/5

  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.

  Parameters4/5

  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.

  Purpose4/5

  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.

  Usage Guidelines4/5

  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.

• label_split_regionsA
  3.9/5.0
  Behavior4/5

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

  With no annotations available, the description carries the full behavioral burden. It usefully discloses that order does not matter, that splitting does not shift anything, and that labels remain in place. This addresses common concerns about non-destructive splitting, though it does not mention undo behavior or whether all clips/labels are affected.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences front-load the main action and scope, then add only relevant behavioral clarifications. Every sentence earns its place with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-output-schema tool, the description is largely sufficient: it states what happens and reassures about ordering and label placement. A minor gap is that it does not explicitly state whether the split applies to all audio clips globally, but 'the audio clips' strongly implies so.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool accepts zero parameters, so there is no parameter meaning to explain. The baseline of 4 applies because the description need not compensate for missing schema coverage of parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Split') and resource ('audio clips') and clearly defines scope ('at every label's start and end boundary'). It is clear and accurate, but it does not explicitly differentiate from sibling tools like label_cut_regions or label_delete_regions, relying on the word 'split' alone to imply non-destructive behavior.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when you want to split audio at label boundaries without shifting content. However, it provides no explicit guidance on when not to use it or which sibling tool to prefer (e.g., label_cut_regions for cutting/deleting regions). The context is implied rather than stated.

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

• select_zero_crossingA
  3.9/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full burden. It clearly states that selection boundaries are adjusted to zero crossings and why that matters. However, it does not disclose prerequisites (e.g., an existing selection), whether the operation is reversible, or whether it affects only the selection and not the underlying audio.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, no filler, and the core action is front-loaded. The 'useful before cuts' rationale adds purpose without bloating the description.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless tool acting on the current selection, the description is largely complete: it says what it does, why it is useful, and when to use it. The only minor gap is no mention of alternatives or edge cases, but the tool is simple enough that this is acceptable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema description coverage is 100%, so there is no parameter documentation burden. The description correctly focuses on behavior rather than parameters.This matches the baseline for a parameterless tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Adjust the current selection boundaries') and a clear resource ('current selection boundaries'), and explains its purpose ('nearest zero crossings'). It is clear and distinguishes itself from cut operations, but it does not explicitly differentiate itself from the sibling tool 'nearest_zero_crossing'.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides clear context for when to use the tool: 'Useful before cuts to avoid audible clicks at edit points.' This tells an agent the practical scenario, though it does not mention when not to use it or name alternative tools like edit_cut or nearest_zero_crossing.

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

• track_duplicateA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It states the operation and the selection prerequisite, which is useful, but it doesn't disclose side effects such as whether the new duplicates are selected, where they appear, or their naming. For a simple non-destructive command this is acceptable but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences with the action front-loaded and the prerequisite stated immediately after. No filler or redundant detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema and no annotations, the description covers the essential action and the required selection step. The main gap is not explicitly distinguishing track_duplicate from sibling edit_duplicate, though the word 'track(s)' and the select_tracks prerequisite mitigate that ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema is empty and parameter coverage is 100%, so there are no parameters for the description to document. Baseline 4 applies for a zero-parameter tool; the description also correctly routes input through select_tracks.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Duplicate') and resource ('currently selected track(s)'), which conveys the core action clearly and helps distinguish this from clip-level edit operations like edit_duplicate. It doesn't explicitly call out sibling alternatives, so it stops short of the strongest differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly says to select tracks first with select_tracks, giving the agent an actionable prerequisite. There is no mention of when not to use this tool or which sibling to prefer instead, but for a zero-parameter command that is adequate context.

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

• track_removeA
  3.9/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the behavioral disclosure burden. It does disclose the destructive action and the selection precondition, but it does not mention consequences such as irreversibility, undoability, or behavior when no tracks are selected. This leaves some behavioral ambiguity for an agent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, with the core action first and the prerequisite second. Every word contributes; there is no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool, this definition gives the core action and the required precondition. It is mostly complete, though a note about irreversibility or no-selection behavior would make it fully robust given the absence of annotations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema is empty, so there are no parameter semantics to document. The description still usefully points to select_tracks as the way to establish the target tracks, which is more than the schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action ('Remove') and resource ('currently selected track(s)'), making the tool's purpose unambiguous. It does not explicitly differentiate from close siblings like edit_delete or label_remove, but the track-specific scope is clear.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an explicit usage prerequisite: 'Select tracks first with select_tracks.' This tells an agent what must happen before invoking this tool. It does not discuss when not to use it or mention alternatives, so it stops short of full guidance.

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

• track_set_colorA
  3.9/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral disclosure burden. It discloses that the tool modifies a color tag and that color_index 0 means 'no custom color, inherit default', which is useful. It does not mention behavior when no track is selected, whether this affects track headers versus clips, or reversibility, but for a simple color-set operation this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the core action and target are in the first sentence, followed by the key prerequisite and parameter explanation. Every sentence contributes necessary information without excess.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with no output schema, the description covers purpose, valid input range, and the selection prerequisite. A slight gap is the lack of stated error behavior or no-op behavior when no track is selected, but the description is otherwise complete for this simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides only an integer property with 0% description coverage. The description compensates by documenting the valid range '0 to 9' and the special meaning of 0 ('no custom color, inherit default'). It does not enumerate what each specific color index 1-9 maps to, but it covers the essential semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action ('Set the color tag'), the target ('currently selected track(s)'), and the purpose ('visual organization'). It does not explicitly name a sibling alternative like clip_set_color, but the track scoping makes the resource clear enough to avoid confusion.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a concrete usage prerequisite: 'Select tracks first with select_tracks.' This is valuable operational guidance. It does not mention when to use this versus an alternative, so it stops short of full differentiation guidance.

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

• auto_cleanup_podcastA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden, and it delivers: it discloses that the tool runs in the background, returns a job_id immediately, and details the processing chain with concrete parameters (-16 LUFS Apple Podcasts target, 4:1 compression, clip-safe fallback). It even surfaces a critical precondition about the first 0.5s needing to be room tone/silence. The only gap is that it never says what audio the pipeline operates on (selection vs. whole track) or whether the result is destructive or written to a new file.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence earns its place: purpose and async behavior are front-loaded, the pipeline is compressed into a single arrow-separated line, and the parameter details are cleanly separated. The IMPORTANT warning justifies its emphasis. No filler or repetition of schema data.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter background job, the description covers the invocation essentials: the pipeline, the monitoring path, and the parameter precondition. But with no annotations and no output schema, material gaps remain — nothing states the input scope (selection, track, or project), whether the operation is destructive, or where the processed audio output lands, all of which an agent needs to invoke correctly and set expectations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must fully compensate, and it does. For remove_noise it explains the mechanism (uses first 0.5s as noise profile), states the default (True), and flags a critical usage precondition (first 0.5s must be room tone/silence). This adds real semantic depth far beyond the bare boolean in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('ONE-CLICK PODCAST CLEANUP') on a specific resource (podcast audio) and enumerates the exact pipeline stages (DC offset, noise reduction, compress 4:1, LUFS loudness). The 'podcast' target distinguishes it from siblings like auto_cleanup_interview and auto_cleanup_vocal, though it never explicitly says 'use this for spoken-word podcast content.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly instructs the agent to use check_pipeline_status after invocation to monitor the background job, which is genuinely useful routing guidance. However, it gives no conditions for when to pick auto_cleanup_podcast over the many sibling auto_cleanup_* variants (audio, interview, vocal, live), so the when-vs-alternatives guidance is only implied by the name.

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

• auto_cleanup_vocalA
  4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the behavioral disclosure burden and does a solid job by explaining background execution, immediate job_id return, the exact pipeline stages, and how remove_noise uses the first 0.5s as a noise profile. It omits what the tool operates on (selected audio or a track) and whether the cleanup is destructive, which prevents a perfect score.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the main purpose, then explains background behavior, pipeline steps, and the parameter in a compact, structured way. Each section earns its place, though a few words like 'Professional' add little information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter background tool, the description is nearly complete: it covers the processing chain, the job_id return, how to monitor results, and the important noise-profile caveat. The missing input scope (what selection or track is processed) and lack of any note about reversibility/destructiveness are the main gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only provides a boolean with a default and no description, so the help text fills the entire gap. It explains the semantics of remove_noise, its default True, and the critical precondition that the first 0.5s should be room tone or silence, which is invaluable for correct invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states that the tool performs one-click vocal cleanup with professional processing for singing and studio vocals, giving a specific resource and intent. It is distinguishable from podcast/interview/live siblings by its vocal focus, though it does not explicitly name or compare itself to those alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context: it is for vocal tracks and should be monitored via check_pipeline_status. However, it does not say when to avoid this tool or which sibling should be used for non-vocal content, so the selection of this tool over alternatives is left largely implicit.

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

• clip_reset_speedA
  4/5.0
  Behavior2/5

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

  No annotations are present, so the description must carry the full burden. It states the operation ('revert') but does not disclose whether the action is destructive, whether it fails if no speed change exists, or whether it resets to original speed versus 1x. It also omits any side effects on other clip properties.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two concise lines with the main purpose front-loaded and no filler. The Args section adds necessary parameter detail without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool, the description covers the operation and the key format, which is sufficient for basic invocation. However, it lacks any mention of error behavior or prerequisites, and without annotations or an output schema, a bit more behavioral context would be helpful.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  With 0% schema description coverage, the description compensates by explicitly defining the key parameter format as 'trackId:itemId'. This is essential for correct invocation and adds meaning beyond the bare schema type.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb 'Revert' and a clear resource ('a clip's speed change'), and it references the counterpart tool clip_set_speed, making its scope unambiguous. This distinguishes it from pitch-related siblings like clip_reset_pitch and clip_reset_pitch_speed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage when a speed change was previously applied via clip_set_speed, giving a clear trigger condition. It does not explicitly name alternatives or state when not to use it, but the reference to clip_set_speed provides enough contextual routing for an agent.

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

• cursor_to_track_startA
  4/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the behavioral burden. It clearly states the cursor movement and the specific destination, but it does not comment on side effects, selection changes, undo behavior, or what happens when a track has no clips. For a simple navigation command this is adequate though not exhaustive.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences: a clear action sentence followed by a compact parameter explanation. Every word earns its place, and the core behavior is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter navigation tool with no output schema, the description gives the essential behavior and parameter provenance. It could additionally mention behavior for invalid track IDs or tracks without clips, but those are edge cases rather than blockers for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only provides the parameter name and integer type; the description adds real meaning by explaining that track_id comes from project_get_info's track list. This tells the agent how to obtain a valid value, which is valuable given 0% schema description coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Move'), a precise target ('the start of a track's earliest clip'), and identifies the resource via track_id. This clearly distinguishes it from siblings like cursor_to_track_end, cursor_to_project_start, and cursor_set.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when to use this tool: when you need the cursor positioned at a track's earliest clip. It also tells where to get track_id ('from project_get_info's track list'), which is useful. However, it does not explicitly contrast with alternative cursor-navigation tools or state when not to use it.

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

• edit_splitA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral burden. It discloses that the operation is in-place, creates no new track, and acts on selected clips at selection boundaries. However, it does not mention whether the original clips are modified destructively, whether the split creates multiple clips, or any undo/safety considerations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with no filler. The core action and scope are front-loaded, and the prerequisite is stated in a clear, actionable second sentence.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-output-schema tool, the description is reasonably complete: it states the action, the target, the in-place behavior, and the required selection state. The main missing piece is explicit routing among split-related siblings, but that is a usage-guideline matter rather than a fundamental completeness gap.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description compensates by explaining that the tool relies on current editor state ('Select tracks and a time range first') rather than arguments, which is meaningful context beyond the empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Split'), a specific resource ('selected clip(s)'), and a precise condition ('at the selection boundaries'). It adds distinguishing detail with 'in place, no new track', which separates it from sibling tools like edit_split_new.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear prerequisite ('Select tracks and a time range first'), which helps an agent know the required state before invoking. However, it does not explicitly say when to prefer this tool over closely related siblings such as edit_split_new, edit_split_cut, or edit_split_delete.

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

• edit_split_newA
  4/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral disclosure burden. It clearly reveals the key side effect: the original track stays unchanged while audio is split into a new track. It does not cover details such as how multiple selected tracks are handled, the post-operation selection state, or error conditions when no selection exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no filler. The action and key side effect are front-loaded, and the prerequisite follows naturally at the end.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a selection-driven editing command with no output schema and no formal parameters, the description covers the operation, the non-destructive result, and the required preconditions. It is slightly incomplete in not clarifying behavior with multiple selected tracks or naming sibling tools for alternative edit operations.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero formal parameters, so the schema coverage is trivially 100% and the baseline is 4. The description adds meaning by identifying the real inputs—tracks and a time range—that are supplied via selection rather than the schema. No parameter-level detail is needed because there are no declared parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Split'), a clear resource ('the selected audio into a new track'), and a boundary condition ('at the selection boundaries'). The phrase 'leaving the original track unchanged' explicitly distinguishes this from destructive split/cut siblings, making the tool's purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides a clear prerequisite ('Select tracks and a time range first') and implies the non-destructive use case by saying the original remains unchanged. However, it does not explicitly name alternatives such as edit_split, edit_cut, or edit_split_delete, nor does it state when NOT to use this tool.

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

• effect_invertA
  4/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the transformation (phase inversion) but does not disclose whether the operation is destructive, whether the selected audio is replaced, whether undo is available, or what the success/return behavior is. For a mutation tool, this is a meaningful gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences with no filler. The operation is front-loaded in the first sentence, and the practical use case is added in the second. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter effect tool, the description is mostly complete: it says what the tool does and when it is useful. The main gap is the lack of any mention of result or side-effect behavior, which is more noticeable because there is no output schema to fill that in.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so the baseline is 4. The description implicitly identifies the operand as 'the selected audio,' which is the only contextual detail needed. No parameter documentation is required beyond this.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Invert (flip phase) the selected audio.' The parenthetical 'flip phase' disambiguates from sibling tools like effect_reverse, which reverses time rather than polarity. It clearly identifies the operation and object.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a clear use context: 'Useful for phase cancellation.' This implies when an agent should consider using the tool, though it does not explicitly mention alternatives or when not to use it. There is enough context to route correctly among the many effect siblings.

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

• generate_rhythm_trackA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It does explain parameter behavior—defaults, ranges, and the interaction between num_bars and duration_seconds. It also reveals that start_offset creates silence before the first beat. However, it does not describe what the output is (e.g., a generated track in the project), whether it requires a selected track, whether it creates a new track, or how the generated click track behaves after generation. With such a detailed parameter list, a fuller behavioral disclosure was possible.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a compact docstring-style paragraph followed by a clear Args list. Every parameter earns its place with a range and/or purpose. It is slightly long, but for a 9-parameter generation tool, the density is justified. The core verb+resource sentence is front-loaded. The main deduction is that the parameter list is formatted as an Args block that is slightly repetitive with defaults already visible in the schema, though the ranges and semantics add value.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 9-parameter generation tool with no output schema, the description is highly complete on parameters and generation semantics. It explains tempo, time signature, swing, bar counting, duration-based mode, silence offset, click timbres, and pitches. Missing pieces are workflow context: whether this generates a new track, requires a destination track, or what state the project must be in. Sibling generation tools like generate_tone likely need the same context, but the description doesn't state it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, yet the description documents all 9 parameters with ranges and defaults—far beyond the schema's bare type/title/default. It explains the meaning of tempo_bpm, beats_per_bar as time signature numerator, swing, the choice between num_bars and duration_seconds, and the click_type enum values. It also gives strong/weak beat pitch definitions. This fully compensates for the lack of schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description starts with an explicit verb and resource: 'Generate a metronome/click rhythm track.' This clearly distinguishes it from sibling generation tools like generate_tone, generate_chirp, generate_noise, generate_dtmf, and generate_silence. The phrase 'metronome/click' immediately tells an agent what kind of audio this tool produces.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains parameters such as num_bars and duration_seconds, with explicit guidance like 'Set to 0 to use duration_seconds instead' and 'used only when num_bars is 0.' This is useful selection between modes. However, it does not explicitly state when to choose generate_rhythm_track over generate_tone or other generation tools, nor does it give exclusions. The context of a click/metronome track is implied but not stated as a 'when-to-use' statement.

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

• label_importA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and discloses key behaviors: it parses the file directly, skips and reports unparseable lines rather than failing, and adds labels via the same primitives as label_add_batch. It does not mention whether labels are appended to an existing track or whether a label track must already exist, but the stated behavior is more transparent than most.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the primary purpose and file format. The v3 comparison is slightly extra but provides useful rationale for the implementation. Each part contributes to understanding the tool's behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter tool with no output schema, the description is mostly adequate. It explains format, error handling, and the parameter. Missing material details include whether an existing label track is required or created, whether import appends or replaces existing labels, and what the return value is.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description compensates with an Args section specifying that 'path' is the absolute path to the labels text file. It also explains the file format earlier, giving the parameter meaningful context beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Import labels from a standard Audacity label text file' and specifies the exact tab-separated format. It distinguishes itself from sibling label tools by explaining that it parses the file directly and uses the same primitives as label_add_batch, and from v3's ImportLabels command.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is for file-based label import and explains why it exists (no C++ primitive in v4). However, it does not explicitly contrast it with alternatives like label_add, label_add_batch, or label_export, nor does it state when not to use it.

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

• limiterA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must disclose behavior. It explains the limiting behavior and each parameter's effect (threshold, ceiling, release, knee), which is substantive. However, it does not state whether the effect is destructive/reversible, how it interacts with selection, or what output is produced.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One-purpose sentence followed by a clean, tabbed Args list. No filler, and the parameter details are front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  All four parameters are fully documented and the core function is clear, so it is near-complete for a simple audio effect. But without annotations or output schema, it should also mention selection scope, undoability, and when to prefer compressor or loudness_normalize. These omissions leave modest gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description fully compensates with an Args section that defines every parameter, including the default values and the industry-standard streaming ceiling note. This is precisely the semantic information the schema lacks.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States the specific operation 'Apply a limiter' and defines its function as 'prevent audio from exceeding a ceiling.' The ceiling concept clearly distinguishes it from sibling dynamics tools like compressor and loudness_normalize.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies usage through 'prevent audio from exceeding a ceiling,' which tells an agent when it applies, but it does not explicitly discuss alternatives or when not to use it. No exclusion criteria against sibling effects like compressor is provided.

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

• project_get_metadataA
  4/5.0
  Behavior3/5

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

  No annotations are provided, so the description must carry the behavioral disclosure burden. It does disclose one important non-obvious behavior: the 'year' field defaults to '2018' for new projects, which is a stale template default rather than the current date. However, it does not mention return format, error behavior, or assumptions about an open project, leaving several behavioral aspects undisclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no filler. The first sentence states the core operation and result fields, and the second provides a high-value implementation quirk about the 'year' default. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter getter with no output schema, the description is largely complete: it identifies the tool's result fields and flags a surprising default value. It could be more complete by describing the structure of the returned metadata or noting whether it requires an open project, but those are minor gaps given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema coverage is 100%, so there is no parameter burden to compensate for. The description adds meaningful semantics by naming the metadata fields returned, which is useful context beyond the empty input schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Get project metadata tags' and then enumerates exactly which fields are returned (artist, track title, album, track number, year, comments). This makes the tool's purpose unmistakable and distinguishes it from generic project tools like project_get_info.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the tool is used when reading project metadata tags, but it does not explicitly state when to prefer this over siblings such as project_get_info or project_set_metadata. There is no 'use this instead of...' guidance, so the usage context is only implied rather than explicitly routed.

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

• project_saveA
  4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden. It discloses two refusal conditions and instructs the agent to inspect isError and the returned message. It does not explicitly state that a successful save overwrites the existing file, which is a meaningful side effect of a save operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no unnecessary words. The primary action is front-loaded, and the additional behavioral constraints are compact and directly relevant.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema, the description is complete: it states the action, the conditions under which it refuses, and how to interpret failures. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there are no parameter semantics to document. The baseline of 4 applies since nothing is missing from the parameter perspective.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Save the current project.' It does not explicitly differentiate from the sibling tool project_save_as, but the refusal condition 'has no file path yet' hints at the distinction. This is clear but lacks explicit sibling differentiation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context about when saving will fail: never-saved projects and no unsaved changes. However, it does not explicitly mention when to use project_save_as instead, leaving the alternative to be inferred. The usage guidance is implied rather than stated.

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

• project_set_metadataA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure. It non-obviously states that only supplied fields are changed and that an empty string clears a field, which is essential. It does not clarify null vs empty semantics or return value, but these are minor for a setter.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: main action first, then the partial-update rule, then a flat Args list. No filler and each line earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a six-parameter tool with no annotations and no output schema, the description gives the core behavior, partial update semantics, clearing convention, and all fields. Missing null handling and return behavior are minor for a simple setter.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters3/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description is responsible for parameter meaning. It lists every parameter but mostly restates the parameter names ('Artist name.', 'Track title.'). The partial-update rule applies globally, but no specific formats for track_number, year, or null handling are provided.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Set one or more project metadata tags' and enumerates all six fields. It is clearly distinguished from sibling project_get_metadata by the set vs get verb.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys the key usage context: partial update, only passed fields are changed, and empty string clears a field. However, it does not mention alternatives or exclusions, so the agent must infer when to choose this over sibling like project_get_metadata.

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

• clip_reset_pitchA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries responsibility for explaining behavior. 'Revert' clearly indicates a state-changing operation, and the link to clip_set_pitch clarifies the scope. However, it does not disclose what happens when no pitch change exists or whether the operation affects other clip properties.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  One direct sentence plus a compact argument definition. No filler, fluff, or repetition of schema details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter reset tool, the description is largely sufficient: it explains the action and the key format. It could be more complete by noting the relationship to clip_reset_pitch_speed, but this is a minor gap given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, but the description fully compensates by explaining the only parameter: key is the clip's key in 'trackId:itemId' format. This adds meaningful information beyond the schema's bare 'string' type.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource: 'Revert a clip's pitch change'. It also names the paired tool clip_set_pitch, making the operation unambiguous and differentiating it from speed resets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'made via clip_set_pitch' implies the tool should be used after a pitch change was applied, but it does not explicitly contrast with siblings like clip_reset_pitch_speed or clip_reset_speed. Usage context is clear but alternatives are not addressed.

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

• clip_trimA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does well: it discloses that audio is discarded, exactly how positive and negative delta_sec behave, and that min_clip_duration constrains the result. It could go further by stating whether the operation is destructive/undoable or what happens on failure, but core behavioral traits are covered.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded with the core purpose, followed by a clarifying live-confirmed example and compact parameter docs. Every sentence earns its place without unnecessary padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 4-parameter mutation tool with no output schema or annotations, the description provides enough detail to call it correctly: all parameters, edge semantics, and minimum duration are explained. It is slightly incomplete on return values and failure behavior, but those are secondary for this tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the Args section fully compensates by explaining each parameter: key format, side values, delta_sec direction, and min_clip_duration default. This adds substantial meaning beyond the bare input schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the verb and resource: trimming a clip's left or right edge inward by a delta in seconds and discarding audio. It is specific and self-contained, but it does not explicitly distinguish itself from siblings like edit_trim, so it misses the top score.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Usage is only implied: an agent can infer this tool is for trimming an edge by a time delta. It references clip_stretch's convention and explains positive/negative effects, but it never states when to choose clip_trim over edit_trim, edit_cut, edit_split, or other related tools.

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

• command_statusA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the burden, and it does convey that this is a read-only lookup of a recorded result rather than a live execution. It does not disclose what a result contains, whether commands can still be running, or what error/status values are possible.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences plus an Args list, with no filler. The lookup purpose is front-loaded and the parameter provenance is stated compactly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter lookup tool with no annotations, invocation guidance is nearly complete: the source of the id is given. However, with no output schema, the description should clarify what a 'recorded result' looks like in terms of status fields or success/error information, which is currently ambiguous.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema only says command_id is a required string with title 'Command Id'; the description adds the crucial semantic that the id comes from a recent_commands entry. This provenance meaning is valuable and compensates for 0% schema description coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb ('look up') and resource ('recorded result of a previously executed command'), and scopes the operation to a command id. This clearly distinguishes command_status from siblings like recent_commands, which lists commands, and check_pipeline_status, which checks a different pipeline.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly tells the agent where to obtain the required command_id ('as returned in a recent_commands entry'), implying the correct call sequence. It does not enumerate when not to use the tool, but for a simple status lookup the context is clear.

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

• edit_joinA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It discloses that the operation depends on the current selection and that the result is one joined clip. It does not mention whether joining destroys the original clips, whether it is reversible, or how it handles cross-track or gap scenarios, leaving notable behavioral ambiguity.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences with zero filler. The key action is front-loaded, and the prerequisite is stated immediately after. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter editing command, the description covers the expected outcome and the required preconditions well. There is no output schema and no annotations, so it could be more thorough about destructive side effects or undo behavior, but the core invocation context is present.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema is empty, so the description is the only source of guidance about what the tool consumes. It usefully explains that the real inputs are the current selection: clips, tracks, and a time range. This meaningfully exceeds the bare schema and clarifies how the agent should prepare state.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Join'), resource ('selected clips'), and result ('into one clip'), making the core purpose clear. It does not explicitly name sibling tools like edit_disjoin or label_join_regions, so differentiation is implicit rather than explicit.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives a concrete precondition: 'Select tracks and a time range first.' This tells an agent what state must exist before invoking the tool. However, it does not state when to prefer this tool over alternatives such as edit_split or edit_disjoin, so the guidance is useful but not fully complete.

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

• effect_amplifyA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the linear scaling behavior, gives a default of 1.0, and importantly discloses that the default behavior limits the result unless allow_clipping is set to true. This is meaningful behavioral context, though it does not mention whether the effect is destructive or how limiting is implemented.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-line purpose followed by a tight Args block. Every sentence adds value, and the examples are efficient. There is no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter effect tool with no output schema, the description covers the essentials: target audio, parameter semantics, ranges, defaults, and the clipping-versus-limiting behavior. It is slightly thin on side effects like destructiveness or undo behavior, but nothing critical is missing for an agent to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  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, and it does. The ratio parameter gets examples, decibel equivalents, a range, and a default. The allow_clipping parameter gets its behavioral consequence and default. Both parameters are fully enriched beyond the bare schema definitions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action and resource: 'Amplify (or attenuate) the selected audio by a linear ratio.' This is clear and distinct enough from the general idea of effects. However, it does not explicitly differentiate itself from sibling tools like normalize or limiter, so it stops short of a 5.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use or when-not-to-use guidance is provided, and no alternatives are named. The usage is implied by the description: use it when you want simple linear gain or attenuation. But an agent must infer when to choose this over normalize, compressor, or limiter from the sibling list, which is not spelled out.

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

• effect_notch_filterA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It discloses the operation mutates the selected audio and gives parameter meaning/constraints, but it does not state whether the effect is reversible, requires a selection, or processes the whole track if no selection exists. Adequate for a simple effect but with gaps.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The purpose is front-loaded in a single sentence, followed by a compact two-line Args section. Every sentence adds information: what it does, example use, and parameter constraints/defaults. No filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter effect with no output schema, the description covers the operation, the scope ('selected audio'), example usage, and full parameter semantics. It would be more complete if it mentioned reversibility or behavior when no selection exists, but these are minor given the simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, yet the description fully documents both parameters: frequency_hz has units, a constraint (>0), and default; q has units, range (0.1-1000), default, and qualitative meaning ('narrowness'). The description compensates completely for the missing schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb ('Apply'), a precise resource ('notch filter'), and the desired outcome ('remove a narrow frequency band'), with a concrete example (mains hum). This clearly distinguishes it from sibling effects like normalize or click_removal without requiring the schema.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The 'e.g. mains hum' example implies the appropriate use case (removing a narrow unwanted band), but the description never explicitly says when to prefer this tool over alternatives such as click_removal or noise_reduction, nor does it give exclusions. Usage guidance is implied, not explicit.

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

• generate_toneA
  4.1/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It discloses the core behavior (fills the selected time range) and parameter defaults, but doesn't state whether existing audio is overwritten, which track gets the tone, or whether the operation is undoable. This is a moderate gap for a tool that modifies project content.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence behavior statement with a prerequisite, followed by a cleanly formatted Args list. Every line adds information and there is no redundant text.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 3-parameter generator with no output schema, the description covers the essential invocation context: selected-range dependency and parameter constraints. It could mention required track selection or the effect on existing audio, but the core usage is clear enough for an agent to call it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the Args block is the only source of parameter meaning. The description fully compensates by listing valid waveform values, frequency minimum, amplitude range, and defaults for all three parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states 'Generate a tone' with a clear verb and resource, and adds scoping detail by saying it fills the currently selected time range. It doesn't explicitly contrast with sibling generators like generate_chirp or generate_noise, but the waveform/frequency/amplitude parameters make the intent sufficiently distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly instructs the agent to call select_region first to control duration, giving a concrete prerequisite and usage context. It doesn't mention alternatives or when-not-to-use, but for a simple generator this is clear enough guidance.

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

• label_export_chaptersA
  4.1/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral disclosure burden. It goes beyond the schema by explaining the three formats, the timestamp/title layout for simple format, and the automatic fallback naming for labels without text. It does not cover error behavior or whether the operation is read-only, but it is substantially transparent for an export utility.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and front-loaded: purpose first, then formats and behavior, then parameter documentation. Each sentence adds value and the length is appropriate for a tool with three parameters and multiple format options.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool of this complexity, the description covers the core invocation details: output path, formats, defaults, and overwrite semantics. It does not mention return values or failure modes, but since there is no output schema and the operation is a straightforward file export, the missing details are minor.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  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, and it does. It explains that path is an absolute output path, format enumerates the three valid values with a default, and overwrite explicitly describes replacement behavior. All three parameters receive meaningful semantics beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific verb and resource: export labels as a chapter/marker file. It distinguishes the output format and purpose, though it does not explicitly contrast it with similar label export siblings like label_export or label_export_audio_segments.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives concrete use cases such as chapter navigation, track listings, and interview indexes, which implies when the tool is appropriate. However, it does not explicitly state when to prefer this tool over label_export or label_export_audio_segments, nor does it mention exclusions.

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

• label_regular_intervalsA
  4.1/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the behavioral transparency burden. It discloses the naming convention ('N' suffix, 1-based), the default prefix, and the fact that duration must be supplied because no C++ primitive exists. It does not state whether a label track is auto-created, whether existing labels are preserved, or where the interval sequence starts.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with a clear purpose, followed by a brief rationale for the duration parameter and a compact Args section. The C++ primitive explanation is slightly wordy but earns its place by explaining an important design constraint. Overall it is efficient and well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers required parameters, constraints, defaults, and naming behavior, and no output schema is expected for an add operation. However, it omits where the interval sequence begins (project start? selection start?) and whether the tool creates a label track if none exists. These are material gaps for correct invocation in an unspecified project context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must fully document the parameters. It does: interval is spacing in seconds (>0), duration is total coverage in seconds (>0), and text_prefix is the prefix with a 1-based numeric suffix and a default of 'Marker'. This is complete and adds meaning beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Add labels at regular intervals across a known duration.' This clearly distinguishes the tool from siblings like label_add_at, label_add_batch, and label_import, since it focuses on evenly spaced labels over an explicit duration.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when to use this tool: when a known duration is available or can be measured via project_export_audio or an analysis tool. It explicitly warns that the tool will not guess the duration. However, it does not name alternative tools or explicit conditions for preferring a different labeling tool.

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

• project_openA
  4.1/5.0
  Behavior4/5

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

  With no annotations, the description takes on the disclosure burden. It surfaces a genuinely important behavior: .aup3 inputs cause an interactive conversion prompt that is unsafe to trigger over MCP. It doesn't detail what happens to the current project on open, but the main safety-relevant trait is disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tight and front-loaded: the core action and format appear first, followed by a necessary safety warning, then one-line argument documentation. No filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter open tool, the description covers the essential invocation detail (absolute .aup4 path) and the major edge case (.aup3 conversion prompt). It does not describe return values or whether the current project is replaced, but that is less critical for making the call.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description compensates by specifying that 'path' must be an absolute path to a .aup4 file. It also implies the file must exist ('existing'), adding meaning beyond the bare string schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly specifies the action ('Open'), the resource ('existing Audacity project file'), and the supported format ('.aup4'), which is unambiguous. It does not explicitly name a sibling alternative, but the format and 'existing' wording set it apart from project_new and project_import_audio.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides a concrete when-not: .aup3 files must not be used because they trigger an interactive conversion prompt unsafe for MCP. It does not explicitly route to an alternative tool, so it stops short of a full usage-guide comparison.

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

• track_resampleA
  4.1/5.0
  Behavior2/5

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

  With no annotations provided, the description carries the full burden of disclosing behavior. It states the operation but does not say whether resampling is destructive, whether undo is available, whether all selected tracks are modified permanently, or what happens if no tracks are selected. This is a noticeable transparency gap for a mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is short, front-loaded with the operation, and includes the prerequisite and parameter details in a clean Args block. Every sentence provides necessary information without padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with no output schema and no annotations, the description covers the operation, the required selection precondition, and the parameter semantics. It is slightly incomplete only in not addressing the operation's side effects or failure cases, but it is otherwise sufficient for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description fully documents the only parameter: rate is the target sample rate in Hz, with examples and an explicit valid range (1-384000). This adds essential meaning beyond the schema's bare integer type and title.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Resample'), a clear resource ('the selected track(s)'), and the target result ('to a new sample rate'). It also names the required precondition via select_tracks, which disambiguates it from track/clip editing siblings that operate on other properties.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells the agent to select tracks first with select_tracks before calling this tool. It provides clear context for when to use it, though it does not mention alternative tools or when not to use it.

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

• track_set_propertiesA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It correctly discloses that the operation mutates a track and that unmentioned properties remain unchanged. It does not address error behavior, return value, or side effects, but the core mutating behavior is clearly stated.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: a two-sentence overview states the operation and its partial-update behavior, followed by a clean Args list. Each line adds essential meaning without repetition or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple setter with one required parameter and no nested objects, the description covers invocation details well: allowed values, units, and partial-update semantics. Minor omissions like behavior for an invalid track index or the return response are not critical for calling the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the Args block fully compensates: it translates track as 0-based, gives gain a range in dB, defines pan as left-to-right with -1.0 to 1.0, and explains name, mute, and solo. This is exactly the semantic information missing from the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb ('Set'), resource ('properties of a track'), and selection criterion ('by index'), which clearly distinguishes it from single-purpose track tools like track_mute or track_set_color. The scope is precise and actionable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The partial-update instruction ('Only the properties you pass are changed - omit any you don't want to touch') is valuable usage guidance. However, there is no explicit comparison to sibling tools such as track_mute, track_ute_all, or track_set_color, so the agent must infer when to choose this general setter instead.

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

• auto_analyze_audioA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of disclosing behavior. It reveals that the tool selects all audio, exports it to a temp WAV, measures it, and returns diagnostics plus a recommendation. This is substantive behavioral context, though it does not clarify whether the selection persists or whether the temp file is cleaned up.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded. The first sentence states the core purpose, and the second lists the concrete steps and outputs. Every sentence contributes essential information without repetition or fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema, the description covers the action, scope, workflow, and return content well. It could additionally state whether the operation is non-destructive or whether any state changes persist, but overall it provides enough context for an agent to decide to invoke it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so no parameter documentation is needed. The description accurately reflects that the operation is automatic and project-wide. Baseline for zero parameters is 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('analyze') with a clear resource ('the current project's audio') and uniquely describes its goal of recommending a cleanup pipeline. It lists exact diagnostics returned (peak/noise/clipping/click/silence-gap/dynamic-range), which clearly distinguishes it from sibling analysis and cleanup tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies use when you need a pre-cleanup analysis and a recommendation for which pipeline to run next. However, it does not explicitly state when not to use this tool or name alternatives such as auto_cleanup_audio, analyze_beat_finder, or analyze_sample_data_export. The routing guidance is implicit rather than explicit.

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

• clip_reset_pitch_speedA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full behavioral disclosure burden. It does state that both pitch and speed changes are reverted in a single call, which is the core behavior, but it does not elaborate on whether this resets to default values, whether it is reversible, or any side effects. Adequate but minimal.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is extremely compact: one functional sentence plus a single parameter explanation. Every part earns its place, with no redundant phrasing or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple single-parameter tool, the description covers what the tool does and how to specify the target clip. It lacks details like error conditions or explicit confirmation of reset-to-default behavior, but the complexity is low enough that the description is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only defines 'key' as a string, but the description adds the important format detail: 'trackId:itemId'. Since schema description coverage is 0%, this compensation is valuable and gives the agent enough information to construct the parameter correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action — 'Revert both pitch and speed changes on a clip in one call' — and clearly distinguishes this from siblings like clip_reset_pitch and clip_reset_speed by emphasizing the combined operation. The verb and resource are unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'both pitch and speed changes... in one call' makes the use case clear: choose this when you need to reset both properties together instead of calling the individual reset tools. It doesn't explicitly name alternatives or exclusions, but the context is apparent.

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

• cursor_setA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description must carry the behavioral burden. It transparently discloses the state change (moving both the playback cursor and edit point) and the time unit, which is the core behavior. It does not, however, mention side effects, bounds/clamping, or return behavior; acceptable for a simple navigation command but not rich.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences plus a minimal Args line. It front-loads the action and resource, then gives the only necessary parameter detail. No filler or redundant restatement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter positional navigation tool with no output schema and no annotations, the description supplies the core action and parameter semantics. It omits any indication of return value, failure behavior for invalid times, or relationship to the existing cursor_to_* siblings, leaving minor but real gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only exposes 'time' as a bare number, while the description adds the essential meaning: 'Position in seconds'. This resolves the likely ambiguity between samples, frames, and seconds and fully documents the single parameter.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a concrete verb ('Move'), names the target resource ('playback cursor / edit point'), and clearly specifies the destination ('specific time'). This distinguishes it from sibling cursor_to_* tools that target preset positions such as project start/end or track boundaries.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The phrase 'specific time' communicates the intended use case: arbitrary-position cursor movement rather than a named boundary. It does not explicitly name alternatives or exclusions, but the context is clear enough for an agent choosing between this and cursor_to_project_start or cursor_to_track_start.

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

• edit_pasteA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It discloses the core action (paste from clipboard) and the stateful dependency on the current selection. However, it doesn't mention side effects such as whether pasting inserts or overwrites existing audio, what happens if the clipboard is empty, or whether the operation is undoable. These gaps keep it below a 4.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no wasted words. The primary action is stated first, followed by the key prerequisite. The structure is ideal for quick agent comprehension.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-output-schema tool, the description covers the essential information: what the tool does and the required precondition. Minor details like error handling for empty clipboard or missing selection are not specified, but the instruction to select first mitigates that risk. Overall it is adequately complete for this simple operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero properties, so the baseline is 4. The description adds meaningful implicit-parameter semantics by explaining that the destination is the start of the current selection, set via select_region or cursor_set. This clarifies stateful behavior beyond the empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Paste audio from clipboard at the start of the current selection.' This clearly distinguishes it from sibling edit tools like edit_cut or edit_copy, which perform different operations. No ambiguity about what the tool does.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides an explicit prerequisite: 'Select the destination position first with select_region (or cursor_set).' This tells the agent what to do before invoking the tool. It doesn't explicitly discuss alternatives, but among the siblings there is no other paste tool, so no exclusion is necessary.

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

• effect_crossfade_clipsA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the behavioral burden. It discloses the precondition and what operation is performed, but it does not mention whether crossfading is destructive, whether it can be undone, or what happens if the selection does not contain two overlapping clips. This is an adequate but incomplete behavioral disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences front-load the action, then give the essential prerequisite, then confirm the empty parameter list. Every sentence is necessary and there is no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-output-schema tool, the description is largely complete: it names the operation, the target, and the required selection. It lacks only edge-case or reversibility details, which would strengthen completeness for a mutating audio effect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema coverage is 100%, so there is no parameter semantics to document. The description redundantly confirms 'Takes no parameters,' which aligns with the baseline for a parameterless tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Crossfade'), the exact object ('the overlap between two adjacent, overlapping clips'), and the required precondition ('Select the overlapping region across both clips first'). This clearly distinguishes it from sibling tools like effect_crossfade_tracks by targeting clips rather than tracks.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit prerequisite: the overlapping region must be selected before invoking the tool. It does not explicitly name alternatives or state when not to use it, but for a zero-parameter effect the selection guidance is sufficient context for correct use.

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

• effect_paulstretchA
  4.2/5.0
  Behavior3/5

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

  Annotations are absent, so the description must carry behavioral disclosure. It honestly communicates the performance tradeoff (smaller time_resolution = slower) and the selection precondition, and describes the resulting texture. However, it does not state whether the effect destructively modifies the selected audio, whether it is reversible, or what the command returns.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the purpose, then a one-line prerequisite, then a focused Args block. Every sentence adds useful information; no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an unannotated mutation-style effect with no output schema, the description covers purpose, prerequisite, and both parameters well. Clear gaps remain around whether the operation is destructive/undoable and what the resulting audio behavior or return status is, so it is only minimally complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The description adds full semantic meaning beyond the bare schema: stretch_factor is explained with concrete reference points (1.0 = no change, 10.0 = 10x longer) and time_resolution is given a quality/performance tradeoff plus a lower bound (>=0.00099). With 0% schema description coverage, this fully compensates.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description identifies a specific operation ('Extreme time-stretch effect') and its sonic purpose ('creates ambient/drone textures'), which distinguishes it from sibling stretch tools like effect_sliding_stretch. The 'Select audio first' prerequisite further clarifies what it operates on.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly instructs 'Select audio first,' giving a clear precondition. The 'extreme time-stretch / ambient/drone' framing implies when it is appropriate, but it does not name alternatives or state when not to use it relative to effect_sliding_stretch or clip_stretch.

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

• effect_repairA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full behavioral burden. It usefully discloses that the effect will refuse to run on longer regions, which is a real behavioral trait. However, it does not mention whether the operation is destructive, whether it can be undone, or what happens after successful repair.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two brief sentences, no filler, and the most actionable constraint is front-loaded. Every sentence adds necessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-parameter effect tool with no output schema, the description covers the essential prerequisite and the key limitation. It could be slightly more complete by noting side effects or success/error behavior, but it is adequate for an agent to attempt the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4. The description adds important operational meaning by explaining that the affected region is determined by the current selection rather than by parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('repair') and resource ('a very short damaged section of audio') and adds the crucial constraint that the region is at most a few dozen samples. This clearly distinguishes it from broader audio effects and other editing tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives concrete usage context: the user must select the damaged region first, and the region must be extremely short or the effect will refuse to run. It does not explicitly name an alternative for longer regions, but it provides enough guidance for correct invocation.

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

• get_noise_profileA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden here. It does disclose the underlying mechanism — 'Sets NoiseReductionEffect's GetProfile flag and runs it' — and relates it to Audacity's dialog button. However, it never explicitly states whether the audio is modified, whether a previous profile is overwritten, or what the tool returns after the call.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well structured: purpose first, then the critical precondition, then implementation context. Each sentence earns its place, and the warning is clearly separated and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, stateful capture tool, the description provides the needed invocation context: selection requirement, relationship to noise_reduction, and the underlying Audacity behavior. It could go further on return values and exact side effects, but it is broadly complete for selecting and calling the tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero formal parameters, so the schema is already complete; the baseline is 4. The description adds useful implicit-parameter guidance by telling the agent to ensure the current selection is pure noise of about 0.5-2 seconds before invoking the tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Capture a noise profile from the currently selected audio region.' It also states that this profile is used by the noise_reduction tool, which clearly separates it from the many effect and analysis siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives an explicit precondition: 'Select a region of pure noise (e.g. 0.5-2 seconds of silence/background noise) before calling this.' It also explains the profile feeds the noise_reduction tool. It does not discuss when not to call it or name alternatives, but the context is clear enough for correct use.

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

• label_delete_regionsA
  4.2/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full disclosure burden and does it well. It explicitly states the operation is destructive ('Delete the audio'), explains that gaps are closed, discloses the last-to-first processing strategy, and warns that the timeline shifts and label data should be re-read afterward.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: the main action is stated first, followed by the essential processing-order detail and a practical verification step. Every sentence adds value, and there is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema and no annotations, the description is complete. It tells the agent what will happen, how the operation is executed, and what to do after invocation ('Re-read label_list afterwards'), leaving no critical ambiguity about the tool's effect or side effects.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and 100% schema description coverage, so there are no parameter semantics to clarify. The baseline of 4 applies because the description adds no unnecessary detail and the absence of parameters is fully reflected in the schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose4/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a clear action and resource: deleting audio under every label and closing the resulting gaps. It is specific enough to be understood, but it does not explicitly differentiate itself from similar label/region tools like label_cut_regions or label_delete_audio_at.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied: delete all audio regions marked by labels and close the gaps. However, it does not state when to choose this tool over alternatives such as label_cut_regions or edit_delete, nor does it mention any prerequisites or exclusions.

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

• label_silence_regionsA
  4.2/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and does disclose the key behavioral traits: audio is replaced with silence, the timeline length is unchanged, and labels remain in place. It lacks explicit mention of irreversibility or undo behavior, but the destructive nature is clearly conveyed without contradicting any structured metadata.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two short sentences with the main action front-loaded. Every sentence adds useful behavioral information: 'Replace the audio under every label with silence' states the action, and the second sentence clarifies order-independence and timeline preservation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter command with no output schema, the description covers the core behavior well: what changes, what does not change, and why order does not matter. Minor ambiguity remains about whether 'every label' means all labels across all tracks, but this is a small gap for such a simple tool.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema description coverage is 100%, so there are no parameter semantics to clarify. Per baseline for zero-parameter tools, this dimension receives a 4.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Replace the audio under every label with silence.' It also distinguishes itself from cut/delete operations by noting the timeline length is preserved and labels stay put, which differentiates it from siblings like label_cut_regions and label_delete_audio_at.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes the tool's behavior clear but does not explicitly say when to use it versus alternatives such as label_cut_regions, label_delete_audio_at, or edit_silence. Usage guidance is implied through the non-shifting, label-preserving behavior, but no alternative is named or excluded.

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

• nearest_zero_crossingA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden and does disclose an important behavioral trait: the search is independent of the current selection. However, it does not mention return format, boundary behavior (e.g., whether it can return before or after the given time), or any assumptions about the audio/track context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences plus a one-line Args note carry all the essential information with no filler. The key purpose and scoping fact (independent of selection) are front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter utility tool this is nearly complete: purpose, usage context, alternative, and parameter semantics are covered. The main gap is the lack of an explicit return-value description, since there is no output schema, but the phrase 'zero-crossing time' makes the result reasonably inferable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, and the description compensates by explaining that 'time' is in seconds and that the search happens 'near' that time. This adds real meaning beyond the schema's bare number type, though it could specify valid range or format constraints.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb-resource pair ('Find the nearest zero-crossing time') and names its intended use ('precise, click-free edit points'). It also differentiates from the sibling select_zero_crossing by noting independence from the current selection, so the agent can distinguish it without inspecting other schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It states when this tool is appropriate: when a precise, click-free edit point is needed and when selection independence matters. It names select_zero_crossing as the contrasting alternative, but it stops short of explicitly saying 'use select_zero_crossing when selection-dependent behavior is desired,' leaving a small inference.

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

• select_regionA
  4.2/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It usefully discloses that the operation only applies to currently selected tracks and depends on prior selection state. However, it does not state whether this replaces an existing region selection, what happens when no tracks are selected, or whether any track-specific side effects occur.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the core purpose, and includes only necessary prerequisite and parameter clarification. Every sentence contributes value, and the Args section is clean and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter selection tool with no output schema or annotations, the description covers the essential behavior, prerequisites, and parameter meaning. Minor omissions like exact selection replacement behavior and no-tracks-selected behavior keep it from being fully complete, but nothing critical is missing for a basic call.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only defines start and end as numbers, with 0% schema description coverage. The description adds real meaning by explaining 'start: Start time in seconds' and 'end: End time in seconds,' including units that the schema omits. It could add constraints like end after start, but the core semantics are adequately covered.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Select a time region,' a specific verb plus resource, and immediately clarifies that it operates on currently selected tracks, which distinguishes it from sibling selection tools like select_tracks or select_clip. The scope is clearly a time-based selection across tracks rather than a track or clip selection.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly tells the agent to call select_tracks or select_all first if needed, which is clear prerequisite guidance. It does not explicitly name alternatives or exclusion conditions, but the dependency and intended invocation context are evident.

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

• split_range_at_silencesA
  4.2/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden, and it does disclose the core operation and scope. However, it does not explain the effect on existing clips, whether the operation is destructive or undoable, what silence detection criteria are used, or what happens if no clips are selected.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the primary action, followed by the key prerequisite and parameter definitions. Every sentence adds necessary information without repetition or filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter tool with no output schema, the description covers the action, scope, selection prerequisite, and parameter semantics. The main gap is the lack of detail about silence detection behavior and potential side effects, but the agent has enough to invoke the tool correctly in most cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  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 does so by defining start and end as times in seconds and noting that end must be >= start. This provides meaningful guidance beyond the bare schema fields, though it could clarify range inclusivity and units relative to the project timeline.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action: automatically split every clip on selected tracks within a time range at detected silence boundaries. This clearly differentiates it from siblings like clip_split_at_silences, which likely targets individual clips rather than selected tracks and a range.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly instructs the agent to select tracks first via select_tracks, which is a concrete and necessary precondition. It does not discuss when to prefer this tool over alternatives such as clip_split_at_silences or truncate_silence, so it stops short of a 5.

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

• transport_play_stopA
  4.2/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full disclosure burden. It does transparently state the state-dependent behavior and the basic side effect of toggling playback. But it leaves unspecified how the tool behaves if the transport is paused or recording, and it does not mention any failure conditions. That is a moderate gap for a no-annotation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single efficient sentence with a helpful parenthetical. It front-loads the action and avoids any filler, repetition, or irrelevant details.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-output-schema transport control, the description covers the essential calling context. The only notable omission is the paused/recording edge case, which could matter in a transport tool, but the overall complexity is low enough that this is not a major completeness failure.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema already reflects that with empty properties. Per the baseline rule for zero-parameter tools, the description does not need to add parameter-level detail, and the core semantics are clear from the description itself.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Toggle') and names the resource ('playback of the current project'), with an explicit conditional ('play if stopped, stop if playing'). This clearly separates it from sibling tools like transport_play, transport_stop, and transport_pause by describing a combined state-switching action.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description conveys that the tool is for flipping the current playback state regardless of what it is. However, it does not explicitly name the deterministic alternatives (transport_play, transport_stop) or state when not to use the toggle, so an agent wanting to force a specific state might not immediately know to prefer those siblings.

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

• analyze_label_soundsA
  4.3/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the burden of disclosing side effects, and it does so explicitly: it adds labels to the project's label track and creates the track if needed. It also reveals that the operation mutates project state and points to label_list for reading results, but it does not mention whether existing labels are preserved or if there are any destructive consequences.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and efficient: a clear two-sentence purpose summary, a high-level side-effect note, and a compact argument list. Every part adds information, with no filler or redundant restatement.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  All five parameters are covered with defaults and semantics, and the description tells the agent how to retrieve the results afterward via label_list. It is slightly incomplete only in not addressing edge cases like what happens when no sounds/silences are found or how existing labels are affected.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description fully compensates by explaining every parameter: threshold_db includes range and default, measurement lists allowed values, min_silence_duration and min_label_interval include units, and label_type explains each option's meaning. This adds substantial meaning beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action: detect sounds separated by silence and add a label for each one, with label_type determining whether sounds or silences are labeled. It clearly distinguishes itself from generic label tools by focusing on silence-separated sound detection.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description indicates a clear use case and even tells the agent to call label_list afterward to read the detected regions. However, it does not explicitly mention when to prefer this tool over siblings like analyze_beat_finder, label_regular_intervals, or transcribe_to_labels, nor does it state when not to use it.

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

• auto_audiobook_masteringA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It provides valuable transparency: the tool runs in background, returns a job_id immediately, and requires monitoring through check_pipeline_status. It also details the exact processing pipeline, target RMS/peak values, and the important remove_noise caveat about the first 0.5s needing room tone. However, it does not specify what audio is processed (e.g., selected clips, all tracks, whole project) or whether the operation is destructive/reversible, which is a meaningful gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-structured and information-dense without padding. The all-caps headline, pipeline breakdown, target specifications, and Args section each add necessary operational detail. Every sentence contributes value, and the most critical warnings are called out prominently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a background job tool with no output schema, the description explains the asynchronous behavior, the returned job_id, and the monitoring tool to use. It also covers the main argument and the processing targets. The main missing context is the input scope — what audio the mastering applies to — which could be important for an agent deciding whether to invoke this tool on a given project.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description fully compensates for the single parameter. It explains remove_noise applies noise reduction using the first 0.5s as a noise profile, states the default is True, and highlights the important prerequisite that the first 0.5s should be room tone/silence if enabled. This is substantially more meaning than the bare boolean schema field provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'ONE-CLICK AUDIOBOOK MASTERING: ACX/Audible compliant processing.' It clearly identifies the purpose and differentiates it from sibling tools like auto_master_music or auto_cleanup_audio by specifying audiobook/ACX compliance rather than general music mastering or cleanup.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly indicates when to use this tool: for one-click audiobook mastering targeting ACX requirements. It also gives workflow guidance by noting it runs in the background and instructing the user to use check_pipeline_status to monitor. It does not explicitly list when not to use it or name alternatives, but the context is clear enough to guide selection.

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

• clip_set_colorA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses the key format and the color_index range, including the special 0 'inherit from track' behavior. It does not mention permissions or overwrite semantics, but for a simple setter the core behavioral surface is adequately transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise: a clear one-line purpose followed by a compact Args block. Every sentence adds useful information, with no filler or repetition of the schema's field names.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter setter with no output schema, the essential inputs and effect are covered. The only minor gap is the absence of explicit return/error behavior or prerequisites, but the operation is straightforward enough that this is not a serious omission.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the Args section fully documents both parameters: key format 'trackId:itemId' and color_index semantics with range 0-9 and the special 0 behavior. The description compensates completely for the missing schema parameter descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource: sets a clip's color tag for visual organization. It is clearly distinct from siblings like track_set_color and other clip_set_* operations by targeting the clip's color specifically.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use guidance or alternatives are given, but the use case is clear from the description. The distinction from track_set_color is implicit rather than stated, and no exclusions or preconditions are provided.

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

• cursor_to_project_endA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full behavioral disclosure burden. It clearly states the action and adds the meaningful semantic detail that project end means total duration, not the last edited region. For a zero-parameter cursor movement, this transparently conveys the effect and likely side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, concise sentence with no filler. It front-loads the action and includes the clarifying 'total duration' detail in a parenthetical, making the description efficient and scannable.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's extreme simplicity (zero params, no output schema, no annotations), the description provides all necessary information for an agent to invoke it correctly. The scope ('project end') is fully specified, and no further behavioral or contextual information is needed.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is no schema or description burden. The baseline of 4 for paramless tools applies; the description correctly does not attempt to document parameters that do not exist.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Move'), a specific resource ('cursor'), and a precise target ('end of the project'). The clarifying parenthetical '(its total duration)' removes ambiguity about what 'end' means, distinguishing it from track-end or selection-end concepts.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies when the tool should be used: when you need the cursor at the project's end. However, it does not explicitly mention any alternatives or exclusion conditions, such as 'use cursor_set for arbitrary positions' or 'use cursor_to_track_end for track boundaries.' This is a simple tool, so the lack of explicit routing is acceptable but still leaves the guidance implicit.

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

• cursor_to_project_startA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full behavioral burden. It clearly states the operation and exact destination (cursor moves to project start at t=0). For a zero-parameter, non-destructive cursor positioning tool, this is adequate transparency, though it does not mention any potential side effects like selection or playback state.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single sentence that is direct and front-loaded with the essential information. Every word contributes meaning, and the 't=0' clarification adds precision without bloat.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless, simple cursor movement tool with no output schema, the description contains all necessary operational information. The destination is unambiguous, and the sibling list provides enough surrounding context to disambiguate from other cursor-related tools.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and schema coverage is 100%, so there is nothing for the description to explain. The baseline for a no-parameter tool is 4, and the description appropriately adds no unnecessary parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Describes a specific action ('Move the cursor') with a clear resource and destination ('very start of the project (t=0)'). It is immediately distinguishable from siblings like cursor_to_project_end, cursor_to_track_start, and cursor_to_track_end.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The intended use is implied by the action itself, but there is no explicit when-to-use guidance or comparison with alternatives such as cursor_set, cursor_to_track_start, or cursor_to_project_end. Context for choosing this tool comes mainly from the tool name and sibling list rather than the description.

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

• edit_duplicateA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description itself must communicate behavior. It does say it creates a new track, implying a non-destructive copy. However, it does not clarify whether each selected track gets its own new track or all selected audio merges into one new track, nor whether effects, volume, or other properties are copied.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences: the first states the operation, the second states the prerequisite. Every word adds necessary information and the tool name is not repeated.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema and no annotations, this description is sufficient. An agent knows what action to perform, what must be selected beforehand, and what the expected result will be.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  There are zero parameters, so there is nothing for the description to document beyond the general instruction to select tracks and a range first. This matches the baseline for parameterless tools.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action, 'Duplicate the selected audio into a new track,' with a clear resource. This differentiates it from siblings like track_duplicate, which would duplicate a track rather than a selection.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives an explicit prerequisite: 'Select tracks and a time range first.' This tells the agent what state must be set up before invoking the tool, though it does not name alternative tools or conditions when not to use it.

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

• edit_split_cutA
  4.3/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral disclosure burden. It clearly explains the key side effect: audio is cut to clipboard and replaced by silence, not by closing the gap. This discloses the most important behavioral trait beyond the tool name.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences only, with the key distinguishing behavior front-loaded in the first sentence and the invocation prerequisite in the second. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter editing command with no output schema, the description is complete: it states what the tool does, the critical behavioral nuance, and how to prepare the selection. Nothing essential is missing for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema is empty, so the baseline is 4. The description adds context by explaining that the operation depends on the user's pre-selected tracks and time range, which is the only meaningful input semantic for this tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Cut the selected audio to clipboard'. It clearly differentiates this tool from siblings like edit_cut by emphasizing 'WITHOUT closing the gap - leaves silence where the audio was.' This is precise and informative.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a necessary precondition: 'Select tracks and a time range first.' It implies when to use this tool via the distinction from cut-that-closes-gap, but it does not explicitly name alternatives or state when not to use it. The usage guidance is present but mostly implicit.

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

• effect_fade_inA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavioral disclosure. It communicates that the tool mutates audio by applying a fade-in and requires a selection, but it does not mention reversibility, whether the original audio is replaced, or any default fade behavior. These gaps are modest for a well-known effect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, each earning its place: one states the operation, the other states the required precondition. No redundant wording or unnecessary detail.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a parameterless audio effect with no output schema, this is complete. It explains what happens, what scope is affected, and what must be done first. There is no missing information an agent needs to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool takes zero parameters, so the description does not need to document anything beyond the operation itself. The baseline of 4 applies here since there are no parameters whose meaning could be clarified.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Apply a fade-in') and resource ('selected audio'), making the tool's purpose unmistakable. It also distinguishes this from related effect tools by naming the exact operation rather than a generic 'apply effect' phrase.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear operational context: the user must select the audio region before invoking the tool. It does not explicitly name alternatives like effect_fade_out or effect_adjustable_fade, but the prerequisite is enough to tell the agent when this tool is appropriate.

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

• effect_studio_fade_outA
  4.3/5.0
  Behavior3/5

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

  There are no annotations, so the description carries the full behavioral disclosure burden. It clearly says the tool applies a fade-out to the selected audio and takes no parameters, but it does not mention whether the change is destructive, whether a selection is strictly required, or how the output is represented. This is adequate for a simple effect tool but leaves some behavioral traits implicit.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no wasted words. It front-loads the action and target, includes the key comparison to a sibling, and states the parameter behavior cleanly.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter effect with no output schema, the description covers the essential information: what the tool does, what it acts on, how it differs from the closest sibling, and the fact that no parameters are needed. Nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has zero parameters, and the description reinforces this by explicitly stating 'Takes no parameters.' Since there are no parameters to document, the description adds appropriate clarity beyond the empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Apply'), a clear resource ('a fade-out to the selected audio'), and explicitly distinguishes itself from the sibling effect_fade_out ('smoother, more natural'). It also notes it takes no parameters, which makes the purpose unmistakable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description directly names effect_fade_out as the alternative and explains why to prefer this tool: it is smoother and more natural. It does not mention other fade-related siblings or provide explicit 'when not to use' guidance, but the context is clear enough for an agent to select it appropriately.

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

• generate_chirpA
  4.3/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It does explain the core behavior (fills selected range, duration controlled by select_region) and parameter constraints, but it does not state whether existing audio in the selected range is overwritten or what the tool returns on success. This is a notable gap for a generation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose, then states the critical prerequisite, then lists parameter semantics in a clean, scannable Args block. Every sentence earns its place without padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 5-parameter tool with no annotations and no output schema, the description is largely complete: it defines the action, the required selection context, all parameter meanings, and defaults. The main missing piece is explicit disclosure of side effects on existing audio, such as whether the chirp replaces the selection or is layered into it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must fully compensate. It does: every parameter is explained with allowed values, ranges, and defaults, e.g., waveform options, frequency >= 1 Hz, amplitude 0-1, and all defaults. This is exactly the semantic detail the schema lacks.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description immediately states a specific verb and resource: 'Generate a chirp (frequency sweep).' It adds the key scoping behavior 'Fills the currently selected time range,' which clearly distinguishes it from sibling tools like generate_tone, generate_noise, and generate_dtmf.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear usage context by stating that the tool fills the currently selected time range and explicitly instructs the agent to 'call select_region first to control duration.' It does not explicitly name alternatives or exclusions, but the prerequisite is precise and actionable.

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

• generate_dtmfA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden. It explains that the tool fills the selected time range, which is useful behavioral context, but it does not disclose whether existing audio in the selection is overwritten, whether the operation is undoable, or what happens if no selection exists.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the primary action and selection requirement come first, followed by a concise parameter list. There is no filler or repetition of schema information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool with three fully documented parameters and no output schema, the description covers the essential call semantics, including the selection prerequisite. It is slightly incomplete in not specifying valid DTMF characters in 'sequence' or clarifying whether generation replaces existing audio.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema provides only defaults and types, with no descriptions. The description fully compensates by explaining each parameter's meaning, valid range, and default: sequence text, duty cycle as tone/silence ratio, and amplitude as a 0-1 value.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: 'Generate DTMF (telephone) tones' and adds the key scoping detail that it fills the currently selected time range. This clearly distinguishes it from sibling generation tools like generate_tone, generate_chirp, generate_noise, and generate_silence.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit prerequisite: 'call select_region first to control duration.' This tells the agent when and how to use the tool acceptably, though it doesn't explicitly mention alternatives or when not to use it.

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

• generate_silenceA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys the core behavior—filling the selected time range with silence—and the dependency on a prior selection. However, it does not state whether existing audio in the range is overwritten, whether the operation is reversible, or any destructive side effects. That gap matters for an audio-editing mutation tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, each earning its place: the first states the action, the second gives the essential usage prerequisite. No filler or repetition, and the most important information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema, the description is nearly complete: it names the behavior, the target scope, the prerequisite action, and confirms no parameters are needed. The only minor gap is the lack of an explicit warning that the selected audio will be replaced with silence, which is somewhat implied by 'fills'.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema is empty, so schema coverage is effectively 100%. The description explicitly says 'Takes no parameters' and clarifies that duration is controlled through select_region instead. This adds useful semantic guidance beyond the empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb and resource: generate silence, and explains that it fills the currently selected time range. This clearly distinguishes it from siblings like generate_tone, generate_noise, and edit_silence, so an agent knows exactly what the tool does and what output to expect.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit prerequisite: call select_region first to control duration. This is clear, actionable usage guidance. It does not explicitly contrast with alternatives, but for a zero-parameter generation tool the selection-based workflow is the main decision the agent needs to make.

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

• list_realtime_effectsA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It clearly indicates a read-only listing operation and enumerates the returned fields, which is useful. However, it does not specify ordering, inclusion of inactive effects, empty-chain behavior, or error handling for invalid track IDs.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the core purpose, and every sentence earns its place. The Args section is clear and avoids repetition of schema details beyond the essential semantics.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter list tool with no output schema, the description adequately states the input contract and the high-level return shape. Minor gaps like exact response formatting or behavior on empty chains do not prevent correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only declares track_id as an integer, and schema description coverage is 0%. The description fully compensates by explaining that track_id comes from project_get_info's track list and that -2 targets the Master bus. This is exactly the semantic detail an agent needs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific resource ('realtime effect chain on a track or the Master bus') with a clear action, and explicitly lists the output fields (index, name, active state). It differentiates itself from siblings by scoping to realtime effects and referencing remove_realtime_effect/set_realtime_effect_active, making its role unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear usage context: it returns indices specifically intended for remove_realtime_effect/set_realtime_effect_active, and explains the special -2 sentinel for the Master bus. It does not explicitly contrast with list_effects or other listing tools, but the realtime-effect scope makes the intended use clear.

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

• project_import_audioA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It does reveal the state requirement (open project) and acceptable audio formats, which is useful. However, it does not mention whether the operation is undoable, whether the audio file is copied or referenced, or what happens with an invalid path.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose, followed by the essential prerequisite and parameter detail. Every sentence earns its place, and there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter import tool with no output schema, the description covers the essential aspects: what it does, when it can be called, and what the path parameter requires. A small gap is that it does not indicate whether the command returns status information or whether the import is asynchronous, but the provided context is sufficient for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only names the parameter 'path' with no description, so the description fully compensates by explaining it must be an absolute path and listing supported formats (wav, mp3, ogg, flac, etc.). This is precisely the semantic detail an agent needs.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the action: 'Import an audio file into the current project as a new track.' This gives a specific verb, resource, and result, and it is distinguishable from sibling tools like project_export_audio or transcribe_to_file.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly states the critical prerequisite: a project must already be open, and it names the tools to use first (project_new or project_open). It provides clear context for when this tool is appropriate, though it does not discuss exclusions or alternative import paths.

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

• project_save_asA
  4.3/5.0
  Behavior3/5

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

  With no annotations, the description carries the full burden. It does disclose overwrite refusal by default and warns against auto-saveing. However, it doesn't clarify save-as semanics such as whether the current project becomes associated with the new file, or describe error/return behavior when the path exists and overwrite is false.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three short, information-dense sentences front-load the core operation and guardrail, then give exactly the two parameter meanings needed. No wasted words.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parametr tool, this is nearly complete: it covers file type, path form, overwrite behavior, and when not to call. No output schema exists, so a sentence about expected orror/success feedback would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the parameter docs in the description are esential. It exptains that path must be an absolute path, and clarifies overwrite means replacing an existing file and that replacement is refused by default — meaning thatn beyond the schema's bare boolean default.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Opening sentence names the exact action and resource: 'Save the current project to a new .aup4 file.' The 'new' qualifier cleanly distinguishes it from project_save, which is present in the sibling list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit when-if-appropriate guidance: 'ONLY call when the user explicitly asks - do NOT auto-save after effects or pipelines.' It lacks an explicit alternative such as project_save, so it's not a full 5.

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

• remove_realtime_effectA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description itself must convey behavior. It clearly indicates that this is a destructive removal of an effect from the realtime chain, but it does not disclose potential error cases, whether removal is undoable, or what response the caller should expect.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise, front-loads the purpose, and then provides a clear Args block. Every sentence adds value with no redundant or misleading content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter removal tool, the description covers the operation and both parameters well enough to invoke it correctly. It is slightly incomplete by not describing return values or invalid-index behavior, but those are not critical for a straightforward removal action.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, but the description fully compensates by explaining both parameters: track_id's source and the -2 Master bus special case, and index's source from list_realtime_effects. This adds meaning far beyond the bare integer schemas.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states 'Remove one effect from a track's (or the Master bus's) realtime effect chain by index,' using a specific verb and resource. It also distinguishes itself from related siblings like add_realtime_effect, list_realtime_effects, and set_realtime_effect_active.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context on how to invoke the tool: track_id comes from project_get_info's track list, -2 targets the Master bus, and index comes from list_realtime_effects. It does not explicitly state when not to use this tool or mention alternative tools, but the prerequisites are strong enough for correct use.

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

• select_allA
  4.3/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly states that selection covers all tracks and all audio data, but it does not mention side effects such as replacing the current selection or whether the operation is non-destructive. For a simple selection command this is adequate but not exceptionally transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, focused sentence with no wasted words. It front-loads the action and states the full scope of the selection without redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-output-schema command, the description is complete. It fully defines what will be selected and requires no further information for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there are no parameter semantics to document. The description also needs no parameter compensation since the schema is empty; the baseline of 4 applies.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Select') with a precise resource ('all tracks and all audio data in the project'), clearly distinguishing it from sibling selection tools like select_tracks or select_region. The scope is unambiguous and immediately understandable.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description makes clear this is the tool for selecting everything in the project, providing strong contextual cues for when to use it. It does not explicitly name alternatives or exclusions, but the all-encompassing scope makes the intended usage obvious against the sibling tools.

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

• select_noneA
  4.3/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full behavioral burden. It fully discloses both state-changing effects (deselecting tracks and clearing the time selection), with no hidden side-effect implied. Since the operation is non-destructive and simple, this is transparent enough.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single sentence that states both effects clearly with no filler. It is front-loaded and every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a no-argument, no-output command, the description fully specifies the observable behavior. An agent has everything needed to invoke it correctly without further clarification.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is nothing for the description to explain. The baseline of 4 applies because no parameter documentation is needed; the description correctly focuses on the operation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Deselect') and a precise resource ('all tracks') plus an explicit additional action ('clear the time selection'). It clearly distinguishes from siblings like select_all and select_region by stating the exact inverse operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  No explicit when-to-use statement or mention of alternatives. However, the description itself implies usage: when the agent needs to clear all current track and time selections. For a zero-parameter command with an obvious purpose, this implicit context is adequate but not elaborately guided.

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

• auto_cleanup_liveA
  4.4/5.0
  Behavior5/5

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

  Without annotations, the description carries the full burden and succeeds: it reveals the tool runs in the background and returns a job_id immediately. It also discloses the exact processing pipeline, including that noise reduction is always on, and warns about the mandatory room-tone requirement for the first 0.5 seconds.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is information-dense and well-organized, with the pipeline laid out in a readable sequence and the critical warning marked IMPORTANT. There is minor redundancy between 'noisy/field recordings' and 'live performances, field recordings, and noisy environments,' but no meaningful fluff.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness3/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  It covers async behavior, monitoring, pipeline, and the room-tone prerequisite well. The main gap is that it never states what the tool actually operates on—current selection, active clip, or whole project—which matters since the tool takes no parameters. This leaves a meaningful assumption for the agent.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema is empty, so there are no parameters to document and baseline 4 applies. The room-tone requirement is a usage precondition rather than a parameter, but the description handles it clearly even though it doesn't add parameter-specific detail.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies a specialized cleanup action for live/noisy recordings, with 'aggressive processing' and a detailed pipeline. It distinguishes itself from sibling cleanup tools like auto_cleanup_podcast, auto_cleanup_interview, and auto_cleanup_vocal by targeting live performances and field recordings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states the intended use cases: live performances, field recordings, and noisy environments. It also tells the agent to monitor progress with check_pipeline_status. However, it doesn't name alternatives or state when not to use it, so it falls just short of fully explicit routing guidance.

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

• auto_lofi_effectA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It discloses async behavior, immediate job_id return, the exact pipeline stages, and a current limitation (warmth + compression only), which is far more transparent than a typical effect description. It is silent on whether the source audio is modified destructively, but the disclosed async behavior and job_id semantics partially mitigate that.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Purpose is front-loaded and each section (pipeline, note, args) adds distinct value. The v3 reference is slightly internal/historical but it still informs the agent about capability and directs attention to the result note field. No filler to speak of.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter async tool with no output schema, it explains job_id return value, monitoring via check_pipeline_status, pipeline stages, parameter choices, and known limitations. It does not explicitly state what audio is targeted (e.g., selected clip vs entire track), but the core call-and-monitor sequence is sufficiently complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage and no enums, so the description compensates by defining the three intensity values ('light', 'medium', 'heavy') with meaningful audio-quality descriptions and the default. This fully documents the only parameter and gives an agent the exact vocabulary needed to call the tool correctly.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb ('Apply') and resource ('audio') with a distinctive 'vintage/lo-fi' scope that separates it from sibling effect tools like compressor or bass_and_treble. The creative-lo-fi label is unambiguous and instantly tells an agent what the tool is for.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly describes the async workflow ('Runs in background - returns a job_id immediately. Use check_pipeline_status to monitor'), giving clear context on how to use the result. It does not explicitly contrast this tool with individual effect siblings, but the named pipeline conveys that this is an all-in-one creative effect rather than a single processor.

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

• edit_copyA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden, and it does disclose the key behavior: the selected audio goes to the clipboard and the source is copied rather than removed. The prerequisite is also stated, which is enough for safe invocation of a non-destructive copy operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, no filler, with the operation stated first and the prerequisite immediately after. Every word earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool this is nearly complete: action, target, and precondition are all present. It could add a note about clipboard scope (e.g., that the copy can be pasted using edit_paste), but that is not necessary for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters and 100% coverage, so schema-side documentation is already complete. The description still adds useful context by tying the operation to the current track and time-range selection.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('copy') and resource ('selected audio to clipboard'), so an agent knows exactly what the tool does. It is clearly distinct from siblings like edit_cut and edit_paste because it copies to the clipboard rather than cutting or pasting.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides a concrete usage prerequisite: select tracks and a time range first. It does not explicitly enumerate when not to use it or name an alternative, but the context is clear.

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

• label_add_atA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral disclosure burden. It explicitly discloses the side effect 'Changes the current selection as a side effect' and the composed mechanism select_region + label_add, which is valuable transparency. It does not mention return values or error behavior, but for a simple add operation this is a strong disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the core purpose, and uses a short Args block for parameters. The source-comment reference is slightly extra but supports credibility rather than padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple label-adding tool with no output schema, the description covers the essential behavior, the selection side effect, and all parameter semantics. It could be more complete by mentioning what the operation returns or whether it is undoable, but it provides enough context for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description compensates by documenting all three parameters with meaningful details: start/end are in seconds, end must be >= start, and text is optional. This adds real semantic value beyond the bare input schema, though it stays fairly minimal.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'Add a label at an exact time range, regardless of the current selection,' which precisely identifies the verb, resource, and distinctive behavior. It distinguishes itself from sibling label_add by explicitly noting that it does not depend on the current selection and explains its composition from select_region + label_add.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: whenever an exact start/end range is known and the current selection should not matter. It references label_add's selection-dependent behavior, giving useful context for choosing between the tools, though it does not explicitly state 'use label_add when you want the current selection' as an exclusion.

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

• label_join_regionsA
  4.4/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the transparency burden. It discloses meaningful behavioral details: order does not matter, labels stay put, and the operation is the inverse of label_split_regions. It does not state whether the operation is destructive or what the return value is, but the core behavior is clearly conveyed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is three terse sentences with zero filler. The primary action is front-loaded, and the clarifying behavioral notes are short and directly useful.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter operation with no output schema, the description covers the essential context: what it does, how it relates to label_split_regions, and key invariants like labels staying put. It is complete enough for an agent to invoke it correctly without ambiguity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema is empty, so there is nothing for the description to explain about parameters. The baseline for a zero-parameter tool is 4, and the description appropriately avoids inventing parameter details.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action: joining audio clips across every labeled region, and explicitly identifies itself as the inverse of label_split_regions. This clearly distinguishes it from sibling label operations like label_cut_regions or edit_join without needing to inspect schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear usage direction by naming label_split_regions as its counterpart, implying it should be used to reverse or undo a split operation. It does not exhaustively list when not to use it, but for a zero-parameter command this is sufficient context.

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

• recent_commandsA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden and discloses the output fields and read-only nature of the action. It does not state ordering, retention limits, or maximum number of commands, but for a zero-parameter list command this is a minor gap.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences, places the main purpose first, and adds the usage context second. Every sentence contributes useful information with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, zero-parameter listing tool, the description is largely complete: it specifies output fields, likely use cases, and the path to command_status for further lookup. The term 'recently' is somewhat vague, but it does not prevent an agent from invoking the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool takes zero parameters, so the baseline is 4. The description adds meaningful context about the returned data but there are no parameter details needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('List'), a specific resource ('recently executed MCP commands'), and enumerates the returned fields (id, timestamp, success, result message). It also differentiates itself from the sibling command_status by explicitly mentioning that the id can be used to look up with command_status.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear use cases: checking what an earlier command actually did, and finding a command's id for command_status lookup. It names the relevant alternative tool (command_status), though it does not explicitly enumerate when not to use recent_commands.

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

• transcribe_to_fileA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool runs in the background, returns a job_id immediately, and requires a separate pip install. It does not mention how to check the resulting job status, but the key behavioral traits are clearly surfaced.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is somewhat long but tightly packed with actionable information. The initial behavioral requirements are front-loaded, and the Args section is structured and scannable. A little redundancy exists between the schema field names and the Args list, but every sentence contributes.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 5-parameter background task with no output schema and no annotations, the description is remarkably complete: it covers setup, path behavior, background execution, return behavior, and every parameter. The main gap is not pointing the agent to check_transcription_status for following up on the returned job_id.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the description fully compensates by explaining all five parameters with examples, valid values, and meaning. It adds value beyond the bare schema by clarifying path format, format choices, model sizes, language behavior, and task semantics.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action and resource: transcribe audio and export to a subtitle or text file. It also shows the exact output formats (srt, vtt, txt), making it distinguish itself from sibling transcription tools like transcribe_audio or transcribe_to_labels.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear invocation guidance: it requires separate setup, must tell the user where the file will be saved before starting, and should call get_default_transcription_folder when no path is given. It does not explicitly name sibling alternatives or say when not to use it, so it misses the full when-vs-alternatives guidance.

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

• transport_get_play_positionA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the burden of behavioral disclosure. The verb 'Get' implies a non-mutating read, and the description explicitly lists what state is returned. It does not mention units or response format, but for a zero-parameter state getter this is a reasonable level of transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  A single, front-loaded sentence that names the operation and all returned state with no filler. Every word contributes meaning, and a reader can absorb the entire purpose in seconds.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter getter with no output schema, the description covers the essential invocation context: what the tool retrieves and that it is a state inspection. The only minor gap is the lack of units or formatting details for positions, but this is not critical enough to make the tool unusable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is nothing for the description to clarify beyond what the empty schema already shows. Per the rubric, zero params receive the baseline score of 4; no further parameter documentation is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Get') with a clear resource ('current playhead position') and enumerates the exact state being retrieved: playback active status and time selection start/end. This differentiates it from sibling transport controls like transport_play, transport_stop, and transport_record, which are commands rather than queries.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The getter phrasing conveys clear context: this tool is for inspecting transport state, not for changing it. It does not explicitly name alternatives or exclusion cases, but among the many transport_* siblings its read-only purpose is immediately recognizable, so an agent can decide when to invoke it without much ambiguity.

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

• transport_recordA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden, and it explicitly discloses the non-obvious failure mode: if no input device is configured, the dispatch succeeds but recording does not actually engage. This adds real behavioral transparency beyond the basic action.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Three sentences with each one earning its place: the action, the prerequisite/failure behavior, and the stopping counterpart. The core purpose is front-loaded with no redundant wording.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool, the description covers the essential operational details: what it does, the required condition, the silent failure mode, and how to stop recording. It leaves minor ambiguity around pre-existing recording state, but this is acceptable given the tool's simplicity.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the input schema is fully documented, so there is no parameter burden for the description to carry. The baseline of 4 applies because no parameter context is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and object—'Start recording on a new track'—which clearly identifies transport_record as the tool for initiating recording. This distinguishes it from sibling tools like transport_play, transport_stop, and transport_play_region, which handle playback or stopping.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It names the complementary stop tool, transport_stop, and states a prerequisite: a working audio input device. It also warns that the command silently does nothing if no device is configured, which helps the agent decide not to rely on it in that scenario, though it does not explicitly contrast with playback tools.

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

• analyze_sample_data_exportA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden and does disclose the core write-side effect: creating a file at an absolute path with extension-dependent formatting. It also explains the limit and units controls, though it does not mention overwrite behavior or return/status.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a one-sentence purpose followed by a compact, well-labeled Args list. Every line adds actionable information with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple 3-parameter tool with no output schema and no annotations, this description covers the invocation surface well: what to pass, how the path affects format, and the default behavior. The only notable omission is explicit guidance against using sibling export tools, but the resource-specific wording mitigates that.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, and the Args block fully compensates: it adds the absolute-path requirement, the extension-to-format mapping, the numeric range and default for limit, and the allowed values and default for units. This goes well beyond the bare schema properties.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The first sentence names a specific verb ('Export'), a concrete resource ('raw sample values'), a clear scope ('from the selection'), and destination file types ('text/CSV/HTML'). This clearly distinguishes it from audio-export or label-export siblings even without naming them.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the right context: exporting raw measured sample data rather than audio or labels, with output format determined by extension. It does not explicitly name alternative tools or state when not to use it, so it stops short of full routing guidance.

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

• clip_split_at_silencesA
  4.5/5.0
  Behavior3/5

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

  No annotations are provided, so the description carries the transparency burden. It clearly explains the targeting behavior and key format, but does not disclose whether the original clip is replaced, whether the edit is destructive, or how silence boundaries are determined.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is tight and front-loaded: purpose first, then differentiation from a sibling, then parameter guidance. Every sentence earns its place with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a one-parameter tool, the definition covers purpose, usage, and argument semantics well. It does not describe the result of the split (e.g., what happens to the original clip or how new clips are returned), and it does not mention the similarly named split_range_at_silences sibling, but these are minor gaps.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Despite 0% schema description coverage, the description fully documents the only parameter, key, including its required format 'trackId:itemId'. This is exactly the meaning an agent needs beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a clear action: split one specific clip into multiple clips at silence boundaries. Also distinguishes itself from edit_disjoin by clarifying that it targets a clip directly by key rather than acting on the current selection.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly contrasts with edit_disjoin and states when this tool is appropriate: when you want to operate on one specific clip by key instead of whatever is selected. This gives an agent a concrete routing signal.

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

• edit_deleteA
  4.5/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the behavioral burden. It discloses the destructive action, the gap-closing behavior, the fact that nothing is copied to the clipboard, and the required selection state. It does not mention undo, but the core behavior is clearly and accurately conveyed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, front-loaded with the action and its behavioral consequence. Every phrase adds information and there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter command with no output schema, the description covers the command's effect, its non-effect on the clipboard, and the required user state. There are no significant gaps an agent would need to resolve before calling it.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so the baseline is 4. The description still adds useful meaning by explaining that the operation applies to the current selection rather than any explicit argument.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Delete') and resource ('selected audio'), and adds the consequence 'closing the gap' plus the explicit contrast 'does not copy to clipboard.' This clearly distinguishes it from sibling tools like edit_cut without needing to inspect schemas.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives a concrete precondition: 'Select tracks and a time range first,' which tells an agent how to prepare a valid invocation. It does not explicitly name alternatives or when-not conditions, but the clipboard note implies when edit_cut or edit_copy would be more appropriate.

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

• edit_redoA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the burden of behavioral disclosure. It states the core behavior (redo the last undone edit) and the edge-case behavior ('fails cleanly if there's nothing to redo'). This is valuable context beyond the tool name, though it does not detail broader history or state effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences, no filler, and the primary action is front-loaded. Every word earns its place, and the failure behavior is stated efficiently.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema, the description is complete. It explains the operation, provides the key failure mode, and is enough for an agent to call and interpret the result correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there is nothing to document. The schema already fully covers parameter semantics by having an empty properties object, and the description adds no conflicting or missing param information.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('redo') with a clear resource ('the last undone edit'), making the action unambiguous. It also naturally distinguishes itself from the sibling edit_undo by describing the inverse operation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use the tool: after an edit has been undone and should be restored. It does not explicitly name edit_undo as the alternative or state exclusions, but the inverse relationship is immediately clear.

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

• edit_split_deleteA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly reveals the key non-obvious behavior: deletion leaves silence rather than closing the gap. This is the critical trait an agent needs to know. It doesn't mention reversibility or output, but for a simple destructive edit that is sufficient.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded. The first sentence states the action and its distinguishing outcome in clear terms, and the second sentence provides the necessary setup. Every word earns its place with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a simple zero-parameter operation with no output schema and no annotations. The description fully covers what the tool does, how its behavior differs from related edits, and what the user must do before invoking it. Nothing essential for correct invocation is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema has zero parameters, so there is nothing for the description to explain about individual parameters. The description adds the operational precondition, 'Select tracks and a time range first,' which is useful context and goes beyond what the empty schema provides. This earns a strong score despite no formal parameters.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the operation ('Delete the selected audio') and the distinctive behavior ('WITHOUT closing the gap - leaves silence where the audio was'). This sets it apart from sibling tools like edit_cut and edit_delete, which presumably close the gap. The purpose is fully transparent.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The prerequisite is explicitly stated: 'Select tracks and a time range first.' The behavioral contrast conveyed by 'WITHOUT closing the gap' also implies when this tool is appropriate. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a 5.

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

• get_default_export_folderA
  4.5/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the behavioral disclosure burden. It clearly states the return value and fallback behavior: the user's Music folder path, falling back to the home folder if Music does not exist. For a zero-parameter getter, this is sufficient, though return type and error behavior are not specified.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two focused sentences: the first states the purpose, the second covers the return value, fallback, and usage guidance. Every word earns its place with no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  This is a trivial zero-parameter getter with no output schema, so the description needs to explain the return value and when to use it. It does both, including the fallback path. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema is an empty object with zero parameters, so there are no parameter semantics to clarify. The baseline of 4 for zero-parameter tools applies here.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb and resource: 'Get the default folder for exporting audio files.' This clearly differentiates it from the sibling get_default_transcription_folder, which is the only other default-folder getter among the listed tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides an explicit usage condition: 'Use this when the user doesn't specify where to save.' This tells an agent when to call it, and implies when not to call it, though it does not name an alternative tool explicitly.

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

• get_default_transcription_folderA
  4.5/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral burden. It transparently states that calling the tool returns the user's Documents folder, making the result and read-only nature clear. It does not detail edge cases or side effects, but none are expected for a simple getter.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is two sentences with no filler. The purpose is front-loaded, followed by the return value and a clear usage instruction. Every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, simple getter with no output schema, the description is complete: it states what the tool returns and when to call it. An agent can select and invoke it correctly without additional information.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so parameter semantics are trivially satisfied. The baseline of 4 applies because no parameter information is needed and the schema coverage is effectively complete.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool gets the default folder for saving transcription files and specifies it returns the user's Documents folder. This distinguishes it from the sibling get_default_export_folder, which concerns export rather than transcription.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives an explicit condition: 'Call this when the user doesn't specify where to save.' It provides clear usage context, though it does not name alternative tools or explicitly discuss when not to use it.

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

• label_cut_regionsA
  4.5/5.0
  Behavior5/5

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

  With no annotations, the description fully carries the behavioral disclosure burden. It clearly warns that only the last cut survives on the clipboard, explains that regions are processed last-to-first to preserve label timing, and states that the label track is unaffected. This is exemplary transparency for a mutating operation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: a one-sentence summary followed by critical caveats about clipboard behavior, processing order, and label track preservation. Every sentence adds meaningful information without padding.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter tool with no output schema, the description covers the operation, side effects, ordering behavior, and what remains unaffected. An agent has enough information to invoke it correctly and anticipate its consequences.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there are no parameter semantics to clarify. Per the baseline for parameterless tools, this is effectively complete; the description need not add anything.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Cut the audio under every label to the clipboard, closing the gaps.' This clearly identifies what the tool does and distinguishes it from generic edit_cut or label deletion tools by emphasizing all labeled regions and gap-closing behavior.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines3/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description implies the use case: removing all labeled audio regions and closing the resulting gaps. However, it does not explicitly state when to prefer this over alternatives like label_delete_regions, label_delete_audio_at, or edit_cut, nor does it mention when not to use it.

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

• label_editA
  4.5/5.0
  Behavior4/5

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

  With no annotations to rely on, the description carries the full transparency burden. It clearly discloses that editing is partial and non-destructive to unspecified fields: 'Only the fields you pass are changed' and each optional field defaults to 'unchanged.' It does not mention error handling, permissions, or return values, but the key behavioral trait for a partial-edit operation is covered.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the core purpose, and uses a structured Args list that makes each parameter's role immediately scannable. Every sentence contributes necessary information without filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple edit tool, the description provides enough to select and invoke it correctly: required key, optional fields, timing units, and partial-update behavior. The main gap is the absent handling of explicit null values—since null is the schema default, it remains ambiguous whether passing null clears a field or means 'unchanged,' which could matter in edge cases.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must fully explain the parameters, and it does. It specifies the key format ('trackId:itemId'), the meaning of text, start, and end, and the unit for times (seconds). It also clarifies the default semantics for optional parameters, adding substantial value beyond the raw schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Edit'), a resource ('existing label'), and a clear scope ('text and/or timing'). It distinguishes itself from sibling tools like label_add (existing vs new) and label_update_text (text plus timing in one call) through its explicit scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use the tool: when an existing label's text or timing needs to be modified. The phrase 'in one call' suggests it is the consolidated editing tool, and 'Only the fields you pass are changed' gives partial-update context. However, it does not explicitly name alternative tools like label_update_text or state when not to use it.

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

• label_exportA
  4.5/5.0
  Behavior4/5

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

  No annotations are present, so the description carries the behavioral burden. It discloses the output format, internal implementation (pure Python formatting of label_get_all data), and overwrite semantics. It stops short of describing failure behavior when overwrite is false or the return value, but the key side effects are visible.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The purpose is front-loaded and the args block is clean and readable. The implementation-background sentence adds transparency but is non-essential, preventing a perfect score for economy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter file-export tool with no annotations or output schema, the description supplies everything needed to call it correctly: destination path semantics, overwrite behavior, and file format. The relation to label_import completes the mental model, so no critical context is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, yet the description documents both parameters: path as an absolute output path, and overwrite with its replace behavior and default. This fully compensates for the schema's bare string and boolean types.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  Description opens with 'Export all labels to a standard Audacity label text file' — a precise verb, resource, and output format. It further specifies tab-separated start/end/text lines and references label_import, making the tool's scope distinct from siblings like label_export_chapters.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly frames the output as the same format label_import reads back, signaling interoperability and a round-trip use case. It does not, however, name sibling alternatives like label_export_chapters or label_export_audio_segments, nor state when not to use them, so guidance is clear but not exhaustive.

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

• list_effect_parametersA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It discloses that values are plugin-reported, that the extraction works uniformly across Builtin/VST3/LV2/AudioUnit, and that it returns human-formatted current values. Read-only nature is implied by 'List' but not stated explicitly, and error behavior is not described.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is appropriately front-loaded with purpose and then structured Args. The plugin examples are illustrative and useful, though slightly longer than strictly necessary; they reinforce why parameter names/ranges need not be guessed.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter read tool with no output schema, the description covers inputs, output fields, source of both parameters, and the Master bus special case. Nothing an agent needs to call it correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, but the description provides rich parameter semantics: track_id comes from project_get_info's track list, -2 means Master bus, and index is the position in the chain from list_realtime_effects. An agent can resolve both arguments without external clues.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'List a realtime effect's real, plugin-reported parameters'. It enumerates the exact returned fields (name, units, min/max/default/current value, formatted current value), and the realtime scope distinguishes it from sibling list-style tools like list_effects and list_effect_presets.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives clear workflow context by sourcing track_id from project_get_info's track list, index from list_realtime_effects, and documents the -2 Master bus sentinel. It does not explicitly name alternative tools or state when-not-to-use conditions, so it stops short of a 5.

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

• list_effect_presetsA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It explains that the operation depends on the plugin format exposing presets and explicitly states that an empty list is normal, not an error. It does not explicitly state that the operation is read-only or describe error behavior for invalid IDs, though the verb 'list' strongly implies non-mutating behavior. The added context about plugin variability is valuable beyond bare inference.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-organized: a first sentence states the purpose, a second sentence adds an essential caveat, and a clean Args section explains parameters. There is no filler or repetition. Every line contributes actionable information, and the important normal-result behavior is front-loaded near the top.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter list tool with no output schema and no annotations, the description covers the key aspects: purpose, parameter sourcing, and special Master bus value, plus a behavioral expectation about empty results. It does not specify the exact return format (e.g., array of strings) or error handling for invalid track/index values, but an agent has enough to invoke it correctly and interpret results. A slightly richer note on return type would make it fully complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must fully compensate, and it does. It defines track_id as coming from project_get_info's track list and documents the special -2 value for the Master bus. It defines index as the position in the chain from list_realtime_effects. This is precisely the kind of semantic enrichment that an agent needs to call the tool correctly, and it exceeds what the bare schema provides.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: "List a realtime effect's real factory presets". It immediately clarifies the scope with examples (reverb room/hall presets) and distinguishes itself from related operations like listing effects or parameters. The phrase 'real factory presets' clearly separates it from user presets and from parameter-level inspection.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear workflow context: track_id comes from project_get_info and index from list_realtime_effects, which tells an agent exactly how to obtain arguments. It also sets the expectation that not every plugin exposes factory presets and that an empty list is a normal outcome, preventing false error detection. It does not explicitly name alternative tools or state when not to use it, but the input provenance and normal-result caveat provide solid usage guidance.

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

• loudness_normalizeA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the transparency burden and discloses a major risk: it can boost quiet audio by 20-30dB and cause clipping, and instructs to measure first. It does not explicitly mention irreversibility or whether the operation applies to a selection, but the warning is concrete and useful.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with the action, then the danger warning and practical targets, then a clean Args block. Every sentence adds necessary information; there is no filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a low-complexity tool with no required params and no output schema, the description covers the operation, risks, usage scenarios, and all parameters. The only notable gap is that it does not explicitly state what audio is affected (selection, track, or whole project), which an agent may need to infer from context.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, but the description compensates fully by documenting all three parameters with units, ranges, defaults, and behavioral meaning (e.g., lufs_level range -145 to 0, stereo_independent semantics, dual_mono purpose). This adds value the schema does not provide.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource ('Normalize audio to a target LUFS loudness') and distinguishes itself from the generic sibling 'normalize' by the LUFS target and platform-specific values. Even without an explicit sibling comparison, the purpose is unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear usage context: recommended target LUFS values per platform and an explicit prerequisite to measure levels with auto_analyze_audio first. It does not explicitly state when to prefer normalize or other effect tools, so it stops short of a 5.

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

• project_export_audioA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral burden. It discloses the output format (WAV, stereo, 44.1kHz), the overwrite refusal default, and mandatory user-notification and folder-placement rules. It does not mention whether the export is synchronous or returns status, but it covers the most critical side effects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded with the core purpose, followed by mandatory usage constraints and parameter documentation. Every sentence carries necessary information, and the layout with an Args block is easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the simple two-parameter schema and no output schema, the description covers the essential behavior: format, path, overwrite policy, and safety constraints. It could slightly improve by referencing get_default_export_folder or explicitly contrasting with project_export_selection, but overall it is adequate for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must fully explain parameters. It does: 'path: Absolute path for the exported .wav file' and 'overwrite: Set true to replace an existing file at that path - refused by default'. This adds meaningful semantics beyond the bare schema types.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action and resource: 'Export the full project's audio (all tracks, stereo, 44.1kHz WAV)'. This differentiates it from the sibling project_export_selection by explicitly scoping to the full project, so an agent can identify when this tool is appropriate.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context: export full project audio, always tell the user the save location beforehand, and never save to the home folder root. It lacks an explicit when-not-to-use statement or direct mention of project_export_selection, but the 'full project' wording strongly implies the alternative for partial exports.

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

• project_export_selectionA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the full behavioral burden. It discloses the output format, the need for a selection, mandatory user notification about save location, folder placement restrictions, and overwrite behavior ('refused by default'). It covers the key behavioral aspects an agent needs to know before invoking.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and well-structured: opening purpose, then prerequisites, then mandatory usage rules, then parameter explanations. Every sentence adds value, and the most important operational guidance (tell user about save location) is prominently highlighted.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the low complexity (2 params, no output schema, no annotations), the description is largely complete: it covers purpose, prerequisites, key side effects (file creation, overwrite), and parameter semantics. It stops short of explaining the return value or what happens if no selection exists, but these are minor gaps for an export function.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the Args section must compensate. It clearly explains 'path: Absolute path for the exported .wav file' and 'overwrite: Set true to replace an existing file at that path - refused by default,' adding meaningful semantics beyond the raw schema types. This fully compensates for the missing schema descriptions.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a clear, specific verb+resource: 'Export only the current selection's audio (mono, 44.1kHz WAV).' It identifies the exact output format and distinguishes this selection-export operation from sibling project-level exports like project_export_audio by using 'only the current selection's audio.'

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly instructs the prerequisite: 'Select a time range first with select_region or select_all.' This gives clear context for when to call the tool. However, it does not explicitly name alternative tools or state when not to use it, though the 'only...selection' phrasing implicitly differentiates from whole-project export.

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

• set_realtime_effect_activeA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries full behavioral burden. It clearly explains the state transition ('True to enable, False to bypass') and explicitly notes that the effect is not removed, preventing a wrong assumption of destructive behavior. It does not mention outcome reporting or edge cases, but for a simple toggle this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact, front-loaded with a clear one-sentence purpose, and uses a concise Args block with no redundant prose. Every line contributes necessary information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a three-parameter boolean setter with no output schema, this is nearly complete: it identifies the chain, the track selection convention, the effect index source, and the active semantics. The main gap is that it does not describe what the tool returns or what happens on invalid input, but this is minor for such a focused utility.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must fully compensate. It does: track_id is tied to project_get_info's track list with -2 as Master bus, index is tied to list_realtime_effects, and active is explicitly mapped to enable/bypass. Every parameter is given meaning beyond its raw type.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb ('Enable or bypass'), a specific resource ('one effect in a track's or the Master bus's realtime effect chain'), and clarifies scope ('without removing it'). This clearly distinguishes it from sibling tools like add_realtime_effect, remove_realtime_effect, and list_realtime_effects.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives useful usage context: track_id comes from project_get_info's track list, -2 means the Master bus, and index comes from list_realtime_effects. However, it does not explicitly state when to prefer this tool over remove_realtime_effect or add_realtime_effect, so it lacks explicit exclusions or alternative routing.

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

• track_get_infoA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden. It discloses meaningful output behavior: full clip list with start/end/title per clip, or label list for label tracks, and implies a read-only operation via 'Get'. It does not explicitly state side-effect-free or error behavior, but the conditional label-track behavior and output details add real transparency.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the first sentence states the tool's purpose and return content, followed by a focused Args section. Every sentence earns its place, especially the caveat about track_id, and there is no redundant or vague filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter info tool with no output schema, the description is largely complete: it explains where the ID comes from, what the tool returns, and how label tracks differ. Minor missing details like exact JSON key names or error behavior are unlikely to block correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must fully explain the single parameter. It does so excellently: track_id is defined as 'The track's id, from project_get_info's track list', with an explicit warning that it is NOT the same as the 0-based 'track' index used elsewhere. This is precise, actionable, and prevents a likely misuse.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the specific verb and resource: 'Get detailed info about one track', and enumerates the exact fields returned (title, type, rate, mute/solo, clip list, or label list for label tracks). This distinguishes it from sibling tools like project_get_info or label_get_all, which operate at different scopes.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context on how to obtain track_id: 'from project_get_info's track list', and explicitly warns against using the 0-based 'track' index from track_set_properties'/track_resample. It does not explicitly name alternative tools to choose between, but the sourcing guidance and exclusion of a common mistake provide solid usage direction.

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

• transcribe_to_labelsA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description carries the disclosure burden. It reliably discloses asynchronous behavior (immediate job_id return), the experimental status, setup requirements, and the need to clean up previous labels. It could further mention whether it uses selected audio or the entire project and whether it creates or reuses a label track, but the provided behavioral details are strong.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well-organized and front-loaded: purpose first, then setup, execution mode, cleanup guidance, and parameter explanations. Every sentence adds value, and the Args section is clean and easy to parse.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For an experimental async tool with no output schema, the description covers the essential operational context: dependencies, background execution, job_id return, label cleanup, and parameter meanings. It does not mention how to track job completion or exactly which audio is transcribed, but enough information is present for an agent to invoke the tool correctly and know what to expect.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema contains no parameter descriptions, yet the description fully documents all three parameters: model_size with specific Whisper model values, language with ISO code or auto-detect semantics, and task with transcribe vs translate behavior. This fully compensates for the 0% schema coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states a specific action: 'Transcribe audio and add Audacity labels at each segment timestamp.' This distinguishes it from sibling transcription tools like transcribe_to_file or transcribe_audio by emphasizing label output, and the background/job_id behavior further differentiates it.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides practical context: it is experimental, requires a separate pip install, runs in the background, and explains how to clear stale label tracks before re-running. However, it does not explicitly contrast this tool with transcribe_to_file, transcribe_audio, or transcribe_selection, so an agent must infer when this tool is preferred over those alternatives.

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

• transport_playA
  4.5/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the unconditional nature, the non-stopping behavior, and the internal composition ('checking transport_get_play_position first and only toggling if not already playing'). This is more than most descriptions provide, though it could also mention whether playback is synchronous or whether it can fail on empty projects.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single dense paragraph, slightly longer than necessary, but every clause earns its place: the unconditional behavior, the contrast with the toggle sibling, the lack of a dedicated 'always play' action in v4, and the composition logic. It is front-loaded with the key behavior before the parenthetical explanation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given zero parameters and an output-schema-less tool, the description covers the essential context: what triggers playback, how it avoids the toggle problem, and how it relates to the sibling. It lacks a note on failure modes (e.g., no audio loaded) but that is a minor omission for a transport action.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so there's nothing to document. The description adds context about the action's semantics ('current cursor position','unconditionally'). A baseline of 4 is appropriate for no-parameter tools since there is no schema burden to compensate for.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Start playback'), a specific resource ('current cursor position'), and an explicit scope ('unconditionally... never stops playback'). It clearly distinguishes itself from the sibling transport_play_stop, which is the most similar tool in the sibling list.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says when to use this tool versus the alternative: it names transport_play_stop, explains that the alternative is a toggle, and states the condition ('if not already playing'). It also explains the composition logic (checking transport_get_play_position first), which gives the agent a clear decision rule.

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

• analyze_beat_finderA
  4.6/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the behavioral burden. It discloses that the tool mutates the project by adding labels to the label track, creating one if needed, and it tells the agent how to retrieve the results via label_list. This adequately covers the key side effects for a simple tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The definition is short and front-loaded: a one-sentence summary, followed by side-effect and readback details, then the single parameter. Every sentence earns its place and there is no redundant repetition of schema content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool's low complexity, one optional parameter, no output schema, and no annotations, the description is complete. It explains what the tool does, the side effect, how to read the results, and the parameter semantics. Missing edge-case details are low-value for this simple operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must fully explain the parameter. It does: threshold_percent is given a range (5-100), a direction ('Lower finds more beats'), and a default (65). This fully compensates for the schema's bare property definition.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource: 'Find beats in the selected audio and add a label at each one.' It clearly states both the action and the resulting side effect, and the beat-finding focus distinguishes it from the many label_* and analyze_* sibling tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description identifies the prerequisite ('selected audio') and gives a clear follow-up workflow: 'call label_list afterward to read the detected beat positions.' It does not explicitly name alternative tools or exclusion conditions, but the intended usage context is clear.

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

• auto_master_musicA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full transparency burden, and it does so thoroughly. It discloses that the tool runs in the background and returns a job_id, details the pipeline order and defaults, lists concrete genre loudness targets, explains the clip-safe fallback, and warns about the counterintuitive quieter-if-already-loud behavior. There is no contradiction with annotations because none exist.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the tool's purpose and async behavior, then provides necessary pipeline and loudness-target detail. It is longer than minimal, but the complexity of a mastering pipeline justifies most of that length. The 'see _mastering_pipeline's docstring for sources' aside and some marketing phrasing add minor noise, but overall it remains well-structured.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema and no annotations, the description covers the essential invocation details: both parameters with defaults, the job_id return, the monitoring path, pipeline stages, loudness targets, and the quieter-than-input caveat. It does not explicitly state how the target track is selected before calling or describe failure/error handling, but it is close to self-sufficient.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  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 for the bare schema. It explains both parameters: style is a genre preset with the six accepted values and a default, and noise_reduce is a gentle noise-reduction toggle defaulting to false. This adds real semantic meaning beyond the schema's type/default declarations.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with 'ONE-CLICK MUSIC MASTERING' and clearly states the tool's job: professionally master a music track with genre-tuned settings toward a published loudness target. This distinguishes it from peak-limiting-only tools and from the audiobook/podcast cleanup siblings. The verb, resource, and intent are immediately unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It establishes clear context: use this when you want automatic, one-click music mastering aimed at genre-specific loudness rather than just peak limiting. It also explains the async workflow and directs the agent to check_pipeline_status for monitoring. It does not explicitly name alternative tools for manual mastering or podcast/audiobook cleanup, so it stops short of a 5.

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

• clip_stretchA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full disclosure burden. It richly explains the non-obvious delta_sec sign convention, the growing vs. shrinking behavior, and the time-stretching fallback. It does not explicitly state whether shrinking is destructive or undoable, but the provided behavioral detail is substantial.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core behavior, followed by the critical sign-convention warning and then parameter explanations. Every sentence adds necessary information, and the example is compact yet highly clarifying.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has four parameters and a counterintuitive sign convention, but the description covers all of them, offers a real example, and explains the underlying audio behavior. Even without an output schema, the agent has enough to invoke the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description must explain all parameters, and it does. It documents key format, side values, delta_sec sign semantics with a concrete example, and min_clip_duration's default and purpose.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('grow or shrink') and resource ('a clip's left or right edge'), making the operation immediately clear. It also distinguishes itself from sibling tools by explaining the sign convention relative to clip_trim and the behavior when no trimmed audio remains.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives clear context for when this tool is appropriate: growing reveals previously-trimmed audio, and shrinking reduces the clip inward. It references clip_trim's sign convention but does not explicitly state when to choose clip_stretch over clip_trim or other editing tools.

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

• edit_silenceA
  4.6/5.0
  Behavior4/5

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

  With no annotations available, the description carries the disclosure burden. 'Replace' transparently signals a destructive modification of the selected audio, and the selection precondition clarifies the scope. It could mention undoability or no-selection behavior, but the core behavioral risk is clearly conveyed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two short sentences contain both the action and the prerequisite, with no filler or redundancy. The structure is appropriately front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-output-schema tool, the description is complete: it states what happens, to what it applies, and what the user must do first. There is no missing critical information for correct invocation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero schema parameters, and the description fully explains how the target is determined via the current track and time-range selection. This compensates completely for the empty input schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Replace') and resource ('selected audio') with a clear result ('with silence'). This differentiates it from sibling tools like edit_cut, edit_delete, and generate_silence, even though no sibling is named explicitly.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly states the necessary precondition: 'Select tracks and a time range first.' This gives an agent actionable context for invocation, though it does not explicitly list alternatives or exclusion cases.

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

• edit_trimA
  4.6/5.0
  Behavior4/5

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

  No annotations are present, so the description carries full responsibility. It clearly discloses the destructive nature ('delete everything except the selected region') and the required prior selection state. It does not mention undoability or layout side effects, but the core behavior is transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no filler: the first states the action, the second states the prerequisite. Information is front-loaded and each sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given zero parameters, no annotations, and no output schema, the description fully covers what the tool does and what must happen before invoking it. An agent has sufficient information to select and call the tool correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema is empty (0 parameters), so the baseline is 4. The description adds essential meaning by explaining that the implicit inputs are the currently selected tracks and time range, which is critical for correct invocation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb ('Trim'), a resource ('audio'), and the precise operation ('delete everything except the selected region'). This clearly distinguishes it from sibling editing tools like edit_cut or edit_delete by defining its selection-based destructive scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives an explicit prerequisite: 'Select tracks and a time range first', which tells the agent that prior selection is required and implies when to use the tool. It does not name alternatives or exclusion conditions, so it stops short of a 5.

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

• effect_adjustable_fadeA
  4.6/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full behavioral burden and does so excellently. It discloses a live-confirmed crash for multi-clip selections, the unguarded assert name, and that a clean single-clip selection was confirmed to work. This is far beyond typical effect-tool documentation.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The purpose is front-loaded and the Args section is scannable. The crash warning is slightly verbose with repeated 'confirmed live' phrasing, but the length is justified because the precondition is critical to safe invocation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description covers all parameters, defaults, units, and the critical crash edge case, which is enough for an agent to invoke the tool correctly. It does not describe return values or whether the effect is destructive/undoable, but the core invocation requirements are complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, but the description documents every parameter: fade_type allowed values and default, mid_fade_adjust_percent range, units meaning ('Percent' or 'dB'), and start_level/end_level semantics. This adds meaning that the bare schema cannot convey.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Apply a customizable fade to the selected audio.' The phrase 'customizable' plus the parameter list (fade_type, levels, mid-fade adjustment) clearly distinguishes it from simpler siblings like effect_fade_in and effect_fade_out.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives explicit, actionable usage context: a single-clip selection is required, and violating that precondition causes a crash. It does not explicitly name alternatives or say when to prefer this over simpler fade tools, but the selection guidance is strong and concrete.

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

• label_get_allA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden, and it does disclose the key behavioral trait: it returns structured data with specific fields, not raw content blocks. It provides enough transparency for a zero-parameter read operation, though it could mention whether 'all labels' means all in the project or some other scope.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, tightly worded sentence that immediately states what the tool returns and how it differs from its sibling. There is no redundant or filler content.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple, zero-parameter read tool, the description is largely complete: it names the tool, the output fields, and the distinguishing alternative. The only minor gap is not explicitly defining the scope of 'all labels,' but the sibling comparison and structured-output detail make the tool safely invocable.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and schema description coverage is 100%, so there is nothing for the description to clarify. The baseline of 4 applies because no parameter ambiguity exists.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly identifies the operation: 'Get all labels' and specifies the exact output shape (key, text/title, start, end). It also explicitly contrasts itself with sibling label_list, making its purpose distinct even among many label-related tools.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly names the alternative tool label_list and explains the difference: this tool returns structured data rather than raw MCP content blocks. This gives an agent a clear basis for choosing label_get_all over label_list.

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

• project_closeA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full disclosure burden and does it well: it reveals the refusal behavior for dirty projects and the underlying rationale. It omits minor edge behaviors like what happens when no project is open, but the primary safety-critical behavior is transparently disclosed.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no filler: the core action is front-loaded, followed immediately by the critical caveat and the remedy. Every clause earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter, no-annotation, no-output-schema tool, the description covers everything an agent needs to invoke it safely: what it does, when it fails, what to do first, and why. The only gap is unspecified success/error return behavior, which is minor given the structured context is minimal.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters, so the baseline is 4 per the rubric. There is nothing for the schema to document and nothing for the description to compensate for; the description's behavioral context is all that is needed.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific verb ('Close') and resource ('the current project') in the opening sentence. Among siblings like project_new, project_open, and project_save_as, the action is unambiguous and distinct.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly names the alternative (project_save_as) and the exact condition that requires it (unsaved changes). It also explains why the tool cannot proceed on a dirty project — an interactive dialog that isn't safe over MCP — leaving no inference to the agent.

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

• project_get_infoA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden of behavioral disclosure. It makes clear this is a read-only project-info operation and discloses the limitations: it provides track summaries, not full clip lists. It could add explicit statements about side effects or preconditions, but the 'Get' verb and enumerated fields already communicate the essential behavior.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is concise and every sentence earns its place. The first sentence front-loads the purpose and enumerates the information returned; the second sentence gives a necessary routing hint to a sibling tool. There is no fluff or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Without an output schema, the description carries the burden of explaining return values, and it does so thoroughly: path, display name, unsaved changes, duration, and per-track fields. It lacks explicit formatting or type details for these fields and doesn't mention prerequisites like having a project open, but for a zero-parameter get_info tool it is reasonably complete.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema description coverage is 100%. The description doesn't need to explain any parameters. The baseline of 4 for a zero-parameter tool applies, and no additional parameter semantics are necessary.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states what the tool does: retrieve project-wide information, and enumerates the exact fields returned (path, display name, unsaved-changes state, duration, and per-track summary). It also explicitly differentiates itself from track_get_info by directing the agent to use a track's id for full clip lists.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives a clear usage guideline: use this tool for project-level summary information, and use track_get_info with a track id when full clip or label data is needed. This explicitly routes the agent to the appropriate alternative rather than leaving it to infer.

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

• select_clipA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral burden. It discloses the selection side effects: selecting the track, the clip itself, and the time range spanning it. It doesn't mention whether the previous selection is replaced, but for a simple selection tool this is reasonably transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the first sentence states purpose and behavior, and a small Args section documents the only parameter. No filler or redundant schema repetition exists.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter selection tool with no output schema, the description is complete: it defines the action, the selection scope, the parameter format, and the parameter source. Nothing required to invoke the tool correctly is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The single parameter key is clearly explained beyond the schema's bare 'string' type. The description specifies the 'trackId:itemId' format and tells the agent exactly where to obtain it (track_get_info's clip list), which fully compensates for the 0% schema description coverage.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Select') with a clear resource ('a specific clip') and key-based identification. It also states exactly what the selection includes (track, clip, and time range), making the tool's purpose unmistakable and distinct from siblings like select_tracks and select_region.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description clearly implies when to use this tool: when you have a clip key from track_get_info's clip list and want to select that specific clip. It doesn't explicitly name alternatives or exclusion conditions, but the phrase 'specific clip by key' gives enough context to route an agent away from broader selection tools.

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

• track_muteA
  4.6/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full burden and does well: it discloses the muting/unmuting behavior, the default mute value, and the critical 0-based track index convention. It does not mention side effects like undo behavior or whether playback is affected, but for a simple setter this is adequate.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and well-structured: a one-sentence purpose, a wrapper clarification, and a clean Args section. Every sentence earns its place, with no fluff or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter wrapper, the description is complete enough for an agent to call it correctly. It covers the operation, both parameters, the default, and the crucial track indexing caveat; no output schema or further details are necessary.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, yet the description fully compensates by explaining both parameters: track is 0-based, follows track_set_properties convention, and is NOT the 'id' field from project_get_info/track_get_info; mute is True/False with a default of True. This adds essential meaning beyond the bare schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Mute or unmute a track by index.' It clearly differentiates itself from the broader track_set_properties tool by calling itself a 'Convenience wrapper over track_set_properties' mute parameter,' and the singular 'by index' distinguishes it from track_mute_all.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description provides clear usage context by identifying this as a convenience wrapper over track_set_properties' mute parameter, implying it is the simpler choice for single-track mute/unmute operations. It does not explicitly state when not to use it or mention alternatives like track_mute_all, so it falls short of a 5.

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

• transcribe_audioA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description carries the behavioral burden and does so well: experimental status, background execution, job_id return, local/offline dependency, required pip setup, and language auto-detection pitfalls are all disclosed. It does not cover failure modes or whether models need downloading, but the key async behavior is transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is well organized and front-loaded: core purpose and warning first, then workflow, then caveats, then a compact Args block. No sentence is redundant, and all operational details earn their place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The tool has no output schema or annotations, but the description is self-contained: it explains prerequisites, async behavior, monitoring, language caveats, and every parameter. An agent has enough to select, invoke, and follow up on the job correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description fully compensates by documenting all three args with allowed values, defaults, and semantics: model_size options, ISO language/None, and transcribe vs translate. This adds meaning the bare schema completely lacks.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific operation: transcribe the entire project audio with faster-whisper, and clarifies it runs locally/offline. The phrase 'entire project audio' distinguishes it from selection/label/file-target transcription siblings without ambiguity.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit workflow guidance: run in background, receive job_id immediately, poll check_transcription_status every 10-15 seconds, and pass language explicitly to avoid auto-detection errors. It does not explicitly contrast with transcribe_to_file or transcribe_selection, so no exclusions are stated.

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

• clip_set_speedA
  4.7/5.0
  Behavior5/5

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

  There are no annotations, so the description carries the full burden of disclosure. It explicitly says no audio is processed, the operation is reversible, and speed is a duration multiplier rather than a playback-rate multiplier, with formula and concrete examples. This is exceptionally transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with purpose and prominently warns about the counterintuitive speed semantics. There is mild redundancy between the prose explanation and the arg list, but the extra length is justified by the subtlety of the behavior.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple two-parameter tool with no output schema and no annotations, the description provides everything needed for correct invocation: exact meaning of each parameter, behavioral caveats, reversibility path, and a permanent alternative. No critical information is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema has 0% description coverage, but the description fully documents both parameters: key format is defined as 'trackId:itemId', and speed is explained with exact multiplier values and their effect on duration. This fully compensates for the empty schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific action and object: 'Non-destructively change one clip's speed', which clearly states what the tool does. It also names related tools like clip_reset_speed and clip_render_pitch_speed, helping distinguish this operation from reversible and permanent alternatives.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explains that the change is non-destructive and reversible via clip_reset_speed, or can be made permanent with clip_render_pitch_speed. This gives an agent clear decision context, though it does not enumerate every possible alternative such as clip_stretch.

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

• list_effectsA
  4.7/5.0
  Behavior5/5

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

  With no annotations to indicate safety or side effects, the description carries the full burden and does so excellently. It discloses confirmed behavioral quirks: category filtering silently misses VST3 effects, add_realtime_effect requires the internal PluginID rather than title, and limit caps results are visible via totalMatched.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness4/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is long but dense with essential caveats and integration details. A small amount of redundancy exists—the category limitation is stated both in the IMPORTANT paragraph and again under the category argument—but the layout is otherwise well-organized and front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a tool with no output schema, no annotations, and four undocumented parameters, the description covers everything an agent needs: parameter behavior, output field meanings, cross-tool usage, failure modes, and filtering strategy. Nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must fully document the parameters, and it does. Every parameter is explained with type semantics, case-insensitivity, allowed family values, examples, defaults, and the limit's relationship to totalMatched.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description clearly states the tool lists installed effects/plugins across families (Builtin, VST3, Nyquist, etc.), and it distinguishes the result semantics from related effect tools. It also names the exact downstream use of each result field, making the purpose unambiguous.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description gives excellent practical guidance: use family='VST3' with a search keyword for VSTs, avoid category filtering for third-party plugins, and use title vs. id depending on whether applying effects or adding realtime effects. It does not explicitly state when to prefer an alternative listing tool, but it provides clear context for the intended usage.

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

• project_newA
  4.7/5.0
  Behavior4/5

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

  Even with no annotations, the description discloses an important behavioral quirk: calling it while a project is open would open a separate application window. It also clarifies that it does not replace the current project in-place. This gives agents critical expectations beyond the simple 'create' verb.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Two sentences with no filler. The main purpose is stated first, followed immediately by the necessary precondition and instruction sequence. Every clause adds useful information for correct invocation.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a zero-parameter creation tool with no output schema, the description is sufficient: it gives the action, the precondition, the fallback when the precondition is unmet, and the relevant sibling tools to use first. Nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and an empty schema, so there is no parameter detail to add. The baseline of 4 applies, and the description's note about saving/closeing relates to preconditions rather than parameters, which is appropriate.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a precise action: 'Create a new project in the current window.' It clearly distinguishes itself from project_open, project_close, and project_save_as by emphasizing the current-window behavior and the prerequisite that no project is open.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly tells the agent when the tool works: only when no project is currently open. It also gives the correct alternative sequence—project_save_as if needed, then project_close—and explains the consequence of ignoring the precondition.

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

• suggest_and_add_effectA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full transparency burden and meets it well. It discloses the search scope (all actually-installed, realtime-capable effects), the matching heuristic (category keywords against title/vendor, since VST3 categories report 'None'), the soft preference via _PREFERRED_VENDORS, and the fact that alternatives are returned to avoid a black box.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core workflow and then adds necessary implementation caveats, all in compact paragraphs. The Args section is structured and adds information that the schema lacks; no sentence is filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness4/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  The description gives the agent enough to select and call the tool correctly, including parameter sourcing and behavior of the suggestion logic. The only gap is the absence of an output schema and only a vague statement that 'alternatives' are returned, without specifying the exact response shape or no-match behavior.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only gives property names and types (0% description coverage), so the tool description must supply semantics. It does: track_id is tied to project_get_info's track list with -2 reserved for Master, and category lists all 11 accepted values.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb+resource pair ('Find a good installed effect ... and add it as a realtime effect') and labels the workflow ('pick the right plugin for me'). This clearly distinguishes the tool from siblings like add_realtime_effect or list_effects, which either require an already-chosen effect or only enumerate available effects.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly establishes when to use this tool: the user has a stated goal or category but not a particular plugin, and the tool searches installed realtime effects for them. It does not explicitly name the alternative tools to use when the exact effect is already known, though that contrast is inferable from the sibling list.

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

• track_unmute_allA
  4.7/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It clearly reveals the key behavioral trait: the operation applies to every track, including unselected ones, not just the current selection. This is precisely the kind of non-obvious behavior an agent needs to know before invoking the tool.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is a single, well-structured sentence that front-loads the action and then clarifies the full scope. Every word contributes meaning; there is no filler or redundant information.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple zero-parameter mutation tool, the description is fully sufficient. It states the exact action ('unmute'), the exact scope ('every track in the project'), and an important behavioral caveat ('including any not currently selected'). No additional context is needed for an agent to invoke it correctly.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and 100% schema coverage, so parameter documentation is not needed. The description adds meaningful context about the operation's scope even though there are no params to document. Baseline 4 applies for a zero-parameter tool.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description uses a specific verb ('Unmute') with a clear resource ('every track in the project') and clarifies scope with 'including any not currently selected.' This clearly distinguishes it from sibling tools like track_mute and track_mute_all, which perform mute operations.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description states clear context: this tool unmutes all tracks in the project regardless of current selection. It does not explicitly name alternatives or exclusion conditions, but for a zero-parameter action the usage is evident. The mention of unselected tracks implies this is the tool to use when selection should be ignored.

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

• auto_cleanup_audioA
  4.8/5.0
  Behavior5/5

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

  With no annotations provided, the description carries the full burden and does so thoroughly: it discloses that the operation runs in the background, returns a job_id immediately, and should be monitored via check_pipeline_status. It also reveals the processing order and explicitly states what the tool will NOT do to the audio. This is well beyond minimal disclosure.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the key promise, then gives usage context, runtime behavior, pipeline, and exclusions before detailing parameters. Every sentence earns its place; the all-caps exclusion line is emphatic but compact. It avoids redundancy despite covering a lot.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a background, two-parameter tool with no output schema, the description covers everything needed to invoke it correctly: async behavior, monitoring method, pipeline order, parameter semantics, and the essential precondition about audio levels and the first 0.5s noise profile. Nothing critical is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description fully compensates. Both parameters are explained with behavior, defaults, and practical caveats—e.g., remove_noise's 'first 0.5s should be room tone/silence' warning. This adds meaning far beyond the bare boolean schema.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific action ('Remove noise and artifacts') with a clear scope ('WITHOUT changing loudness or dynamics'), and the 'SAFE CLEANUP' framing distinguishes it from sibling mastering tools like auto_master_music or loudness_normalize. The pipeline breakdown (DC offset removal, noise reduction, click removal) adds further precision.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It explicitly states when to use: 'Use this when audio levels are already good and you just want to clean it up.' It also gives when-not guidance via 'NO compression, NO normalize, NO LUFS. Just clean.' However, it does not name a specific alternative tool for cases where loudness/dynamics adjustments are needed, leaving the agent to infer that from the sibling list.

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

• clip_render_pitch_speedA
  4.8/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the full burden of behavioral disclosure. It clearly communicates the irreversible nature, the fact that reset tools become ineffective after this operation, and the edit_undo alternative. This goes well beyond a generic action statement.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The core action is front-loaded, followed by the critical caveat and fallback instruction, then the parameter spec. Every sentence earns its place with no filler or redundancy.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter, irreversible audio-bake operation, the description gives the purpose, usage context, irreversibility warning, undo path, and parameter format. No output schema is needed for this fire-and-forget action, so nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The schema only provides 'key' with type string and title 'Key', with no description. The tool description compensates fully by specifying the exact expected format: 'trackId:itemId' format for the clip's key.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'permanently bake a clip's pitch/speed changes into its audio.' It also distinguishes itself from the non-destructive clip_set_pitch/clip_set_speed tools and from the reset tools, so an agent can tell it apart from its siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Explicitly says to use it once happy with a non-destructive preview from clip_set_pitch/clip_set_speed, warns that clip_reset_pitch/clip_reset_speed will no longer work, and directs the user to edit_undo as the fallback. This is clear when-to-use and when-not-to-use guidance.

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

• clip_set_pitchA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description carries the full burden and does so well: it discloses that the operation is non-destructive, processes no audio, is playback-time only, reversible, and can be permanently baked. This clearly sets expectations.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact and front-loaded: the core behavioral distinction appears first, followed by only necessary argument details. No filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-required-parameter tool with no output schema, the description covers what the agent needs: what it does, the key format, the semitones meaning, and the related reset/render workflows. Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must add meaning for both parameters. It specifies the key format ('trackId:itemId' from track_get_info) and explains semitones as a pitch shift that can be negative.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific operation—non-destructively changing one clip's pitch—and clarifies that it is a playback-time transform with no audio processing. This distinguishes it from sibling tools like effect_change_pitch or clip_set_speed.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It provides clear context: use for non-destructive, per-clip pitch changes, and it names follow-up/reversal alternatives (clip_reset_pitch, clip_render_pitch_speed). However, it does not explicitly contrast this tool with sibling pitch-changing alternatives such as effect_change_pitch or clip_set_speed.

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

• label_export_audio_segmentsA
  4.8/5.0
  Behavior5/5

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

  With no annotations, the description fully carries behavioral disclosure. It reveals output format restrictions (mono WAV only), naming scheme, skipping of zero-length point labels, non-overwrite behavior with reporting, performance warning, and a limitation compared to v3's Export2. This is unusually transparent.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  Every sentence earns its place. The main action is front-loaded, and each subsequent sentence covers a distinct behavioral or practical concern without repetition or filler. It is detailed but compact.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a single-parameter tool with no output schema and no annotations, this description provides everything an agent needs to invoke it correctly: file naming, skip conditions, overwrite behavior, output format limitation, and a mandatory user-facing confirmation step.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, so the description must explain the only parameter. It does: 'directory: Absolute path to the output directory.' That adds crucial meaning beyond the bare string type, including the requirement that the path be absolute.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Export the audio under each label as its own mono WAV file.' It clearly distinguishes this from label metadata exports like label_export or label_export_chapters by focusing on per-segment audio file generation.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines4/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit usage guidance: always tell the user the output directory before calling, point labels are skipped, existing files are never overwritten, and long segment lists may take a while. It does not name alternative tools or say when not to use it, but the context is clear enough for correct selection.

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

• set_effect_parameterA
  4.8/5.0
  Behavior4/5

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

  With no annotations provided, the description carries the full behavioral burden. It discloses the exact-value mutation semantics and adds a valuable live caveat about VST3 normalized 0-1 scaling versus displayed units, plus the advice to re-read currentValueString afterward. It does not mention return values or error behavior, but the most important behavioral quirk is covered.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The purpose is front-loaded in one clear sentence, followed by a compact Args-style breakdown. The VST3 caveat is long but necessary and correctly placed under value, so every sentence earns its place.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a 4-parameter mutation tool with no annotations and no output schema, the description provides all lookup paths, range constraints, and a critical units mismatch warning. An agent has enough information to invoke the tool correctly and verify the result by re-reading currentValueString.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema description coverage is 0%, so the description fully compensates. Every parameter is explained with its source or constraint: track_id's Master bus sentinel, index from the effect chain, parameter_id from the effect parameter list, and value bounded by minValue/maxValue with the normalized-scale warning.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  States a specific action — 'set one real-time parameter on a realtime effect to an exact value' — with concrete examples like wet/dry mix and decay time. It explicitly distinguishes itself from add/remove/bypass whole-effect operations, making it clearly separable from sibling tools like set_realtime_effect_active.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  Provides explicit lookup sources for every argument: project_get_info for track_id, list_realtime_effects for index, and list_effect_parameters for parameter_id and value range. It also tells the agent when not to use this tool (not for adding/removing/bypassing effects), which is strong alternative guidance.

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

• track_mute_allA
  4.9/5.0
  Behavior5/5

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

  With no annotations provided, the description carries full responsibility for behavioral disclosure. It goes beyond a simple action statement by explaining that it uses a dedicated C++ command iterating the real track list by id, and why the alternative approach would silently affect the wrong track when label tracks are present. This is rich, non-obvious behavioral context.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is compact: one clear opening sentence stating the action, followed by a dense but relevant technical note explaining why this tool exists rather than being emulated via track_set_properties. Every sentence earns its place, and the key scoping information is front-loaded.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  Given the tool has no parameters, no output schema, and no annotations, the description still provides everything an agent needs to select and invoke it correctly. It explains the exact effect, scope, and an important implementation risk, making the definition contextually complete for this simple operation.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters4/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The tool has zero parameters and the schema already provides 100% coverage by defining an empty object. The baseline for zero-parameter tools is 4, and the description adds nothing further about parameters because there is nothing to clarify.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description states a specific verb and resource: 'Mute every track in the project, including any not currently selected.' This clearly distinguishes it from single-track muting operations like track_mute and from track_set_properties by emphasizing the project-wide scope.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  The description explicitly says when to use this tool (when muting every track, including unselected ones) and explicitly warns against using track_set_properties as a substitute, explaining the index-based addressing pitfall. This gives the agent both a positive and negative usage signal.

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

• add_realtime_effectA
  5/5.0
  Behavior5/5

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

  With no annotations available, the description carries full behavioral burden and delivers: it discloses non-destructiveness, adjustability, removability, live GUI access, and a concrete failure mode when passing a title instead of a Plugin ID. This significantly exceeds the bare 'add effect' meaning.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, followed by a useful comparison, then compact parameter guidance. Every sentence adds practical value, including the confirmed live failure note, with no filler or repetition.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a two-parameter action tool with no output schema and no annotations, this description covers purpose, target selection, effect ID provenance, common pitfall, and relationship to alternatives. Nothing needed to invoke it correctly is left undocumented.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  Schema coverage is 0%, but the description compensates thoroughly: track_id is sourced from project_get_info with -2 reserved for the Master bus, and effect_id is explicitly the list_effects 'id' field, not 'title', with a confirmed failure example. This is exactly the semantic detail the schema lacks.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description names a specific verb and resource: it adds a non-destructive realtime effect to a track's or the Master bus's effect chain. It explicitly differentiates itself from apply-effect/effect_* tools, making its purpose unambiguous relative to siblings.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It clearly contrasts with apply-effect/effect_* tools by noting this effect stays adjustable and removable, and it references the realtime effects panel workflow. This tells the agent when this tool is appropriate and which alternatives are for different behavior.

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

• transcription_set_modelA
  5/5.0
  Behavior5/5

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

  No annotations are provided, so the description carries the full burden. It discloses experimental status, background execution, immediate job_id return, and model download sizes with accuracy tradeoffs. This is strong behavioral disclosure for a tool with no structured annotation coverage.

  Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

  Conciseness5/5

  Is the description appropriately sized, front-loaded, and free of redundancy?

  The description is front-loaded with the core purpose, immediately followed by the critical usage warning. The model-size list and Args section are compact and every sentence contributes actionable information without filler.

  Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

  Completeness5/5

  Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

  For a simple one-parameter background tool with no output schema, the description covers the purpose, the exact conditions to call it, the behavioral execution model, the parameter options, and what to expect in return ('returns a job_id immediately'). Nothing essential is missing.

  Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

  Parameters5/5

  Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

  The input schema only documents model_size with a default and has 0% description coverage. The description fully compensates by enumerating every valid value ('tiny', 'base', 'small', 'medium', 'large-v3') and adding size and accuracy guidance for each, plus a recommendation.

  Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

  Purpose5/5

  Does the description clearly state what the tool does and how it differs from similar tools?

  The description opens with a specific verb and resource: 'Pre-download a whisper model.' It immediately clarifies the tool's narrow role and distinguishes it from transcription tools like transcribe_audio by stating that transcription tools handle model loading automatically.

  Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

  Usage Guidelines5/5

  Does the description explain when to use this tool, when not to, or what alternatives exist?

  It gives an explicit call condition: 'ONLY call this if the user explicitly asks to download or change the model.' It also gives an explicit exclusion: 'Do NOT call this before transcribe_audio,' which tells the agent exactly when not to use it.

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