Server Quality Checklist

Tool Scores

• mcp_opendaw_set_track_soloC
  2.1/5.0
  Behavior1/5

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

  With no annotations available, the description carries the full burden of behavioral disclosure. It only restates the binary solo/unsolo behavior without explaining side effects on other tracks, the meaning of solo in this DAW, or what happens to the unit's previous state. No added value beyond the schema.

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

  Conciseness2/5

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

  At six words, the description is extremely concise but under-specified. It omits necessary context, making this a lack of information rather than an efficiently crafted description.

  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?

  Even though the tool has only two parameters and an output schema, the description fails to provide essential context about the target unit, how to identify it, or the effect of solo on the overall mix. It is barely sufficient for a simple setter.

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

  Parameters2/5

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

  The schema has 0% coverage, but the description does not meaningfully explain the parameters. It implicitly maps solo=true to solo and solo=false to unsolo, but says nothing about what unit_index refers to or how to obtain a valid index. Minimal compensation for the low schema coverage.

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

  Purpose3/5

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

  The description states a clear action (solo/unsolo) but refers to an 'audio unit' rather than a track, which is ambiguous given the tool name contains 'track'. It distinguishes from sibling set_track_* tools by the solo/unsolo action, but the resource is not clearly defined.

  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 on when to use this tool, what prerequisites exist, or how it relates to alternatives like set_track_mute or create_solo. The description gives no contextual entry points.

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

• mcp_opendaw_set_track_muteC
  2.7/5.0
  Behavior2/5

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

  There are no annotations provided, so the description carries the full burden. It only states the action without disclosing side effects, whether the operation is destructive, how it affects playback, or any permissions required. The boolean parameter implies 'set to state' rather than toggle, but that is not explicitly stated.

  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, concise sentence with no wasted words. It is front-loaded with the verb. However, it may be too minimal, sacrificing necessary detail for brevity, but the structure is clean.

  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 the simple parameter set and presence of an output schema, the description should still explain how to identify the target audio unit via unit_index. The ambiguity between 'track' in the name and 'audio unit' in the description is unresolved. The description is too sparse for a tool that directly mutates an audio element.

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

  Parameters2/5

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

  Schema description coverage is 0%, and the description does not compensate. 'Mute' implies a boolean value, but 'unit_index' is left undefined—no explanation of what a unit is, how indices are numbered, or how to discover valid indices. The description adds almost no value beyond the schema's bare parameter names.

  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 ('Mute or unmute') and the target ('an audio unit'). It is a specific verb+resource pairing that distinguishes it from sibling tools like set_region_mute or set_clip_mute. However, the tool name says 'track' while the description says 'audio unit,' which could cause minor ambiguity.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention when muting a track is appropriate, how it relates to solo, or any prerequisites such as needing the track to exist.

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

• mcp_opendaw_set_effect_parameterB
  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 carries the full burden. It reveals that the tool mutates an effect parameter and mentions numeric vs string handling, but the string special case is contradictory ('pass the string as parameter_name=value pair' vs example using 0), and it omits side effects, validation, and error behavior.

  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 compact and starts with a clear purpose, but the repeated and confusing string-parameter guidance wastes words and undermines clarity. Examples are helpful, but the 'Use string_value for equation' comment adds confusion rather than value.

  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?

  The presence of an output schema covers return values, but the description is not complete enough for an agent to safely invoke this tool among its typed siblings. It lacks clear preconditions (effect must exist, parameter must be numeric), and the contradictory string guidance could lead to incorrect calls.

  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?

  All four parameters are explained, compensating for the 0% schema coverage, with useful examples. However, the description of the 'value' parameter is internally inconsistent: it says strings can be passed for params like 'equation', but the schema defines value as a number and the example passes 0, so the actual semantics are unclear.

  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 first sentence clearly states an action ('Set') and a target ('parameter on an audio effect'), and the parameter descriptions further define the resource. However, it does not distinguish this generic setter from sibling typed setters (mcp_opendaw_set_effect_parameter_bool/int/string), nor explain when to prefer this one.

  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 useful context: parameter_name should come from mcp_opendaw_list_effect_parameters, and it gives concrete examples. It does not explicitly state when to use this tool versus the dedicated bool/int/string setters, and the 'string params' guidance is ambiguous.

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

• mcp_opendaw_set_positionB
  3.1/5.0
  Behavior2/5

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

  There are no annotations to rely on, so the description carries the full burden of behavioral disclosure. It mentions the unit 'beats' but does not disclose side effects, such as whether playback is halted, what happens if the position is invalid, or any required engine 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?

  The description is a single, focused sentence that conveys the essential action and unit. Every word is necessary, and there is no wasted text.

  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?

  Given the tool's simplicity (one parameter) and the presence of an output schema, the description is minimally adequate. However, for a mutation tool with no annotations, it lacks context about playback state, preconditions, or potential side effects beyond the basic action.

  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?

  With schema description coverage at 0%, the description must explain the parameter. It adds the meaningful detail that the value is in beats, but it does not specify range, absolute vs. relative, or whether fractional beats are allowed. It partially compensates for the schema's lack of information.

  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 sets the playback position and specifies the unit (beats). It is a specific verb+resource combination that is distinct from sibling tools like set_region_position or set_marker_position, though it does not explicitly differentiate itself.

  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 on when to use this tool versus alternatives, nor are there any prerequisites or context given. The description only states what the tool does without any usage direction.

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

• mcp_opendaw_set_region_durationB
  3.1/5.0
  Behavior2/5

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

  There are no annotations provided, so the description carries full responsibility for behavioral disclosure. It merely states the core effect and gives a format example for duration_beats. It does not explain validation, side effects (e.g., whether the region is resized or content is stretched), constraints (e.g., positive values only), or how region/track indices are resolved. Additionally, the example uses '4.0' which conflicts with the schema's integer type for duration_beats, creating slight 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?

  The description is extremely concise: a single action sentence plus a focused parameter note. Both sentences earn their place and there is no wasted verbosity. The front-loaded verb 'Set' immediately communicates the operation, and the example adds practical value without unnecessary length.

  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 that the tool has four parameters, no annotations, and a single-sentence description, it lacks critical context. The agent is not told how regions are identified (by index relative to track/unit), what constraints apply to duration, or what the operation returns. While an output schema exists, the input side is severely under-specified, making this incomplete for reliable use.

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

  Parameters2/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 all parameters. It only explains duration_beats (format and example) but omits any explanation of track_index, region_index, and unit_index. These are left to be inferred from their names, which is insufficient for error-free invocation, especially since unit_index is optional with a default but not described.

  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's action: 'Set the duration of a region.' This is a specific verb+resource pairing that immediately distinguishes it from sibling tools like set_region_position or set_region_mute. The addition of the duration_beats example reinforces the 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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or any caveats (e.g., whether it applies to audio/MIDI regions, or how it interacts with other region settings). The only context is the action itself, leaving the agent to infer usage from the name.

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

• mcp_opendaw_create_audio_trackB
  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 only states the action and location, omitting side effects such as whether the new track becomes the active track, whether it affects existing tracks, or what 'primary audio unit' implies. Minimal behavioral context 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?

  A single concise sentence that states the action, resource, and target location. No filler or redundant wording. It is appropriately sized for a tool with no parameters.

  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?

  Given an output schema and no parameters, the description covers the essential action. However, it does not explain the ambiguous 'primary audio unit,' and among many similar track-creation tools, additional context about what constitutes an audio track versus other track types would improve completeness. It is minimally adequate but not rich.

  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 zero parameters, the schema already fully covers parameter expectations. The description correctly avoids inventing parameters. The baseline for zero params is 4, and nothing in the description contradicts or adds unnecessary detail.

  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 and resource: 'Create a new audio track' and specifies 'on the primary audio unit.' This clearly distinguishes it from sibling tools like create_synth_track, create_note_track, and create_instrument_track, though it does not explicitly name alternatives.

  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 the many other create_*_track siblings. The description doesn't explain what an 'audio track' is in this context or when it should be preferred over creating a synth, instrument, or note track.

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

• mcp_opendaw_create_four_on_floorB
  3.2/5.0
  Behavior3/5

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

  The description discloses the rhythmic details, velocity offsets, and the return value ('Returns notes created, floor type, and stroke breakdown'), providing some behavioral insight. However, it doesn't mention side effects like overwriting existing notes, whether it creates a new region, or how track_index/unit_index affect the project, which is uncertain given no annotations.

  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 verbose, including a lengthy historical narrative on dance music that is not essential for tool invocation. While it's organized with clear sections for floor types and parameters, the extra context makes it less concise than necessary, though still readable.

  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 tool has 11 parameters and no schema descriptions, so the description bears the full burden of explanation. It thoroughly covers the main pattern generation and pitch defaults, but omits three parameters and doesn't discuss side-effect behavior or track prerequisites, leaving gaps for a complete understanding.

  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 description adds substantial meaning beyond the schema, especially for floor_type with detailed subgenre patterns, and for pitches and velocity with specific MIDI numbers and offset values. However, start_beat, unit_index, and track_index are not described in the text despite having zero schema descriptions, leaving these parameters underdocumented.

  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 creates a four-on-the-floor pattern and elaborates on specific floor_type options, making its purpose explicit and unique to this genre. However, it doesn't directly differentiate itself from sibling pattern-generation tools like create_drum_pattern, so it 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 Guidelines2/5

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

  The description provides examples of how to call the function and explains different floor_type choices, but it does not state when to use this tool versus alternatives such as create_drum_fill or create_euclidean_rhythm. The historical context is interesting but not actionable decision guidance.

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

• mcp_opendaw_delete_audio_regionB
  3.2/5.0
  Behavior2/5

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

  The annotation already declares destructiveHint=true, so the destructive nature is known. The description adds no further behavioral context—it does not disclose whether the deletion is permanent, whether it shifts subsequent region indices, whether undo is possible, or what side effects may occur. It only reiterates the deletion 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 concise and well-structured: a one-line action statement followed by a bulleted parameter list. Every sentence serves a purpose, with no fluff or extraneous detail. It is easy to scan and front-loads the core purpose.

  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 tool is simple, has an output schema, and parameters are documented. However, it lacks important contextual guidance, such as how to determine valid unit/track/region indices and the potential index-shifting effect of deletion. Given the availability of sibling list tools, this missing information could lead to incorrect usage.

  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 schema description coverage at 0%, the description fully compensates by explaining each parameter: unit_index as 'Audio unit index', track_index as 'Audio track index within the AU (type=2)', and region_index as 'Region index to delete (0-based)'. This adds meaningful context beyond the bare schema names and helps an agent understand indexing conventions.

  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: 'Delete an audio region from the timeline.' This is a specific verb+resource with scope ('audio region' and 'timeline'), distinguishing it from note region deletion. However, it does not explicitly differentiate itself from sibling tools like delete_region or delete_note_region, so it falls 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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention how to obtain valid indices (e.g., via list_audio_regions), nor does it advise against using it for other region types. There is no when-to-use or when-not-to-use context.

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

• mcp_opendaw_set_effect_enabledB
  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 burden of explaining side effects. It states the basic toggle behavior (enable/bypass) but omits details such as reversibility, impact on sound, error handling, or whether it triggers any processing changes. This is a significant 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 compact and front-loaded with the purpose, followed by a clear parameter list. Every sentence provides necessary information with no fluff or redundancy. The typo 'an specific' is minor.

  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 toggle tool, the description covers the essential action and parameters. However, it lacks contextual information such as how to obtain valid indices (e.g., via list_effects or get_effect_chain), and the absence of a zero/one-based indexing note creates ambiguity. Since an output schema exists, return values need not be described, but usage context is incomplete.

  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 description adds clear meaning to all three parameters beyond the schema's bare titles, explaining unit_index as 'Audio unit index', effect_index as 'Effect position in the chain', and enabled as 'true to enable, false to bypass'. However, it does not clarify integer base (0-based vs 1-based) or value ranges, which could lead to incorrect invocations.

  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 'Enable or bypass an effect on an audio unit' with a specific verb and resource. It is self-explanatory but does not explicitly differentiate from sibling tools like set_effect_parameter or remove_effect, so it falls short of full sibling distinction.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It only defines parameters and does not mention prerequisites (e.g., obtaining valid unit_index/effect_index from list_effects) or exclusions for other effect-modification tools.

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

• mcp_opendaw_create_trap_rollsB
  3.3/5.0
  Behavior2/5

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

  The description discloses return values and velocity offsets, but does not state whether notes are appended or replace existing notes, nor does it explain track_index, start_beat, or unit_index behavior. With no annotations, these operational details are missing, making the tool's DAW side effects unclear.

  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 thorough and logically structured (purpose, roll types, parameters, return, example), but is longer than necessary with cultural references and song examples. It is front-loaded with the core action, so it remains readable.

  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 a 9-parameter tool with no schema descriptions and no annotations, the description covers the musical style thoroughly but leaves out operational essentials (track targeting, start position, unit context). The presence of an output schema is mentioned but its structure isn't described, so the agent still lacks full invocation clarity.

  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?

  The description adds deep meaning for roll_type (five styles with rhythmic breakdowns), plus pitch and velocity semantics. However, three parameters (start_beat, unit_index, track_index) are entirely unexplained in the description, leaving critical placement information to the schema, which also lacks 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 opens with 'Create trap hi-hat roll patterns' and provides detailed variants (modern, migos, bubble, skrrt, evolving), clearly distinguishing this from generic drum tools. It specifies the resource (trap hi-hat rolls) and the verb (create), 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?

  The description implies usage for trap production with specific style examples, but does not explicitly contrast with sibling tools like create_drum_pattern or create_trap_arrangement. It gives within-tool guidance for choosing roll_type, but no when-to-use vs alternatives.

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

• mcp_opendaw_serializeB
  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 carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, whether it has side effects, performance implications, or any details about the JSON format beyond the name. The description is too sparse to inform the agent about important behavioral traits.

  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 two short sentences and front-loads the purpose. There is slight redundancy between 'Serialize' and 'serialized project data,' but overall it is efficient and free of unnecessary detail.

  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 tool is simple with no parameters and an output schema exists, which covers return value details. However, the description does not mention that this is a non-destructive operation, nor does it differentiate from similar state-querying siblings. It is adequate but has clear 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 input schema has zero parameters, so there is nothing to explain. Per the baseline guideline for 0-param tools, a score of 4 is appropriate. The description adds no parameter information, but none is needed.

  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 ('Serialize the current project state to JSON') and the return value ('Returns the serialized project data'). It includes a specific verb and resource. However, it does not explicitly differentiate from sibling tools like get_project_state or get_full_project_state, so it is not a perfect 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?

  The description implies usage ('when you need to serialize the project state') but provides no explicit guidance on when to use this tool over alternatives or any exclusions. It does not mention any prerequisites or contexts. This is minimal viable implied usage.

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

• mcp_opendaw_create_audio_busB
  3.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. It discloses internal behavior: creates AudioUnitBox, AudioBusBox, TrackBox, wires them together, and returns the new bus index. The implementation caveat about separate editing.modify() blocks and pointer refer() failure is useful, but it doesn't mention permissions, reversibility, or potential 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 compact and front-loaded with the core purpose. The implementation detail and parameter definition each add value, and there is no redundant filler. The structure clearly separates purpose, technical caveat, parameter, and return 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 one-parameter creation tool with an output schema present, the description provides enough context: what it creates, how it wires internal objects, what the name parameter means, and what it returns. It lacks comparison to sibling bus/send tools, but given the simple scope this is sufficient.

  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 has one parameter (name) with no description, and the description explicitly says 'name: Bus label.' This adds meaning beyond the schema. It also clarifies the return value, which helps the agent understand the result. No constraints or format details are given, but for a single simple parameter the coverage 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?

  States a specific action: 'Create a new audio bus (aux bus) with its own audio unit and track.' This clearly identifies the verb and resource, and the added detail about audio unit/track wiring gives concrete scope. It doesn't explicitly name sibling tools to distinguish from, but the core purpose is unmistakable.

  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 like create_send, list_audio_buses, or create_audio_track. The description provides no exclusions, prerequisites, or recommended use cases. It simply states what the tool does rather than when to invoke it.

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

• mcp_opendaw_create_call_and_responseB
  3.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 burden. It discloses a key side effect (creates call on track_index and response on track_index+1) and explains response generation behavior via response types. However, it does not state whether existing notes are overwritten, if tracks must exist, or other side effects, leaving uncertainty.

  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 well-structured with an intro, context paragraph, bulleted response types, and parameter explanations. It is longer than necessary but every section contributes useful information. The opening sentence front-loads the purpose.

  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?

  Given the tool's complexity (12 parameters, 5 response types), the description covers core concepts and several parameters but omits key parameters and preconditions. Output schema exists, so return values are not needed, but the description still leaves gaps in usage understanding.

  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?

  The schema has 0% description coverage, so the description must explain parameters. It explains call_pattern, call_rhythm, response_interval, pairs, gap_beats, and response_type with examples. However, it omits key_root, scale_name, velocity, start_beat, and unit_index, leaving about half the parameters without semantic context.

  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 creates a call-and-response pattern with specific verb and resource. It explains the musical concept and response types, making the purpose unambiguous. However, it does not differentiate from the closely named sibling mcp_opendaw_create_call_response, which seems functionally similar.

  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 in genres like blues, gospel, jazz, African music, work songs, and hip-hop by citing these traditions, but it does not explicitly state when to use this tool vs alternatives or provide exclusions. It gives context but no direct guidance.

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

• mcp_opendaw_create_chord_padsB
  3.4/5.0
  Behavior3/5

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

  The description discloses a lot: generates sustained pads, configurable parameters, supported chord types, defaults, and return values. However, the internal contradiction (says this tool uses strings, then shows examples calling the JSON-array tool with strings) reduces trust in the behavioral description. Without annotations, this inconsistency is a notable 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.

  Conciseness3/5

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

  The description is well-structured but overly long, with three examples that mostly repeat the same progression format. The most critical flaw is that every example uses the wrong tool name (create_chord_progression), which is misleading and should have been caught. The verbosity is partially justified by the need to document chord syntax and defaults, but the errors make it less concise in practice.

  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 chord syntax, defaults, return values, and provides genre context. However, the pervasive use of create_chord_progression in examples makes the invocation details incorrect, so an agent cannot rely on the examples. It also lacks explicit prerequisites (e.g., must have a note track at track_index) and doesn't clarify whether existing notes are overwritten. The output schema exists but the description's inaccuracies prevent 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 description explains nearly all 8 parameters in detail: progression format and supported chord types, bars_per_chord, octave, velocity, note_duration, and some context for unit_index and track_index. start_beat is only minimally described as 'where the progression starts' without specifying units. Given 0% schema coverage, this compensation is strong but not perfect.

  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 sentence clearly defines the tool as creating chord pads from a human-readable string, and it distinguishes itself from create_chord_progression by string vs JSON arrays. However, all usage examples call create_chord_progression instead of the actual tool name, which creates significant confusion about which tool does what.

  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 explicitly contrasts with create_chord_progression and provides genre-specific progression examples, which is helpful. But the examples incorrectly invoke create_chord_progression, undermining the guidance and potentially causing an agent to call the wrong sibling tool. The distinction between string and JSON is clear, but the execution is flawed.

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

• mcp_opendaw_create_downtempo_arrangementB
  3.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 burden for behavioral disclosure. It transparently details the 5 tracks created and their musical patterns, plus defaults for BPM and key. However, it doesn't state whether the tool mutates the existing project, overwrites tracks, requires prior setup, or how it interacts with existing content. It also omits behavior around parameters like start_beat and unit_index, leaving gaps in the side-effect description.

  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 front-loaded with a clear purpose statement, but it then spends several lines on the historical origins of trip-hop in Bristol and a genre characteristics list that, while musically informative, is not essential for invoking the tool. Overall, it is longer than necessary but well-structured with paragraphs and track enumeration.

  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 presence of an output schema reduces the need to explain return values. The description provides a rich musical brief (tracks, patterns, key, BPM) and clearly summarizes the creative result. However, critical operational details are missing: parameter semantics for several parameters, explicit use cases, and non-destructive behavior. The tool is complex enough that these gaps make the description only partially complete for an agent to select and invoke it with confidence.

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

  Parameters2/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 parameter explanation. It explicitly mentions bpm and key_root (defaults) and uses track_index to define track numbering, but provides no explanation for bars, velocity, start_beat, or unit_index. This leaves 4 of 7 parameters entirely undocumented, which is insufficient for a tool with zero 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 opening sentence, 'Create a downtempo/trip-hop arrangement — 85 BPM Bristol sound,' uses a specific verb and resource, immediately identifying the tool's function. It clearly distinguishes this from sibling genre-arrangement tools (e.g., create_afrobeat_arrangement, create_lofi_arrangement) by naming the genre and key characteristics.

  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 for downtempo/trip-hop creation through detailed genre characteristics and track breakdown, but it never explicitly states when to use this tool over alternatives, nor does it offer exclusions or refer to other tools. No when-to-use guidance is provided beyond the genre itself.

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

• mcp_opendaw_create_hardstyle_arrangementB
  3.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 burden of behavioral disclosure. It reveals that four tracks are created with specific patterns and default key, but omits operational details such as overwrite behavior, track placement conflicts, return values, or required project state.

  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 well-structured with a clear lead sentence, followed by genre context and a bulleted track breakdown. The genre education paragraph is somewhat extended, but the overall organization aids readability without excessive redundancy.

  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 a 7-parameter tool with no annotations and no output schema details, the description is incomplete. It explains the musical arrangement thoroughly but does not cover parameter semantics, side effects, prerequisites, or return behavior, leaving significant gaps for an AI agent.

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

  Parameters2/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 only indirectly references track_index and mentions musical traits like 150 BPM and F minor, but fails to explain parameters such as bars, velocity, start_beat, unit_index, or how bpm/key_root map to the described output.

  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 "Create a hardstyle arrangement" with a specific verb and resource. It further distinguishes itself from sibling genre tools by detailing the hardstyle characteristics, BPM, and track structure, making its 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?

  The description implies usage for hardstyle creation but lacks explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like other genre arrangements, leaving the selection rationale to the genre context alone.

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

• mcp_opendaw_create_konokolB
  3.4/5.0
  Behavior4/5

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

  There are no annotations, so the description carries full disclosure burden. It discloses the GM note mapping (36, 38, 42, 43, 45), the fact that notes are placed on track_index, and that syllable text is included in the result. It does not reveal whether notes are appended or overwritten, or how start_beat/unit_index behave, leaving some 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.

  Conciseness4/5

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

  The description uses a clear header plus bulleted sections for styles and mapping. While relatively long, the material is relevant and organized, and the opening line front-loads the purpose. No repetition of schema field titles 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?

  Given the complexity (7 parameters, no annotations, but output schema exists), the description covers the domain thoroughly but leaves operational questions open: the meaning of unit_index, how start_beat is interpreted, whether cycles is a repeat count, and what the output schema contains beyond syllable text. It is valuable but not fully complete.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description is responsible for parameter semantics. It thoroughly documents the 'style' parameter by listing all valid values and their structures, and it mentions 'track_index' as the target track. However, 'cycles', 'velocity', 'tempo_bpm', 'start_beat', and 'unit_index' are left undefined, leaving most parameters ambiguous for an agent.

  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 'Create Indian Carnatic konokol (solkattu) — vocal percussion as MIDI' and later states 'Creates konokol notes on track_index', clearly identifying the verb and resource. It does not explicitly compare to sibling tools like create_tala, but the highly specific musical terminology and style list make the tool's unique 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 Guidelines3/5

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

  No explicit when-to-use or alternatives are stated; however, the detailed explanation of konokol, tala structures, and the phrase 'This is the rhythmic foundation of all Carnatic music' imply the intended context. It lacks an explicit 'use when...' and does not distinguish from the many sibling creation tools like create_tala or create_drum_pattern.

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

• mcp_opendaw_create_liquid_dnb_arrangementB
  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 must disclose behavioral traits. It states that it creates a full arrangement across 4 tracks but does not clarify whether existing content on those tracks is overwritten, whether an empty project is required, or whether there are side effects. Parameters like unit_index and start_beat hint at placement but aren't explained, leaving critical operational information missing.

  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 well-structured with clear sections: purpose, style explanation, track breakdown, parameter list, and examples. It is a bit long but each section contributes useful context. The bullet-list format aids scanning, and the examples demonstrate typical usage. No redundant or filler content is present.

  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 the tool's complexity (11 parameters, no schema descriptions, no annotations), the description is incomplete. It covers the musical intent and core parameters but omits functional parameters (track routing, start_beat, unit_index) and behavioral details. While an output schema exists so return values aren't needed, operational prerequisites and parameter semantics remain under-explained.

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

  Parameters2/5

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

  The description explains bpm, bars, root, octave, and velocity with ranges and defaults, which adds value over the bare schema. However, six parameters (pad_track, bass_track, drum_track, start_beat, unit_index, melody_track) are not explained at all, and schema_description_coverage is 0%. The track descriptions imply a mapping to these but do not explicitly connect them, leaving a significant gap for the agent.

  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: 'Create a full liquid drum & bass arrangement across 4 tracks.' It clearly distinguishes from sibling genre arrangement tools by specifying the liquid DnB subgenre and detailing each track's role (smooth breakbeat, melodic sub-bass, lush extended chords, jazz-influenced lead). References to artists (LTJ Bukem, Calibre) further anchor the style.

  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 context by contrasting liquid DnB with standard DnB ('Instead of Reese bass and Amen breakbeat fury...') and lists track-specific attributes. This strongly implies when to use this tool versus other genre arrangement tools. However, it does not explicitly name alternative tools or state when not to use it, so the guidance remains implicit rather than direct.

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

• mcp_opendaw_delete_note_regionB
  3.4/5.0
  Behavior2/5

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

  The annotation destructiveHint=true already signals destructive behavior. The description adds minimal behavioral context; it mentions 'from the timeline' but does not specify whether the deletion is permanent, whether it affects contained notes, or any side effects. It does not contradict annotations but provides little beyond them.

  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 sentence for the action and three concise parameter lines. No filler or redundant information. It's front-loaded with the primary purpose.

  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?

  With an output schema present and annotations covering destructive intent, the description provides the essential parameter details. However, it lacks usage guidance and behavioral nuancing such as undoability or effects on dependent regions, leaving some gaps for an agent in a complex DAW 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% and no parameter descriptions exist in the schema. The description compensates by explaining all three parameters: unit_index with '-1 = search all AUs', track_index as within the AU, and region_index as 0-based. This fully covers the semantics for an agent.

  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 'Delete a note region from the timeline' with a clear verb and resource. It identifies the target as a note region, distinguishing it from audio regions, but it doesn't explicitly differentiate it from sibling tools like delete_region or delete_audio_region, so it 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 Guidelines2/5

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

  No when-to-use or alternative guidance is provided. The description only defines the operation and parameters, with no context on when to choose this over other delete tools (e.g., delete_region, delete_audio_region) or any prerequisites.

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

• mcp_opendaw_export_stems_formatB
  3.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 full burden of behavior disclosure. It explains the internal pipeline (export_stems then ffmpeg), which is useful, but omits important behavioral details such as potential file overwriting, the requirement for ffmpeg to be installed, and failure modes. This is partial transparency.

  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 about 60 words and contains redundancy—the first sentence and the final sentence both describe the same conversion step. The structure is a bit disjointed, and the inconsistency about wav support could confuse. It earns a mid-range score for being clear but not polished.

  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?

  An output schema exists, so return values are covered, but the description misses important context such as when to use this tool versus the many export-like siblings (export_stems, export_mix, render_full_format), prerequisites like ffmpeg, and where output files are written. The tool's simplicity is balanced by the need for differentiation in a crowded toolset.

  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 0% description coverage, so the description compensates by explaining each parameter, including allowed values for format and the default for bitrate. It adds meaning beyond the schema, though it could specify sample_rate units or valid bitrate patterns. For these simple parameters, the descriptions are sufficient.

  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 (export stems and convert format) and lists the supported formats, distinguishing it from the plain export_stems sibling by mentioning conversion. However, the first sentence says 'MP3 or FLAC' while the schema lists 'wav' as default, creating minor ambiguity about the exact purpose.

  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 discloses that this tool runs export_stems then converts via ffmpeg, implying it is a wrapper for format conversion. However, it never explicitly states when to choose this tool over alternatives like export_stems or export_mix, leaving usage context to be inferred rather than clearly defined.

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

• mcp_opendaw_get_effect_chainB
  3.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates this is a read-only operation. The description adds that it returns an 'ordered list of effects with their type, enabled state, and index,' which gives some behavioral detail beyond the annotation. However, it does not address error cases or invalid indices, so it is modest.

  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, with three short sentences covering purpose, parameter, and return value. It is front-loaded with the main action and contains no unnecessary 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 simple read-only getter with one integer parameter, the description covers the essential purpose, parameter meaning, and return contents. An output schema exists, so the return structure is formally defined. It does not cover edge cases, but that is likely 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.

  Parameters3/5

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

  The input schema has one parameter, unit_index, with only a title 'Unit Index' and no description. The tool description adds 'unit_index: Audio unit index,' which provides minimal clarification that it is the index of the audio unit. However, it is largely redundant with the schema and does not specify indexing base or constraints.

  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 'Get the full effect chain for an audio unit' with a specific verb and resource, and elaborates on the return value ('ordered list of effects with their type, enabled state, and index'). It is not a tautology, but it does not explicitly distinguish from sibling tools like list_effects or get_effect_state, so it is clear but lacks explicit 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 provided on when to use this tool versus alternatives. There are no exclusions, prerequisites, or mentions of sibling tools. The intended usage is only implied by the tool name and description, which is minimal.

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

• mcp_opendaw_get_project_stateB
  3.4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the read-only nature is transparent. The description adds value by specifying the returned data categories, but it does not discuss potential costs (e.g., large payload) or how the state snapshot is taken, which would be useful for a 'full state' 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. It uses a clear verb ('Get'), specifies the resource ('full project state'), and lists concrete elements without any fluff or redundant wording.

  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 adequate for a simple state retrieval tool, and the existence of an output schema reduces the need to explain return values. However, the lack of differentiation from the similarly named sibling 'get_full_project_state' and the absence of usage context leave notable gaps in 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 is empty (zero parameters), and schema description coverage is 100%. The description has no parameter burden, and none of the listed contents require parameter explanation. Baseline for zero params is 4.

  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 retrieves full project state and enumerates key contents (BPM, sample rate, playing status, track list, effects chain). However, a sibling tool named 'get_full_project_state' exists, and the description does not distinguish this tool from that one, which could cause confusion.

  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 on when to use this tool versus alternatives like get_project_info, get_mixer_state, or get_full_project_state. The description simply describes the action without any contextual or exclusionary guidance.

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

• mcp_opendaw_load_effect_presetB
  3.4/5.0
  Behavior2/5

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

  With no annotations provided, the description must carry the full burden of behavioral disclosure. It does mention the internal process (reads, decodes via PresetDecoder, inserts) and the -1 default behavior, but it does not disclose whether the operation is destructive (e.g., replaces the entire effect chain), whether it can be undone, or what happens on invalid file paths. This is a significant gap for a mutating operation on the DAW.

  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 concise, at about four sentences, and front-loads the main purpose. It organizes information logically: purpose, internal behavior, and parameter definitions. Slight redundancy exists between the first and second sentences (both describe loading and applying), but overall every sentence adds useful 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 tool with two parameters and an output schema, the description covers the essential context: the file format, the target audio unit, and the special -1 case. It does not mention whether the operation overwrites existing effects or the exact effect chain insertion behavior, but the presence of an output schema means return values need not be explained. It is reasonably complete for the tool's complexity, though a note on usage relative to sibling preset tools would elevate 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 provides only titles ('Filepath', 'Unit Index') with no descriptions (0% schema coverage). The description compensates well by explicitly defining filepath as the path to the .opb preset bundle and unit_index as the target audio unit index, including the important -1 sentinel meaning. This gives clear semantic meaning beyond the schema, though it could note constraints like file existence or valid index ranges.

  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 loads a .opb preset file and applies it to an audio unit, which is specific and action-oriented. It even notes internal mechanics (PresetDecoder) and the special -1 behavior, making it distinct from simple 'load' operations. However, it does not explicitly distinguish itself from sibling tools like import_preset or replace_from_preset, so it falls 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?

  The description implies the tool is used when you need to load a preset bundle onto an audio unit, providing clear context for its primary use. It does not mention when to use this over alternatives like import_preset, nor does it state any exclusions or prerequisites (e.g., required audio unit existence). This is implied usage, not explicit guidance.

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

• mcp_opendaw_set_track_panningB
  3.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 burden of behavioral disclosure. It adds the panning range (-1.0 to 1.0) which clarifies valid inputs, but it does not disclose side effects, error handling, or the effect of invalid unit indices. This is minimal useful 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 a single sentence with a clear value mapping. It is front-loaded and contains zero 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 simple setter operation, the description covers the essential behavior and value constraints. The output schema exists, so return values need not be described. It lacks minor context about the unit_index parameter, but overall is sufficient for a tool of this complexity.

  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 coverage is 0%, so the description must compensate. It fully explains the 'panning' parameter's scale and endpoints, but the 'unit_index' parameter is left entirely unexplained. This partial coverage is helpful but incomplete for a two-parameter 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 clearly states the tool sets panning on an audio unit and specifies the value range. It distinguishes itself from volume or send operations, though it does not explicitly contrast with sibling tools like set_send_pan or set_stereo_tool_panning.

  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. There is no mention of prerequisites, conditions, or when not to use it, leaving the agent to infer based on the name alone.

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

• mcp_opendaw_undoB
  3.4/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 only states the action without mentioning side effects, whether it's single-level or multi-level undo, what happens if there is nothing to undo, or any irreversible 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 a single, short sentence that immediately states the action, with no filler or redundant context. It is concise and 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 zero-parameter tool, the description covers the core action, and the presence of an output schema means return values needn't be explained. However, it lacks details about the scope of undoable operations and error behavior, leaving some gaps for a tool in a large DAW 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 input schema fully covers parameter semantics. The description adds no parameter information, but with no parameters, the baseline is 4, and nothing is missing.

  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 'undo' and identifies the resource as 'the last editing operation', which clearly conveys the tool's purpose. It is distinct from siblings like mcp_opendaw_redo, though it doesn't elaborate on what counts as an 'editing 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?

  The description implies use when you want to revert the most recent editing action, but provides no explicit guidance on when not to use it, such as in scenarios where the last operation wasn't an 'editing' one, or how it relates to the redo tool as an alternative.

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

• mcp_opendaw_create_ambient_arrangementA
  3.5/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 transparency burden. It richly describes what will be created (4 tracks with specific roles, lengths, and harmonic content), but does not disclose potential side effects such as overwriting existing tracks or how it interacts with existing 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.

  Conciseness4/5

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

  The description is well-structured with a summary up front followed by bullet points, but it includes extraneous artist references and lengthy stylistic background that could be trimmed. It is front-loaded and organized, though longer than necessary.

  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?

  Given the tool's complexity (7 parameters, 4-track generation) and the lack of annotations, the description is thorough about musical characteristics and defaults, but it omits operational behaviors (e.g., what happens with existing tracks, handling of unit_index) and does not differentiate from sibling tools beyond the genre name.

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

  Parameters2/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 explicitly mentions bpm, bars, key_root, and track_index, but does not explain start_beat, velocity, or unit_index. It adds meaning for some parameters but leaves others undocumented.

  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 'Create an ambient arrangement — 70 BPM atmospheric soundscape,' using a specific verb and resource. It further details the four tracks and musical characteristics, clearly distinguishing it from other genre arrangement 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 an ambient, atmospheric soundscape is desired and provides musical context, but it does not explicitly mention when not to use it or recommend alternatives. With many sibling arrangement tools, the lack of explicit differentiation guidance is a gap.

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

• mcp_opendaw_create_gospel_arrangementA
  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 must disclose side effects. It says 'Create a full gospel arrangement' but doesn't state whether this adds new tracks, replaces existing content, or requires a specific project state. The operational behavior (mutating the project) is left implicit, which is a significant gap 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.

  Conciseness4/5

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

  The description is front-loaded with a clear purpose sentence, followed by structured bullet points for each track. While lengthy, the musical detail is relevant and not redundant. It could trim the editorializing sentence ('Gospel music — the foundation...') but overall earns its length.

  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 a complex 11-parameter creation tool with no annotations and no schema descriptions, the description covers the musical content thoroughly but is incomplete operationally. It doesn't mention project-level effects (additive vs. destructive), requirements, or what happens on invocation. The output schema exists, but the description still lacks integration guidance.

  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?

  The schema has 0% coverage, so the description must explain parameters. It does explain track 0-3 assignments (matching drum_track, bass_track, organ_track, choir_track defaults), mentions the default root Ab, and gives a tempo range (70-85 BPM) that relates to the bpm parameter. However, it doesn't explain bars, velocity, octave, start_beat, or unit_index, leaving many parameters underspecified.

  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 'Create a full gospel arrangement — shuffle drums + walking bass + Hammond organ + choir,' clearly stating the tool's function and distinguishing it from other arrangement tools. The detailed breakdown of tracks 0-3 further specifies what the arrangement includes.

  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 the tool—when a gospel arrangement is needed—and provides rich musical style details (default Ab, I-IV-V-I, tempo range). However, it doesn't explicitly exclude other styles or mention alternatives among the many sibling genre-arrangement tools, so it misses explicit when-not/alternative guidance.

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

• mcp_opendaw_create_warp_markerA
  3.5/5.0
  Behavior3/5

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

  The description discloses the core behavior (adds a marker, anchors first/last) and the return value (new marker count and added marker's position/seconds). However, with no annotations, it does not address potential side effects, ordering constraints, or prerequisites such as the region being stretched.

  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 with an opening statement, a short conceptual paragraph, a parameter list, and a return-value note. Every sentence contributes meaning, and the length is appropriate.

  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 tool is moderately complex with five parameters and no annotations, and the description covers the concept, parameters, and return value. It lacks details on preconditions, error cases, and how it relates to other marker tools, but the provided information is sufficient for basic usage.

  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?

  With 0% schema coverage, the description provides brief definitions for all five parameters, clarifying units (beats, seconds) and hierarchy (AU, track, region). While helpful, it does not explain how to obtain these indices or any valid range constraints.

  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 a clear action ('Add a warp marker') and specifies the resource type and context (time-stretched or pitch-stretched audio region). It explains the concept of warp markers, which helps distinguish from similar marker tools, though it doesn't explicitly contrast with 'add_marker' or other 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 description implies the tool is for stretched regions ('to a time-stretched or pitch-stretched audio region') and explains the marker's role, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like add_marker. This leaves the agent to infer the appropriate context.

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

• mcp_opendaw_get_track_infoA
  3.5/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint: true, so the safety profile is known. The description adds that it returns track metadata and region/clip counts, but does not disclose nuances like index validity or handling of hidden tracks. This modest addition is acceptable given the 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?

  Three concise sentences cover purpose, parameters, and return value. The description is front-loaded with the main purpose and contains no unnecessary 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?

  With an output schema present and a readOnly annotation, the description adequately covers parameter selection and return overview. Minor omissions like error handling or edge cases are not critical for a simple getter 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?

  Schema coverage is 0%, so the description must compensate. It does by explaining unit_index as AU index and track_index as track index within the AU, which is essential for correct invocation. It lacks depth like zero-based indexing but is sufficient for the 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 clearly states the tool retrieves detailed track information including type, regions, clips, enabled state, and target. It uses a specific verb and resource, but does not explicitly differentiate from sibling tools like list_tracks or get_region_info.

  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 on when to use this tool versus alternatives. It simply states what it does, without any exclusions or references to other track-related tools.

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

• mcp_opendaw_redoA
  3.5/5.0
  Behavior2/5

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

  No annotations are provided, leaving the description to carry the full burden of behavioral disclosure. The phrase 'Redo the last undone operation' states the action but does not disclose that this is a mutating operation, whether it can fail if no undone operation exists, or how it affects the redo stack. This is significant for a state-changing tool with no 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 a single, concise sentence that directly states the action. It is front-loaded and contains no filler or redundant information, earning the highest score for conciseness and structure.

  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 parameter-less tool with an output schema, the description is minimally adequate, but it lacks contextual details such as when redo is available (e.g., after an undo), what happens if the redo stack is empty, and any error behavior. Since the tool is simple, a score of 3 reflects that it is usable but has clear gaps in behavioral 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 and an empty input schema, so there are no parameter semantics to describe. The baseline score of 4 is appropriate since no parameter information is needed, and the description does not need to compensate for any schema gaps.

  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 'Redo the last undone operation.' uses a specific verb ('redo') and a clear resource ('last undone operation'), which precisely defines the tool's functionality. It also distinguishes this tool from its sibling mcp_opendaw_undo by explicitly stating it reverses an undo, 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 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 relative to undo or any other sibling. The description does not mention that redo is only applicable after an undo operation, nor does it provide any exclusions or alternative tool suggestions. Usage context is only implied by the tool's name and standard behavior.

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

• mcp_opendaw_set_bpmA
  3.5/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, but it only states the action and gives no detail about side effects (e.g., whether existing tempo automation is overridden), required permissions, or return behavior. There is no mention of what changes occur beyond setting a value.

  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 sentence, front-loaded with the action, with no unnecessary words or repetition of schema fields.

  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 setter with an output schema, the description is minimally adequate but leaves gaps about interactions with tempo automation and project state. It is complete on the basic action but not on behavioral consequences or alternative use 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?

  The description adds 'project tempo' and 'BPM' context to the single required parameter, clarifying that the integer 'bpm' value represents the tempo in beats per minute. Since schema description coverage is 0%, this compensation is valuable, though no range or allowed values are given.

  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 ('Set') and identifies the resource ('project tempo') with the unit ('BPM'), clearly distinguishing it from tempo-related siblings like add_tempo_change or get_tempo_at. It is a concise statement of the tool's primary 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 on when to use this tool versus alternatives such as mcp_opendaw_add_tempo_change, mcp_opendaw_list_tempo_changes, or mcp_opendaw_detect_bpm. The description implies only the basic use case and offers no exclusions or prerequisites.

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

• mcp_opendaw_set_clip_labelA
  3.5/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose behavior. It mentions 'Returns success with old and new label' but does not explain side effects, overwriting semantics, error conditions, or index conventions. The mutation side effect is implied by 'Set' but not detailed.

  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 one-sentence purpose, a terse parameter list, and a return note. No filler or redundant content.

  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 provides the essential purpose and parameters, and the output schema covers return values, so it is reasonably complete for a simple setter. However, it lacks guidance on how to resolve indexes or when this tool is appropriate among many similar clip/marker setters.

  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 each of the four parameters: unit_index, track_index, clip_index, and label, with brief but meaningful explanations that go beyond the bare schema property names.

  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: 'Set the label (name) of a clip in the session view', which is a specific verb+resource that differentiates it from sibling tools like set_region_label and set_marker_label.

  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 set_region_label or set_clip_properties. The description only gives the action and parameter list, with no mention of indices sourcing or alternative scenarios.

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

• mcp_opendaw_set_clip_muteA
  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 burden. It mentions the return value ('Returns success with old and new mute state') but does not disclose side effects, reversibility, permissions, or error behavior—only the obvious mute/unmute 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 well-structured: a one-line purpose, a parameter list, and a return-value note. Every sentence adds value with no redundant or filler content.

  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 setter tool, the description covers purpose, parameters, and return value. However, it lacks error handling, prerequisites, or any note about side effects, and with no annotations the agent gets no safety or behavioral context. The output schema exists but is not provided here, so the return note is useful; still, usage guidance gaps remain.

  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 fully compensates by explaining each parameter: 'unit_index: AU index', 'track_index: Track index within the AU', 'clip_index: Clip index', and 'mute: True to mute, false to unmute'. This provides meaningful semantic guidance beyond bare 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 'Mute or unmute a clip in the session view' with a specific verb and resource. It distinguishes itself from sibling tools like set_track_mute or set_region_mute by focusing on clips, and the parameter list reinforces the scope.

  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 on when to use this tool versus alternatives (e.g., track mute, region mute) or any exclusions. The description only states the operation and parameter meanings, leaving the agent without explicit context for tool selection.

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

• mcp_opendaw_set_note_propertiesA
  3.5/5.0
  Behavior2/5

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

  The statement 'Pass -1 for any parameter to skip changing it' is overbroad and misleading. Only the editable property parameters (position_beats, duration_beats, pitch, velocity, cent, chance) have explicit '-1 = skip' annotations, while unit_index has '-1 = search all AUs' (a different behavior) and track_index/region_index have no -1 behavior defined. This ambiguity could cause an agent to pass invalid -1 values for locator parameters. The tool also lacks disclosure of error handling or side effects beyond returning updated 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?

  The description is well-structured: a concise purpose sentence, a brief note about -1 skipping, followed by a clean bullet list of parameters with definitions. Every line adds value and there is no extraneous text. The most important usage hint (list_notes first) 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 tool with 10 required parameters and zero schema descriptions, the description covers purpose, prerequisite, and parameter ranges well. However, the ambiguity around -1 behavior for locator parameters and the absence of any guidance on finding unit/track/region indices (beyond list_notes) leaves gaps. The output schema likely covers return values, so that omission is acceptable, but the input semantics are not fully unambiguous.

  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?

  Each parameter has a one-line description with useful ranges (e.g., pitch 0-127, velocity 0-1, chance 0-100), which compensates for the 0% schema coverage. However, the -1 skip semantics are inconsistently applied across parameters: unit_index uses -1 for 'search all AUs' rather than skip, track_index and region_index have no -1 behavior stated, creating confusion about how to correctly set locator 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 opens with 'Edit properties of a single note within a region', which clearly specifies the verb and resource. It distinguishes itself from more specific note tools like set_note_cents by covering multiple properties, though it does not explicitly name alternative tools for comparison.

  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 clear prerequisite: 'Use list_notes first to find the note_index.' This tells the agent how to prepare for using the tool. It does not explicitly exclude alternatives or state when not to use it, but the context is sufficient for basic selection.

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

• mcp_opendaw_set_region_labelA
  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 only states the operation and parameter meanings, but does not disclose whether the operation is mutating, reversible, or has side effects. It does not describe error behavior or what happens when unit_index=-1 matches multiple regions.

  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 very concise: one purpose sentence followed by a compact parameter list. Each line adds necessary information and there is no fluff or repetition.

  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 setter, this is adequate but has gaps. It does not explain the AU/track/region hierarchy, the implications of 'search all AUs', or what happens on failure. Since no annotations exist and the description is minimal, the overall context is thin.

  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 adds meaning for all four parameters: label is the new text, unit_index can be -1 to search all AUs, track_index is within the AU, and region_index is 0-based. This goes beyond the bare schema titles, though it could include more detail on constraints or ranges.

  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 'Rename a region's label (display name)', which is a specific verb ('rename') and resource ('region's label'). It clearly distinguishes from sibling tools like set_clip_label, set_marker_label, and set_device_label by explicitly targeting the region entity.

  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?

  The description provides no guidance on when to use this tool versus alternatives. It does not mention conditions, prerequisites, or exclusions. There is no context that this is the appropriate tool for renaming a region's label rather than a clip or marker label.

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

• mcp_opendaw_transportA
  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 burden of behavioral disclosure. It simply lists action values without explaining side effects, prerequisites (e.g., whether the engine must be running), or what 'toggle' actually toggles between. This adds little beyond the action names.

  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 no filler or redundant statements. The two-line structure directly conveys the core functionality and parameter values.

  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 one-parameter tool, the description is minimally adequate but misses key context such as whether the engine must be started, the exact behavior of 'toggle,' or the effect on current playback. Given the lack of annotations and sparse schema, this could be more explicit.

  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 declares a required string 'action' with no enum or description. The description explicitly lists the allowed values ('play', 'stop', or 'toggle'), providing essential semantic information that 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 clearly identifies the tool's purpose: 'Control transport: play, stop, or toggle.' It names the specific resource (transport) and the distinct actions, which differentiates it from sibling tools like start_engine or set_position.

  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 on when to use this tool versus alternatives. The description does not mention related engine controls (e.g., start_engine, engine_panic) or any prerequisites, leaving the agent to infer usage from the word 'transport' alone.

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

• mcp_opendaw_add_effectA
  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 states the basic action and return value, but does not disclose preconditions (e.g., how to determine unit_index), side effects (e.g., effect chain order, default state), failure modes, or reversibility. For a mutation tool, this is insufficient.

  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 concise and front-loaded with the action. The effect_type list and return-value hint are useful, but there is minor redundancy in listing effect types after already naming the source tool. Overall, it is well-structured with no 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?

  The tool is simple and the description provides valid effect types and the return value, as well as a connection to parameter-setting tools. However, it omits guidance on how to obtain unit_index and any behavioral caveats. The presence of an output schema and the description's return-value mention reduce the need for further return details, but the unit_index gap keeps it from being complete.

  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 must compensate. It does thoroughly explain effect_type with a full list of valid values and a cross-reference to mcp_opendaw_list_effects. However, unit_index—a required integer—receives no explanation at all, leaving a critical gap for the agent.

  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 verb and resource: 'Add an audio effect to an audio unit's effect chain.' It distinguishes from related tools like mcp_opendaw_add_midi_effect by explicitly targeting audio effects. The enumeration of valid effect types further clarifies the exact scope of the tool.

  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 references mcp_opendaw_list_effects for obtaining valid effect_type values and mentions using the returned effect_index with mcp_opendaw_set_effect_parameter, implying a clear workflow. However, it does not explicitly state when not to use this tool (e.g., for MIDI effects) or mention alternative tools like mcp_opendaw_remove_effect.

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

• mcp_opendaw_create_edm_arrangementA
  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 full burden and does explain what will be created in detail (track patterns, synth types, musical defaults). However, it does not disclose side effects such as whether existing tracks are overwritten, whether new tracks are created, or whether the operation is reversible. This is a create action, so some risk disclosure would improve transparency.

  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 well-structured with a short opening, bulleted track breakdown, and a closing paragraph on key/BPM/progression. Every sentence conveys relevant musical detail, and the length is justified by the complexity of an 11-parameter arrangement tool.

  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 output schema covers return values, and the description provides a rich picture of the musical arrangement. Still, the description lacks explicit usage boundaries and some parameter semantics, making it not fully complete for an agent that needs to decide when and how to invoke this tool among many similar genre-arrangement tools.

  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?

  The description adds meaning to several parameters by mapping track numbers to instrument roles (Track 0 = drums, Track 1 = bass, Track 2 = synth, Track 3 = lead) and by explaining defaults like F minor and 128 BPM. However, with 0% schema description coverage, it leaves parameters like velocity, octave, bars, start_beat, and unit_index unexplained, so compensation is only partial.

  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: "Create a full EDM arrangement". It further distinguishes this tool from its many genre siblings by detailing the festival/mainstage style and listing exact track roles (drums, bass, supersaw, lead).

  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 clearly implies use for EDM/festival/mainstage tracks and explains the default key, BPM, and progression, but it never explicitly says when to prefer this over sibling tools like create_house_arrangement or create_trance_arrangement. No exclusions or alternative tool mentions are provided, so usage guidance remains implicit.

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

• mcp_opendaw_create_rnb_arrangementA
  3.6/5.0
  Behavior2/5

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

  With no annotations, the description must disclose side effects and prerequisites, but it does not. It mentions 'Programmable feel — not live, but loose' and return values, yet never clarifies whether writing to the specified tracks overwrites existing content, whether tracks must already exist, or what occurs on invalid track indices. This is a critical transparency gap for a tool that writes notes.

  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 well-structured with a clear opener, bullet-like track breakdown, and a parameter heading, but it is overly long with artist references and theoretical explanations (e.g., 'i-VI-III-VII... same as synthwave') that carry the message without adding tool-specific operational value. It is informative but not concise.

  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?

  Despite 11 parameters and no annotations, the description supplies substantial context: track-by-track creation details, parameter ranges, examples, and return type. It lacks precondition/error-handling notes, but the combination of genre spec, parameter semantics, and examples makes it sufficient for an agent to invoke correctly in most scenarios.

  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?

  The description documents 9 of 11 parameters with useful semantics (bpm range, bars multiple of 4, root note, octave register, track indices) and gives example calls. However, it omits velocity and start_beat, which remain only schema titles. The coverage is strong but not complete, so it earns a mid score.

  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 'Create a full modern R&B arrangement' followed by a specific genre recipe (trap-influenced drums, sub bass, extended chords, vocal lead). The name and content clearly distinguish it from sibling genre arrangement tools like create_reggae_arrangement or create_synthwave_arrangement.

  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?

  Strong usage context is provided via tempo ranges (55-85), artist references (The Weeknd, Frank Ocean), and explicit track-by-track musical specifications. However, it never explicitly states when NOT to use this tool or contrasts it with alternative genre tools, leaving the agent to infer applicability from genre.

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

• mcp_opendaw_get_neuralamp_modelA
  3.6/5.0
  Behavior2/5

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

  The description contains a significant internal contradiction: first it says 'or an error if the effect is ... has no model loaded,' but later states 'or empty if no model loaded.' This ambiguity fails to disclose the actual return behavior for the no-model case, which is critical for correct agent handling. Annotations (readOnlyHint) are not contradicted, but the description lacks consistent behavioral detail.

  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 concise and front-loaded with the primary purpose. It avoids fluff and logically separates purpose, return behavior, and parameters. However, the contradictory statements about error vs. empty return waste a sentence and could have been consolidated for clarity.

  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 getter, the description covers return values and parameter meanings, but the contradictory return behavior undermines completeness. It also lacks context on how unit_index and effect_index are resolved (e.g., from list_effects), which would be helpful for agents navigating the DAW hierarchy.

  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?

  With 0% schema description coverage, the description attempts to compensate by explaining each parameter: 'unit_index: AU index' and 'effect_index: Effect index in the audio effect chain.' These definitions are minimal and omit details like zero-based indexing or how to obtain valid indices, leaving room for misinterpretation.

  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's function: 'Get the NeuralAmp (Tone3000) model JSON for a NeuralAmp effect.' It uses a specific verb ('Get'), identifies the exact resource (NAM model JSON), and specifies scope (for a NeuralAmp effect), distinguishing it from general effect getters like get_effect_state.

  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 clear usage context by indicating this is for NeuralAmp effects and specifies error conditions when the effect is not a NeuralAmp or has no model loaded. However, it does not explicitly name alternative tools or provide when-not-to-use guidance beyond these error cases.

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

• mcp_opendaw_list_script_paramsA
  3.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true. The description adds valuable context: mapping info is derived from code declarations, not runtime introspection, and the code is the single source of truth. This goes beyond the annotation and helps the agent understand data provenance.

  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 concise sentences; the first states the core purpose and the second adds essential detail about output fields and data source. No filler or repetition.

  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?

  Output schema and return values are covered, and the description explains what the list contains. However, without any param semantics, the tool is incomplete for an agent that needs to know how to specify a scriptable device. This is a noticeable gap for a 3-required-parameter tool.

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

  Parameters1/5

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

  Schema description coverage is 0% and the description does not explain device_type, unit_index, or device_index. The agent is given no semantic meaning for any of the three required parameters, making correct invocation largely guesswork.

  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+resource: 'List @param declarations on a scriptable device with full mapping info.' It details exactly what is returned (label, index, current value, min, max, etc.) and distinguishes itself from sibling list tools by targeting scriptable device parameters.

  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 clear context (parsed from `// @param` declarations, code is source of truth) but does not explicitly state when to use this tool over alternatives like list_effect_parameters or list_instrument_params, 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.

• mcp_opendaw_schedule_clip_stopA
  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. It does mention 'schedule' but gives no details about the timing mechanism, whether clips are stopped immediately or at a future time, side effects, or reversibility. This lack of behavioral detail is a significant gap for a mutation/scheduling 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 extremely concise: a single clear sentence stating the purpose, followed by a focused 'Args:' block. Every sentence earns its place, and the most critical information is front-loaded.

  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 a scheduling tool with no annotations, the description is incomplete. It does not explain what 'schedule' means in this context (e.g., immediate stop vs. timed event), what triggers the stop, or what the output/return value represents despite the presence of an output schema. The tool's complexity demands more 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 description adds valuable meaning beyond the schema: it explains that track_ids is a 'comma-separated list of track UUIDs' and clarifies the purpose ('to stop clips on'). Since the schema description coverage is 0%, this parameter explanation compensates well, though it could mention validation or empty-string behavior.

  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's function with a specific verb ('Schedule'), resource ('clips'), and scope ('to stop on specified tracks, session view'). It distinguishes itself from the sibling tool mcp_opendaw_schedule_clip_play by explicitly saying 'stop' rather than 'play'.

  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 '(session view)' implies when this tool is applicable, but there is no explicit guidance on when to use it versus alternatives like schedule_clip_play. The usage context is implied by the action itself, but no exclusions or alternative tools are mentioned.

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

• mcp_opendaw_set_groove_shuffleA
  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 burden of behavioral disclosure. It provides a useful mapping of amount values (0.0, 1.0, typical values) but doesn't mention side effects, reversibility, or whether it applies to the entire project or just selected regions. The 'set' verb implies mutation but lacks safety details.

  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, with three lines each adding value: the action, the numeric scale, and typical examples. It's front-loaded and doesn't waste words.

  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 main parameter semantics and the output schema handles return values. However, the type mismatch with the schema undermines completeness; an agent cannot safely use the tool without resolving this contradiction. It's adequate but with a critical gap.

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

  Parameters1/5

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

  The description's values (0.0, 0.15, 0.25, 0.5, 1.0) directly contradict the input schema's parameter type of 'integer'. This is a critical inconsistency that would mislead an agent into passing a float, causing validation errors. The description adds meaning but it's incompatible with 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 clearly states the action ('Set the groove/shuffle (swing) amount') and identifies the target resource ('for the project'). It distinguishes itself by focusing on the project-level swing setting, which differentiates it from other rhythm tools like apply_swing.

  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 tool is for setting the global swing/groove amount, providing clear context. It doesn't explicitly list alternatives or exclusions, but the singular parameter and project scope make the use case clear.

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

• mcp_opendaw_set_region_muteA
  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 full burden. It adds the useful non-destructive note ('without deleting it') and explains the mute parameter. However, it doesn't disclose potential side effects (e.g., whether playback state is affected) or error conditions, leaving gaps 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?

  Two short sentences, no filler. The description is front-loaded with the core action and immediately explains the key parameter. 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 simple mute operation, the description is adequate but minimal. It lacks usage context, prerequisites, and return value details (though an output schema exists). Given the tool has 4 parameters and no annotations, a bit more context would round it out, but it is not severely incomplete.

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

  Parameters2/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 only explains the 'mute' parameter ('true to mute, false to unmute'). The three index parameters (track_index, region_index, unit_index) are left to the agent's inference from their names, with no indication of zero-based indexing or required context.

  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 verb (mute/unmute), resource (specific region), and explicitly contrasts with deletion ('without deleting it'), distinguishing it from sibling tools like set_track_mute and delete_region.

  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 describing the action, but does not explicitly state when to use this tool vs alternatives. It does not mention that set_track_mute exists for tracks or that delete_region is for deletion, so guidance is only implicit.

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

• mcp_opendaw_set_send_panA
  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 simply says 'Set' and gives the value range, but does not mention side effects, non-reversibility, whether the send must already exist, or any error behavior. This is minimal 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 compact and front-loaded: one purpose sentence followed by a concise parameter list. Every line adds value and there is 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?

  The description covers the essential parameters and the pan scale, but for a mutating tool with no annotations, it lacks usage context, prerequisites, and error handling details. The operation is simple and the parameter documentation is solid, so it is minimally complete but has clear 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%, but the description manually documents all three parameters: unit_index, send_index, and pan. It also explains pan semantics with a full left/center/full right mapping, fully compensating 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.

  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 the stereo pan for an aux send.' It also defines the allowable range (-1.0 to 1.0), making the action immediately clear. This differentiates it from sibling send tools like set_send_level and set_send_routing.

  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 set_track_panning or set_send_level. There is no mention of prerequisites like an existing send or how invalid indices/pan values are handled. The usage context is only implied by the tool name and parameter descriptions.

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

• mcp_opendaw_set_track_enabledA
  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 transparency burden. It discloses the return value (old and new enabled state) and parameter meanings, but does not mention side effects, prerequisites, or whether the operation is reversible or has any state implications beyond the toggle.

  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 starts with the core purpose, followed by parameter definitions and the return value. No redundant sentences exist, though the line-break formatting could be refined into a more structured list.

  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 tool, the description covers the action, all parameters, and the return format. Since no output schema is shown, the mention of 'old and new enabled state' is valuable. Lacks information about index conventions or error handling, but these are minor 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?

  The input schema provides only parameter names (Enabled, Unit Index, Track Index) with no descriptions. The description fills this gap entirely by explaining each parameter: unit_index as AU index, track_index within the AU, and enabled as mute/unmute semantics. 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.

  Purpose4/5

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

  The description clearly states the action ('Enable or disable a track') and the target resource, and explicitly equates it with track mute in the UI. This aids differentiation from many instrument/effect tools, though it does not distinguish it from the sibling 'set_track_mute' tool.

  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 explicit when-to-use or when-not-to-use guidance is provided. The 'equivalent to track mute' phrase hints at a muting use case, but does not explain how this differs from the set_track_mute sibling or when to prefer one over the other.

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

• mcp_opendaw_set_track_volumeA
  3.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 burden and provides substantial behavioral detail: it discloses the VolumeMapper.decibel(-96, -9, +6) powerByCenter mapping, the valid range (-96 to +6 dB), and the raw value at 0 dB (0.768). This goes beyond a generic 'set volume' statement, though it does not mention side effects or prerequisites.

  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 sentences with no redundancy. The first sentence front-loads the core purpose, and the subsequent sentences add essential technical detail. 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 simple two-parameter setter with an output schema, the description is nearly complete. It fully specifies the volume range and mapping, and unit_index is obvious. It lacks usage guidance and does not explain how to identify the target audio unit, but these are minor gaps for a low-complexity tool.

  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 must compensate. It adds meaning to volume_db by giving the range and mapping, but it leaves unit_index undefined. While unit_index is self-explanatory from its name, the description does not explicitly connect either parameter to the schema, so it only partially compensates.

  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 'Set volume of an audio unit in dB' with a specific verb and resource, and provides the dB range. However, it does not explicitly distinguish this from sibling tools like set_track_panning or set_effect_parameter, so it falls 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?

  The description gives no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. The mapping and range imply usage context, but there is no explicit direction, so it scores 2 (no guidance).

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

• mcp_opendaw_add_chord_tensionA
  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 transparency burden. It discloses that the extension is calculated from the chord root, how the chord is found (root = lowest note), and includes return values. However, it omits error/failure behavior and whether the operation is reversible, leaving some uncertainty 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.

  Conciseness4/5

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

  The description is long but well-structured: a summary, detailed extension list with musical rationales, parameter specs, return statement, and a concrete example. Each section adds value, and the content is front-loaded with the core purpose. Slight verbosity in the extension list is justified by its usefulness.

  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 fully addresses the musical logic and returns, and includes an example call. However, it misses explanation of the three locator parameters (unit/track/region indices) and does not cover failure conditions or how the user obtains these indices. Given the tool's complexity and absent annotations, this is a notable gap.

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

  Parameters2/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 explain parameters. It does well for extension, chord_position, octave, and velocity, but completely omits unit_index, track_index, and region_index — three required parameters. These are essential for targeting the chord, and the schema only lists them as titles with no additional meaning.

  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 opening sentence 'Add a tension/extension note to an existing chord — jazz harmony' clearly identifies the action and target resource. It further explains the purpose ('This is how triads become jazz chords') and is distinct from sibling tools like add_suspension or add_passing_tones.

  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 usage context with per-extension guidance on musical character and appropriate scenarios ('The most common jazz extension', 'Can clash with 3rd — use carefully'). It does not explicitly name alternatives or state when not to use, but the contextual guidance is strong enough.

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

• mcp_opendaw_add_modular_moduleA
  3.7/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 full burden. It explains parameters and return value, but does not disclose side effects, error cases, or whether the operation is destructive. For a 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.

  Conciseness5/5

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

  The description is a compact bulleted list with no filler. Every line provides necessary parameter or return information, earning 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?

  All parameters and the return value are covered, and an output schema exists. However, missing prerequisite context (e.g., device must already exist, index validity) and edge-case behavior make it not 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%, and the description compensates fully by explaining every parameter, including enumerating valid module_type values and clarifying x/y as grid positions.

  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 'Add a module to a Modular device' with a specific verb and resource. It distinguishes from sibling modular tools like list, connect, remove, and set param by focusing on the creation 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 on when to use this tool versus alternatives, such as list_modular_modules or connect_modular_modules. No prerequisites are mentioned, like needing an existing Modular device or valid AU/effect indices.

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

• mcp_opendaw_consolidate_clipA
  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 transparency burden. It discloses the primary behavior (creating an independent copy) and mentions return status ('Returns success, or error'). However, it omits potential side effects, reversibility, and details about failure modes, leaving notable gaps.

  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 sized and well-structured, with a clear definition, condition, and parameter list. The final 'Returns success, or error.' is slightly redundant but not harmful. Overall, it is concise and readable.

  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 a mutation tool with no annotations, no output schema details, and 0% schema coverage, the description lacks important context. It does not explain prerequisites (e.g., clip must exist), the meaning of 'event collection,' or what happens to the original clip after consolidation. It is insufficient for a complete understanding.

  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 must compensate. It adds brief semantics for each parameter: 'unit_index: AU index', 'track_index: Track index within the AU', 'clip_index: Clip index to consolidate.' This clarifies the index hierarchy but does not elaborate on indexing conventions or how to obtain these indices.

  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's function: 'Consolidate a clip's event collection — make it unique (not shared/mirrored).' It uses a specific verb+resource and explicitly distinguishes from sibling tools like consolidate_region and consolidate_note by targeting the clip's event collection.

  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 usage condition: 'If a clip shares its event collection with other clips (mirrored), this creates a new independent copy so edits don't affect other clips.' This indicates when to use the tool, though it does not explicitly list alternatives 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.

• mcp_opendaw_create_breakbeatA
  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. It transparently discloses the musical behavior, including per-subtype note placements and velocity adjustments. However, it is silent on placement mechanics (track_index, start_beat) and whether existing notes are overwritten or added, leaving uncertainty about 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 well-structured with a clear lead, bullet-like breakbeat_type details, parameter explanations, and an example. It is long but each section serves a purpose; the historical context, while informative, could be trimmed slightly. Overall, it is a high-value description that earns its length.

  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 core creation behavior and musical content are thoroughly covered, and the output schema covers return values. However, key parameters like start_beat and unit_index are not explained, and there is no mention of how the pattern integrates into an existing project (e.g., whether it overwrites a region). These gaps make the description incomplete for a tool with 10 parameters and no annotation support.

  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?

  Since the schema has 0% description coverage, the description compensates well for most parameters: breakbeat_type values are exhaustively detailed, and bars, pitches, and velocity are explained with defaults. However, start_beat and unit_index are entirely undocumented, and track_index only appears in the example without semantic explanation, leaving some parameters underspecified.

  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's purpose: 'Create a breakbeat pattern' and elaborates on specific subtypes (amen, dnb, big_beat, etc.). However, it does not explicitly distinguish itself from sibling tools like create_drum_fill or create_break, so it falls short of the highest score for 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 Guidelines4/5

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

  The description gives strong contextual guidance on when each breakbeat_type is appropriate, linking them to genres and artists (e.g., 'The DNA of jungle and DnB'). It does not provide explicit exclusions or alternatives, but the context is clear enough for an agent to decide when 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.

• mcp_opendaw_create_call_responseA
  3.7/5.0
  Behavior3/5

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

  No annotations are provided, so the description bears the full burden. It explains the behavioral pattern (call→response→call→response) and parameter effects, but it doesn't disclose side effects like where notes are placed (track/unit) or whether it mutates existing project state. This is a partial disclosure, not a full one.

  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 well-structured: it leads with a clear purpose, provides musical context, lists parameters with examples, states return values, and gives a usage example. It is slightly verbose with genre enumeration, but each sentence contributes useful information.

  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 core musical semantics, return values, and provides a concrete example, which is good for a generation tool. However, it misses placement-related parameters (track_index, unit_index, start_beat) and doesn't specify which scale types are included beyond a vague reference to music_theory. These gaps matter for a tool with 11 parameters and no 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?

  Schema description coverage is 0%, so the description compensates well by explaining 8 of 11 parameters, including scales, root, patterns, repeats, octave, velocity, and step_duration, with examples and ranges. However, it omits start_beat, unit_index, and track_index, which are present in the schema and important for placement.

  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 creates a call-and-response pattern with antecedent/consequent phrasing, which is specific and actionable. However, it doesn't differentiate from the sibling tool `create_call_and_response`, which appears to serve the same purpose, so it loses a point for sibling 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 provides clear context on when to use the tool (e.g., for blues, jazz, hip-hop, electronic, and folk music) and explains the pattern alternation. It doesn't explicitly mention when not to use it or name alternatives, but the context is strong 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.

• mcp_opendaw_create_comparsaA
  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 burden of behavioral disclosure. It does state, 'Creates notes on track_index using GM percussion', which clarifies the core side effect (note creation on a target track). It also lists the exact GM instruments that will be used, adding useful detail. However, it does not disclose whether existing notes are overwritten, whether any project setup is required, or any other side effects, leaving some ambiguity.

  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 well-organized into clear sections: definition, instrument mapping, and style variants. Every bullet point adds useful context for a culturally-specific tool. The opening sentence is front-loaded with the primary action. While it could be trimmed by removing background history, the detail is justified for a style-specific generator and maintains readability.

  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 complexity (7 parameters, 5 styles, multiple percussion instruments) and that an output schema exists, the description is quite complete. It explains the cultural origin, maps each GM instrument to its role, details each style variant, and explicitly states the track-writing behavior. Minor gaps remain around project requirements (e.g., track must be a GM drum track) or interaction with existing notes, but overall it covers the essential context.

  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 must compensate. It provides explicit value semantics for the 'style' parameter (listing all five styles with descriptions) and clarifies 'track_index' by saying notes are created there. Other parameters like bars, velocity, tempo_bpm, and start_beat are self-explanatory by name, but 'unit_index' remains undocumented. The addition of style and track_index is valuable but only partially compensates for the complete lack of schema-level 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 opens with 'Create Cuban comparsa — carnival procession percussion', which clearly states the tool's function: generating a specific Cuban carnival percussion pattern. It distinguishes itself from the many sibling creation tools by explicitly naming its unique cultural/musical niche and providing detailed genre-specific 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?

  The description gives cultural context and enumerates style variants, implying it should be used when a Cuban comparsa percussion groove is desired. However, it never explicitly states when to use this tool over alternatives like create_clave or create_tumbao, nor does it mention any exclusions or prerequisites, so guidance is 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.

• mcp_opendaw_create_dubstep_arrangementA
  3.7/5.0
  Behavior2/5

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

  No annotations are present, so the description carries the burden. It does state the output ('Returns notes created per track and total') and notes that 'unit_index' should be an AU with note tracks, but it does not disclose whether the tool overwrites existing notes, creates tracks, requires specific project setup, or has other side effects. This is a significant 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.

  Conciseness4/5

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

  The description is structured with a clear summary, track-specific details, a half-time explanation, parameter list, and examples. It is somewhat long but front-loaded and each section adds value; the half-time explanation is slightly redundant.

  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?

  With 10 parameters, no annotations, and 0% schema coverage, the description covers most parameters, provides default values, and includes example calls. It still lacks descriptions for velocity and start_beat and omits side-effect behavior, but overall it is sufficiently informative for basic 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%, but the description compensates by explaining bpm, bars, root, octave, unit_index, and the three track parameters, including defaults and ranges. However, velocity and start_beat are not described, leaving two parameters unresolved.

  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 opening sentence clearly states the tool creates a full dubstep arrangement with half-time drums, wobble bass, and lead arp across 3 tracks. This is a specific verb+resource and distinguishes it from sibling genre tools by naming dubstep-specific elements.

  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 for dubstep tracks at 140 BPM and highlights the half-time feel as 'the fundamental difference from all other electronic arrangements.' However, it doesn't explicitly state when to choose this over other genre arrangement tools or provide clear exclusions.

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

• mcp_opendaw_create_future_bass_arrangementA
  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 thoroughly explains what will be generated (4 tracks, their musical content, genre style). However, it does not disclose potential side effects, such as whether it overwrites existing track data, whether it creates new tracks or uses existing indices, or if the operation is undoable. This ambiguity prevents a higher 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 longer than average but well-structured with clear sections (genre overview, track details, parameter list, examples). Every sentence adds useful context for a creative tool; there is minimal fluff. It is not excessively wordy for the complexity it covers.

  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?

  Given 11 parameters and no annotation support, the description is incomplete. It covers the overall purpose and main musical outputs thoroughly, but fails to explain several parameters and does not address side effects or prerequisites. An output schema exists, so return values don't need to be described, but the missing parameter semantics and side-effect information leave the description only partially complete.

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

  Parameters2/5

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

  Schema coverage is 0%, so the description must compensate. It explains bpm, bars, root, and octave, but 7 of 11 parameters (velocity, bass_track, drum_track, lead_track, start_beat, unit_index, chord_track) are left undocumented. The track indices are only implicitly mentioned in the track descriptions, not explained as parameters. This leaves a significant gap.

  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's function: 'Create a full future bass arrangement — 4 tracks: drums + bass + chords + lead.' It uses a specific verb ('create'), identifies the resource ('future bass arrangement'), and differentiates from sibling genre tools by explicitly naming the genre and detailing the track structure.

  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 context for when to use the tool by detailing future bass genre characteristics and giving example calls (bpm, root, bars). However, it does not explicitly state when not to use it or directly mention alternative tools (e.g., other create_*_arrangement tools), which would warrant a 5.

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

• mcp_opendaw_create_phonk_arrangementA
  3.7/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 disclose the output structure (three named tracks), pattern characteristics, and even a simulation detail ('glide is simulated by short overlapping notes'). However, it does not explain what happens to existing tracks, whether the tool is additive or overwriting, or how start_beat and unit_index influence placement, which are relevant for a multi-track mutation/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.

  Conciseness4/5

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

  The description is long but well-structured and front-loaded with the core purpose. The genre style block, per-track breakdown, parameter list, and examples each carry relevant information for generating a stylistically accurate arrangement. It could be slightly trimmed, but it is not wasteful.

  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 high-complexity tool with 10 parameters and no parameter descriptions, the description is not fully complete. It does an excellent job covering the musical content and four key parameters, and the output schema exists for return values, but the unexplained parameters and missing placement/overwrite behavior leave gaps that make the tool only partially self-contained.

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

  Parameters2/5

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

  The input schema has 10 parameters with 0% schema description coverage, and the description only explains 4 of them (bpm, bars, root, octave). It provides helpful ranges and defaults for those four, but omits velocity, bass_track, drum_track, start_beat, unit_index, and cowbell_track entirely. Because the schema offers no descriptions and titles alone are weak, this leaves a significant gap for an agent trying to set track indices or timing.

  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: 'Create a full drift phonk arrangement — 3 tracks: drums + 808 + cowbell lead.' It clearly distinguishes this tool from sibling genre-arrangement tools by naming drift phonk and listing exact track types and style references (Kordhell, MC Slvr, LXST CXNTURY).

  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 states when to use this tool: when a drift phonk arrangement with drums, 808, and cowbell is needed. It provides rich genre context and parameters, but it does not explicitly call out alternatives or exclusion criteria (e.g., 'use create_trap_arrangement for trap'), so it stops short of a full when/why-not comparison.

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

• mcp_opendaw_create_pitch_stretched_clipA
  3.7/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 full behavioral disclosure burden. It adds some context (pitch alignment, AudioPitchStretchBox mode) but omits important side effects such as whether creating the clip overwrites an existing clip in the slot, prerequisites like engine running, or what the return value signifies.

  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: an action sentence, two behavioral/technical context sentences, then a bullet-like parameter list. Every line is useful and there is no 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?

  Parameter explanations are helpful, but the description lacks broader workflow context: it doesn't mention that audio must be loaded first, whether indices are zero-based, what happens if a clip already occupies the slot, or how unit/track/clip indices interrelate. The presence of an output schema reduces the need to explain return values, but behavioral completeness is still limited.

  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 by explaining each parameter's role. sample_id is tied to mcp_opendaw_load_audio, clip_index is defined as a slot index, and bpm is described as source BPM. Some ambiguity remains around unit_index and track_index relationship, but overall adds substantial meaning beyond titles.

  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 'Create a pitch-stretched audio clip in session view' with a specific verb, resource, and location. It distinguishes itself from sibling tools like create_time_stretched_clip by emphasizing pitch alignment with project tempo and noting the use of AudioPitchStretchBox.

  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 through the description of pitch-stretched behavior (maintaining pitch alignment with tempo). No explicit alternatives or 'when not to use' guidance is given, even though related tools like create_time_stretched_clip exist.

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

• mcp_opendaw_create_playfield_sampleA
  3.7/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 return value but does not state side effects, prerequisites (e.g., an existing Playfield), or failure behavior when auto-detection fails. For a mutation operation, 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.

  Conciseness5/5

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

  The description is compact and well-structured: a single purpose sentence, followed by a bullet-like parameter legend, and a return value note. Every line 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.

  Completeness3/5

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

  The description covers the core aspects: purpose, parameters, and return value. However, it does not explain what 'duration hint' actually controls, nor does it provide guidance on error cases or prerequisites. Given that the operation is straightforward and the output schema exists, the description 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 has 0% description coverage, but the description compensates by explaining all four parameters. It provides concrete examples for midi_note and the special meaning of unit_index = -1. However, sample_name and duration_seconds are described only as 'name for the sample slot' and 'duration hint', leaving some ambiguity about their exact 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 first sentence uses the specific verb 'Add' and the resource 'drum pad to a Playfield drum machine', clearly stating what the tool does. This distinguishes it from sibling tools like list_playfield_samples and set_playfield_sample_enabled. The description also clarifies that 'create_playfield_sample' means adding a pad/sample slot, not just creating a sample.

  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 purpose implies when to use the tool (when you want to add a drum pad to a Playfield), but no explicit guidance is given about when not to use it or which alternatives to choose. There is no mention of sibling tools like copy_playfield_sample or create_drum_pattern, 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.

• mcp_opendaw_create_psytrance_arrangementA
  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. It discloses the generated musical content in detail (kick pattern, bassline syncopation, lead motifs, atmosphere textures) and default key, but omits side effects such as whether existing notes on the target tracks are overwritten, or if any prerequisites exist. This is a notable gap 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.

  Conciseness4/5

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

  The description is well-structured with a clear summary, bullet points on genre traits, and a numbered list of tracks. While the genre history adds length, it provides useful musical context and each section earns its place. Slightly verbose but not excessively so.

  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 thoroughly covers the musical output and track structure, but falls short on explaining all parameters and their constraints. Since there is an output schema, return values are not required to be described, but the lack of parameter semantics for 4 of 7 parameters makes the tool less complete for correct invocation.

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

  Parameters2/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 explains track_index usage (offsets for the 4 tracks) and implies bpm and key_root defaults (145 BPM, F minor). However, it does not explain bars, velocity, start_beat, unit_index, or their effect on the generated arrangement, leaving most parameters without semantic meaning.

  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's function: 'Create a psytrance arrangement' with explicit details on genre characteristics and the 4 tracks it creates (Drums, Bass, Lead, Atmosphere). It distinguishes this from sibling genre tools by specifying psytrance-specific elements like 145 BPM, rolling bassline, and hypnotic lead.

  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 context for when to use the tool: when creating a psytrance arrangement, with specific musical attributes and track layout. However, it does not explicitly mention alternatives or when not to use it, though the genre-specific name and content implicitly distinguish it from siblings like create_trance_arrangement.

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

• mcp_opendaw_create_riffA
  3.7/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose behavioral traits. It describes musical style and parameter ranges, but never states whether the operation writes to a track, overwrites existing notes, requires permissions, or is reversible. The lack of side-effect disclosure is a significant gap 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.

  Conciseness4/5

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

  The description is well-structured with a clear opening, genre bullet points, parameter list, and examples. Each section serves a purpose, though it is longer than minimal; the genre details and examples add value but could be trimmed without losing the core message.

  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?

  The description covers the musical concept and primary parameters, but it completely omits the placement parameters (start_beat, unit_index, track_index), leaving agents uncertain how the riff integrates with a track or region. It also does not clarify whether the riff is appended, replaces existing notes, or creates a new region, making the invocation context incomplete.

  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 zero property descriptions, so the description compensates by explaining riff_type, key_root, scale_type, bars, octave, velocity, and seed, including allowed values and defaults. However, it omits start_beat, unit_index, and track_index, leaving those parameters underexplained despite being in 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 opens with 'Create a genre-specific riff — catchy repeated melodic fragment,' a specific verb+resource statement. It further distinguishes a riff from a melody and an ostinato, clearly separating this tool from siblings like create_melody and create_ostinato.

  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 context for when to use this tool by contrasting riff against melody and ostinato, and it gives genre-specific guidance with examples. However, it does not explicitly name alternative tools or state when not to use this tool, so it lacks explicit exclusions.

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

• mcp_opendaw_create_rondoA
  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 that sections are created sequentially on track_index (melody) and track_index+1 (bass), and it details scale-degree patterns for A, B, and C sections. However, it does not state whether the tool overwrites existing notes, requires pre-created tracks, or has 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.

  Conciseness4/5

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

  The description is long but well-structured and front-loaded with a one-sentence definition. The detailed form list, scale list, and harmonic-degree explanations are useful and relevant. It could trim some redundancy with schema defaults, but overall it earns its length for a complex music-generation 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 tool's complexity and the complete lack of schema descriptions or annotations, the description provides a rich amount of context: form definitions, scale-degree patterns, track placement, and section length. It omits side-effect and prerequisite details, but the presence of an output schema reduces the need to describe return values, and the content is comprehensive enough 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.

  Parameters3/5

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

  Schema description coverage is 0%, and the description partially compensates by enumerating valid key_root values, scale_name options, and form_type variants, as well as explaining bars_per_section and track_index placement. It does not clarify velocity, tempo_bpm, start_beat, or unit_index, leaving some parameters underspecified.

  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 'Create a rondo' and immediately explains the concept as 'recurring theme alternating with contrasting episodes.' It clearly identifies a specific resource/action and distinguishes itself from siblings like create_sonata_form and create_ternary_form by focusing on rondo structure and providing form types.

  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 substantial musical context and form-type options, but it never explicitly states when to use this tool over other compositional siblings like create_sonata_form or create_variations. The guidance is implied through the definition of rondo and its forms, but no direct alternatives or exclusions are provided.

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

• mcp_opendaw_create_sonata_formA
  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. It discloses useful behavioral details such as melody on track_index and bass on track_index+1, and that the development section uses sequence-based modulation. However, it does not state whether existing notes are cleared or replaced, what prerequisites exist, or what side effects occur on the target tracks.

  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 well-structured with clear numbered sections and front-loaded purpose. However, it is verbose: the music-theory tutorial details (e.g., 'stepwise, lyrical, conjunct', 'closing group: cadential figures') exceed what is operationally needed for tool invocation and could be condensed without losing essential guidance.

  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 9-parameter compositional tool, the description richly covers the musical form, scale options, and track layout – strong contextual grounding. But it omits operational details for 3 parameters and does not describe whether the tool overwrites existing region content. The presence of an output schema covers return values, but these gaps prevent full completeness.

  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 must compensate. It adds substantial meaning for scale_name (full list of valid values), track_index (melody/bass relationship), and the bar-count parameters (exposition/development/recap implied by the structural explanation). However, velocity, start_beat, and unit_index are never explained, leaving a meaningful gap.

  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 'Create sonata form — exposition, development, recapitulation' uses a specific verb + resource and clearly distinguishes this tool from sibling form-creating tools like create_binary_form, create_ternary_form, and create_rondo. The detailed structural description reinforces exactly what is being generated.

  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 context for when to use the tool ('structural foundation of classical symphonies, sonatas, string quartets, and concertos from Haydn through Mahler'), implicitly signaling classical-era composition. However, it never explicitly names alternatives or states when not to use this tool versus other form generators.

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

• mcp_opendaw_get_project_metadataA
  3.7/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already establishes the read-only nature, and the description adds no contradictory behavior. The description adds minimal behavioral context beyond the return values, providing no insights into side effects or performance characteristics.

  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 short sentences, front-loading the core purpose and then providing a quick usage context and return fields. No extraneous information is present, so 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?

  Given the tool's simplicity (no parameters, output schema present), the description covers the essential purpose and return data. However, the lack of differentiation from several related sibling tools (e.g., get_project_info, get_project_state) leaves a minor 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 input schema is empty and schema description coverage is 100% by default. The description correctly lists the return fields, but since there are no parameters, there is nothing to explain beyond 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 explicitly states 'Get project metadata' and enumerates the specific fields (creation date, BPM, time signature, AU count, track count), making the tool's function clear. However, it does not differentiate from sibling tools like get_project_state or get_project_info that 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 Guidelines3/5

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

  The phrase 'Quick overview of the project state in one call' suggests a lightweight, single-call usage context, but it lacks explicit guidance on when to prefer this tool over similar metadata/state tools. It does not mention any alternatives or exclusions, so the usage guidance is only implied.

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

• mcp_opendaw_remove_effectA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description bears full responsibility for behavioral disclosure. It states the removal but does not mention side effects like reindexing of remaining effects, error behavior for invalid indices, or any destructive/irreversible implications. This is a significant 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 exceptionally concise: one purpose line and two parameter definitions. Every sentence adds value, with no fluff or repetition. The structure front-loads the action and then lists parameters clearly.

  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 removal tool, the description is adequate but leaves gaps: no guidance on locating indices, no error handling details, and no mention of whether unit_index is 0-based. An output schema exists, so return values need not be explained, but the lack of usage and error context makes it minimally 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 description coverage is 0%, but the description compensates by clearly defining both parameters: 'unit_index: Audio unit index.' and 'effect_index: Effect position to remove (0-based).' It adds the crucial 0-based detail for effect_index, though remaining ambiguity about unit_index's indexing prevents a perfect score.

  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: 'Remove an audio effect from an audio unit's chain.' This clearly identifies the verb, resource, and scope, and distinguishes it from sibling tools like add_effect, list_effects, remove_midi_effect, and set_effect_enabled.

  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 implied through the action and parameter definitions, but the description does not explicitly state when to use this tool versus alternatives, nor does it mention prerequisites such as obtaining valid indices via list_effects. No exclusions or context guidance are provided.

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

• mcp_opendaw_set_audio_region_waveform_offsetA
  3.7/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. It discloses that the offset shifts the visual start (non-destructive display) and that it returns old and new offsets. However, it doesn't disclose potential side effects, prerequisites, or error conditions, which is modest but acceptable for a simple 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 with the action, followed by a short explanation, parameter list, and return value note. Every sentence earns its place; there is no redundant 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 4-parameter setter with an output schema, the description covers what the tool does, the parameters, and return behavior. It could be improved by adding how to find the indices (e.g., via list_audio_regions) or an example, but these are not essential 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 has 0% description coverage, and the description compensates by listing each parameter with a brief meaning: unit_index (AU index), track_index (Track index within the AU), region_index (Audio region index), and offset (in seconds). While terse, this adds meaning beyond the bare schema titles, especially the unit for offset. The term 'AU' is not expanded, but this is a minor gap.

  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 a specific verb+resource: 'Set the waveform display offset of an audio region.' It clearly explains the concept (shifts visual start) and purpose. However, it doesn't explicitly distinguish this from sibling operations, though the unique action is clear enough without an explicit alternative.

  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 the tool's purpose ('useful for aligning the waveform display with the actual audio content') which gives context for when to use it, but does not explicitly state when not to use it or suggest any alternative tools. There are no exclusions or fallback recommendations.

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

• mcp_opendaw_set_effect_parameter_stringA
  3.7/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. It only enumerates parameters and examples without disclosing side effects (e.g., immediate mutation of the effect), reversibility, failure modes, or any behavioral consequences of setting the parameter.

  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 plus a tight parameter list. Every line adds value, the purpose is front-loaded, 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.

  Completeness3/5

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

  All parameters are documented, and an output schema exists, so return value documentation is unnecessary. However, the description lacks guidance on how to discover valid parameter names or which effects support string parameters, and it does not mention error conditions. It is minimally sufficient but not rich.

  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 provides concise definitions for all four parameters (unit_index, effect_index, parameter_name, string_value) and offers valid example values for string_value, adding meaningful detail beyond the schema's bare titles.

  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 ('Set a string parameter') and the target resource ('audio effect'), with a concrete example (Waveshaper equation). This distinguishes it from sibling tools like set_effect_parameter_bool and set_effect_parameter_int.

  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 for string-type effect parameters by its name and the example values, but it does not explicitly contrast with alternatives like set_effect_parameter_int or provide when-not-to-use guidance. The context is clear but not fully developed.

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

• mcp_opendaw_set_instrument_paramA
  3.7/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 transparency burden. It does disclose useful behaviors: auto-detection of the first non-master instrumented AU, the param_index alternative, and that it returns old and new values. However, it does not mention side effects, whether the change is reversible, or any required permissions/state assumptions, leaving gaps in 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?

  The description is compact and well-structured, using a single introductory sentence followed by clear per-parameter explanations. Every sentence adds value, and the examples for param_name are especially useful without being verbose.

  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 four parameters are documented, and the return behavior (old and new values) is stated. The description does not mention how to discover valid param_name values (e.g., via list_instrument_params) and leaves some ambiguity about how to set param_name when using param_index, but overall it is quite complete for 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%, but the description fully compensates by explaining every parameter: unit_index with auto-detect semantics, param_name with concrete examples, value as the new parameter value, and param_index as an alternative with sentinel behavior (-1 = use name). This adds significant meaning beyond the raw JSON 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 tool's action: 'Set a parameter on the instrument connected to an audio unit.' It is specific about the resource (instrument parameter) and provides helpful context like auto-detection. However, it does not explicitly differentiate from siblings like set_effect_parameter or set_midi_effect_param, so it does not fully achieve 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 Guidelines2/5

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

  The description gives no explicit guidance on when to use this tool versus alternatives. It says 'Works with any instrument type' but does not mention when to use set_effect_parameter, list_instrument_params, or other related tools. No when-not-to-use or exclusion criteria are provided.

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

• mcp_opendaw_set_loop_regionA
  3.7/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 behavioral burden. It discloses the core behavior (loops when enabled, region kept but inactive when disabled), which is useful for predicting side effects. It does not address edge cases such as invalid beat ordering, transport state dependencies, or whether enabling the loop affects the current playhead position.

  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 main action, followed by behavioral details and per-parameter definitions. Every line serves a purpose, with no filler or redundant restatement of the schema titles.

  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 an output schema, this description is largely complete: it covers the operation, enable/disable behavior, and parameter semantics. It lacks prerequisites or transport interactions, but these are not critical for such a focused loop-setting 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?

  Schema description coverage is 0%, so the description fully compensates by defining each parameter: 'from_beat: Loop start in beats,' 'to_beat: Loop end in beats,' and 'enabled: Whether loop is active.' It adds meaning beyond the bare integer/boolean types, though it omits details like inclusive/exclusive bounds or valid ranges.

  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 begins with a clear, specific action: 'Set the playback loop region.' It then explains the behavior with enabled/disabled states, making the tool's function unambiguous. However, it does not explicitly distinguish this from the similarly named sibling mcp_opendaw_set_region_loop, so it stops short of a perfect 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?

  The description implies when to use this tool: when you need to configure playback looping between two beats, and it explains how to disable the loop. It does not, however, provide explicit 'when not to use' guidance or mention alternative tools like mcp_opendaw_set_region_loop for per-region looping, leaving usage context inferred rather than stated.

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

• mcp_opendaw_set_marker_positionA
  3.7/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 tool mutates a marker ('Move') but does not disclose what happens with an invalid index, whether the original position is replaced, if values are validated, or if the operation is reversible. This is a significant 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 a single front-loaded purpose sentence followed by two compact parameter lines. Every sentence earns its place; there is no fluff or repetition. Appropriately sized for a 2-parameter tool.

  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 tool is simple with 2 required integer params and an output schema, so the return value need not be explained. The description covers the core purpose and both parameters, but misses edge-case behavior, prerequisites (marker must exist), and any relation to sibling marker tools. Adequate but with clear 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 compensate. It does: marker_index is explained as the 0-based index from list_markers, and position_beats is explained as the new position in beats. Both parameters gain meaningful context beyond the bare integer types, though no ranges or constraints are given.

  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 uses a specific verb+resource: "Move a timeline marker to a new position." This clearly distinguishes it from siblings like add_marker, delete_marker, list_markers, set_marker_label, and set_marker_repeat. The intent 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?

  The description implies usage workflow via 'marker_index: Index from list_markers (0-based)', hinting that list_markers should be called first. However, it does not explicitly state when to use this tool vs alternatives, nor provide any exclusions or 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.

• mcp_opendaw_set_tidal_rateA
  3.7/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 disclose behavior. It offers parameter constraints and allowed values but omits any details on side effects, error conditions, reversibility, or return values. Lacks the behavioral disclosure expected 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.

  Conciseness4/5

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

  The description is fairly concise with a clear first sentence, followed by parameter explanations. The list of rate values is necessary but somewhat verbose; still, it is structured and 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 the core parameters and allowed values, but lacks guidance on usage context, error handling, and aftermath of the operation. Given the tool's simplicity and absence of annotations, it 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.

  Parameters5/5

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

  All three parameters are explained beyond the schema: unit_index as AU index, effect_index with the Tidal requirement, and rate with an explicit allowed list of musical fractions. This 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?

  Clearly states the action (Set LFO rate), the target (Tidal effect), and the input type (musical fraction string). This distinguishes it from sibling tools that set other effect parameters.

  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?

  Provides parameter constraints (must be a Tidal) but does not explicitly state when to choose this over other effect-setting tools or mention alternatives. Usage is implied but not directed.

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

• mcp_opendaw_transpose_notesA
  3.7/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 transparency burden. It discloses helpful behavior: the return value (counts of transposed and skipped notes) and that notes out of MIDI range 0-127 are skipped rather than clamped. However, it omits details like whether the operation is reversible/undoable or what happens to note velocity/duration, leaving some behavioral 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 description is compact and well-organized: a one-line purpose, then per-parameter explanations, then return value. Every sentence adds value, and the structure makes the information easily 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?

  Given the tool's complexity (4 params, no annotations), the description covers the key operational context: parameter semantics, scope defaults, and return value. It lacks discussion of edge cases like overlapping notes or undo behavior, but these are not necessary for basic usage, so it 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?

  Schema coverage is 0%, so the description fully compensates by explaining each parameter: semitones with sign and examples, and unit_index, track_index, region_index with -1 defaults and scoping meanings. This adds substantial meaning beyond the bare schema titles.

  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 ('Transpose all notes') and the resource ('notes') with the specific parameter 'semitones'. It is distinct from siblings like 'diatonic_transpose_notes' by emphasizing semitones, but it does not explicitly differentiate them, so it falls just 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?

  The description provides parameter semantics (e.g., -1 meanings) which imply how to scope the operation, but it gives no explicit guidance on when to use this tool versus alternatives (e.g., diatonic_transpose_notes). There is no 'use when' or exclusionary context, so no real usage direction beyond the operation itself.

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

• mcp_opendaw_validate_projectA
  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 disclosure burden. It discloses the return type ('valid (bool)') and that it returns issue details, and implies a non-destructive check. It does not explicitly state side effects or error behavior, but for a validation tool 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 extremely concise: two sentences that front-load the purpose and clearly state the return value. No wasted words or redundant structural 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?

  The description covers the core behavior and return format, and the presence of an output schema fills in details about the 'details' object. It could be slightly more complete by mentioning whether validation covers any other criteria beyond overlapping regions, but it is sufficient for a simple validation 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, so the baseline is 4. The description does not need to explain parameter details because there are none, and the schema already confirms an empty properties object.

  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 ('check') and resource ('project'), and identifies the concrete validity criterion: overlapping regions on the same track. It is clear, though it does not explicitly distinguish itself from sibling tools like find_overlapping_notes or detect_problems.

  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 usage is implied: you use it to validate a project for overlapping regions. However, it gives no explicit guidance about when to prefer this over alternatives (e.g., find_overlapping_notes, get_project_state) and does not mention scenarios where it should not be used.

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

• mcp_opendaw_connect_modular_modulesA
  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 only states 'Returns success or error', without disclosing details about side effects, whether existing connections are replaced, permissions required, or error conditions. For a mutation tool, this is insufficient.

  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 sentence for the purpose, followed by a clean parameter list, and a closing return statement. All information is relevant and efficiently presented.

  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 6-parameter tool with no annotations, this description covers purpose, each parameter's role, and the return value. It lacks behavioral depth (side effects, error scenarios) and usage guidance, but the core essentials are present. The output schema exists, so return values need not be detailed further.

  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 listing all six parameters with explanatory text. It adds examples for connector names ('Output', 'Result', 'Input', 'X', 'Y'), which goes beyond the raw schema. Some descriptions (e.g., 'Audio unit index') are terse but still meaningful.

  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 'Connect two modules in a Modular device' and clarifies with '(create a patch cable)'. This clearly distinguishes it from sibling tools like list_modular_modules or add_modular_module.

  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 implication is clear: use this to connect modules. However, it does not explicitly state when to prefer this over alternatives, nor does it mention exclusions or related tools. The usage context is clear but not elaborated.

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

• mcp_opendaw_create_drum_soloA
  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 full transparency burden. It discloses the tool generates a structured solo with 'phrasing, build-ups, climax' and genre-specific patterns, and notes return values. However, it does not clarify whether the solo is inserted, appended, or overwrites existing notes, nor does it mention side effects on the current project state or which track/unit is targeted.

  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 well-structured: a concise lead, an explicit contrast with create_drum_fill, a detailed genre breakdown with clear formatting, and concrete usage examples. The genre details are contextually valuable and not redundant. It could be slightly tightened, but the length is justified by the tool's genre-dependent complexity.

  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 core concept, genre vocabulary, key parameters, and return value, with examples. However, the omission of three placement-related parameters (start_beat, unit_index, track_index) and the lack of detail about insertion behavior mean it is not fully complete for a 7-parameter tool with no annotations. The presence of an output schema mitigates the return-value gap, but side effects remain undisclosed.

  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 must compensate. It adds valuable semantic detail for solo_type (lists all five genres with style descriptions), bars (range 2-16), velocity (range 0-1 with loudness note), and seed (PRNG reproducibility). However, it completely omits start_beat, unit_index, and track_index, which are likely essential for placement in the DAW project.

  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: 'Create a genre-specific drum solo with rudimental vocabulary.' It explicitly contrasts itself with create_drum_fill ('short transition') and clearly states it creates a full multi-bar solo. This unambiguously differentiates the tool from similar 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?

  The description explicitly names an alternative: 'Unlike create_drum_fill (short transition), this tool creates a full multi-bar solo.' This provides clear when-to-use guidance. However, other solo-related siblings like create_solo and create_soli are not addressed, so it is not a comprehensive exclusion list.

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

• mcp_opendaw_create_garage_arrangementA
  3.8/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 does disclose the output structure (4 tracks with offsets), musical patterns, and default key. However, it omits important operational behavior such as whether existing notes on those tracks are overwritten, whether new tracks are created automatically, or how the tool interacts with the current project state. This leaves meaningful gaps in predicting 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 well-structured with a clear lead sentence, a bulleted genre overview, and a numbered track breakdown. It is a bit longer than necessary due to genre background (e.g., 'smooth, bumping, after-hours energy'), but the structure makes it scannable and the content is largely pertinent to understanding the tool's musical output.

  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?

  This is a complex tool that generates a full 4-track arrangement, and the description covers the musical essence well—track roles, rhythmic patterns, voicings. However, it leaves out several parameter behaviors (bars, velocity, start_beat, unit_index) and does not mention any operational constraints or side effects. Given the complexity and lack of annotations, the description 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.

  Parameters3/5

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

  The input schema has 0% coverage (no parameter descriptions), so the description must compensate. It provides some meaning for bpm (default 130 and genre-typical 130-138), key_root (default G minor), and track_index (used to place the 4 tracks). But it does not explain bars, velocity, start_beat, or unit_index, which are all essential for controlling the arrangement. This partial coverage earns a mid-level score.

  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: 'Create a UK garage arrangement', and elaborates with genre-defining characteristics and a breakdown of the 4 tracks created. This clearly distinguishes it from sibling tools like create_house_arrangement or create_trap_arrangement by explicitly naming the genre and its signature patterns.

  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 establishes clear context for when to use the tool—when a UK garage arrangement is requested—and educates the agent on genre specifics (2-step, swing, BPM range, track layout). However, it does not explicitly name alternatives or state when not to use it, leaving some inference to the agent based on the tool name and sibling context.

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

• mcp_opendaw_create_hemiolaA
  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 behavioral disclosure burden. It states that notes are created on a single track, primary and secondary groups use respective pitches, and both span the same total duration. It also mentions return values. However, it does not disclose potential side effects like overwriting existing notes or error behavior for invalid parameters.

  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 well-structured: definition, pattern explanation, behavior, parameter list, return value, and example. It is longer than necessary due to cultural/historical references (Brahms, Bernstein, Glass), but these do add musical context. Overall, the structure is logical and the 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 complex tool with 10 parameters and no annotations, the description is quite complete: it explains the musical concept, pattern semantics, all parameters with defaults, return value, and gives an example. Minor gaps remain around exact note placement details and distinguishing from similar polyrhythm/cross-rhythm tools, but it is generally 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%, but the description fully compensates by explaining every parameter with context: pattern values, bars range (1-4), beat units, pitch defaults (60=C4, 64=E4), velocity ranges (0-1), and duration meaning. This adds significant meaning 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 the tool creates a hemiola with a specific 3:2 rhythmic displacement, using specific verbs and the resource type. It explains the concept and pattern variants, but does not explicitly differentiate from sibling tools like create_polyrhythm or create_cross_rhythm.

  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 musical context and pattern options (3:2 vs 2:3), implying when a hemiola might be used. However, it lacks explicit guidance on when to use this tool instead of similar rhythm tools, and no exclusions or alternative tool references are provided.

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

• mcp_opendaw_create_neurofunk_arrangementA
  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 full burden of behavioral disclosure. It carefully details the four tracks, their musical content, defaults, and return value ('Returns notes created per track and total'). However, it does not explicitly state whether existing tracks are overwritten, how start_beat interacts with the arrangement start, or what side effects unit_index has, leaving some 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.

  Conciseness4/5

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

  The description is well structured with clear sections: overview, genre characteristics, track breakdown, parameter list, and examples. The genre bullet points are somewhat lengthy but provide valuable stylistic context for generating authentic neurofunk; every sentence serves a purpose and the front-loaded summary is effective.

  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 thoroughly covers creative output, genre conventions, parameter defaults, ranges, and example invocations. However, critical gaps remain: velocity, start_beat, and unit_index are unexplained, and the tool's behavior regarding track creation (new vs. existing) is not clarified. Given the tool's complexity (11 params, 4 tracks), the description is helpful but not fully complete.

  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?

  The description explicitly explains bpm, bars, root, and octave with defaults and ranges, and infers the track-index parameters via the numbered track list (drum_track, bass_track, reese_track, stabs_track). However, velocity, start_beat, and unit_index receive no explanation, leaving 3 of 11 parameters undocumented—a significant gap given the schema itself has zero 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 opens with a specific verb+resource+scope: 'Create a full neurofunk DnB arrangement — 4 tracks: drums + sub-bass + Reese + stabs.' It clearly delineates the tool's function and distinguishes it from sibling genre-arrangement tools by naming the neurofunk style and the exact track structure.

  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 context for when to use the tool: when a neurofunk DnB arrangement is desired, with BPM, key, and bar ranges. It does not explicitly name alternative tools (e.g., create_liquid_dnb_arrangement) or state when not to use it, but the genre-specific detail effectively implies the usage scenario.

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

• mcp_opendaw_create_note_trackA
  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 creation action but does not mention side effects, prerequisites (e.g., whether the AU must exist), consequences of invalid indices, or whether the operation is reversible. The parameter hint about instrument AU types adds some context, but it is insufficient 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 two sentences with no wasted words. It front-loads the purpose and then provides essential parameter guidance in a compact, readable format. Every sentence 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 simple one-parameter tool with an output schema, the description covers the essential invocation details but lacks edge-case behavior (e.g., what happens if the unit_index is invalid or no synth is found). It is adequate but not fully comprehensive, especially given the absence of annotations.

  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 sole parameter unit_index: its default (-1), meaning (audio unit index), and valid selection criteria (primary or instrument AU with synth devices). This adds meaning far 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 clearly states the tool's function: 'Create a new note/MIDI track on an audio unit.' The verb 'create' is specific, the resource ('note/MIDI track') is defined, and it distinguishes from sibling tools like create_audio_track and create_synth_track by emphasizing the note/MIDI nature.

  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 parameter usage context (unit_index: -1 for primary AU or an instrument AU index), but does not explicitly explain when to use this tool versus alternatives like create_synth_track or create_instrument_track. The when-to-use is implied by the name and purpose, but no exclusions or comparisons are provided.

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

• mcp_opendaw_create_polyrhythmA
  3.8/5.0
  Behavior3/5

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

  With no annotations, the description discloses useful behavior: it creates notes on a single track, spans the same total duration, and returns note count and ratio. However, it does not mention prerequisites (e.g., an existing note track), whether notes are added or replace existing content, or error handling, so the behavioral picture is incomplete.

  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 lengthy but well-organized: definition, parameter details, return value, common ratios, and example. The parameter list and examples are useful, though the common polyrhythms section is somewhat optional. It is structured enough to navigate without being wasteful.

  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 11 parameters, no annotations, and a rich musical concept, the description covers the core functionality well: concept, parameter semantics, common uses, and an example. It lacks prerequisites and error conditions, but the provided information is sufficient for typical use. An output schema exists, so the 'Returns' line is a bonus, not a necessity.

  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. It thoroughly explains every parameter, including ranges, defaults, and musical meaning (e.g., primary_count=3 in a 3:4 polyrhythm, pitch defaults with note names). This adds substantial meaning 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 the tool creates a polyrhythm with two simultaneous rhythmic streams, which is specific and unambiguous. It explains the concept and key parameters, but does not explicitly distinguish from similar sibling tools like create_cross_rhythm or create_metric_modulation, so it falls 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?

  The description provides musical context (jazz, electronic, African, progressive) and defines when a polyrhythm is appropriate, but it does not explicitly state when to use this tool over alternatives or mention any exclusions. Usage is implied rather than directly contrasted with sibling tools.

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

• mcp_opendaw_create_reggae_percussionA
  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 full burden and does disclose key behaviors: it creates notes on a specified track_index using specific GM percussion pitches, and explains how swing offsets off-beat hats. However, it does not clarify whether existing notes are overwritten, how tempo_bpm interacts with style-specific BPM ranges, or what unit_index means, leaving notable behavioral gaps.

  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 and organized as a readable list of styles with consistent formatting. While the historical context sentence and detailed per-style BPM ranges add some length, the information is relevant and earns its place, with only minor 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?

  The description is rich for the core purpose—it explains all six styles, swing behavior, and target pitches—but it omits semantics for several parameters (bars, velocity, start_beat, unit_index) and does not clarify the relationship between tempo_bpm and style-defined BPM ranges. Given the tool’s complexity and optionality, the description is helpful but not fully complete.

  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?

  Since schema coverage is 0%, the description must compensate for missing property descriptions. It explicitly defines the style values, swing range, and track_index, and lists the GM pitches used, but leaves bars, velocity, tempo_bpm, start_beat, and unit_index unexplained, so it only partially covers the parameter space.

  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 clear, specific statement: 'Create Jamaican reggae percussion patterns across 6 styles.' It names the resource (reggae percussion) and the action (create), and the detailed style list distinguishes it from sibling genre-creation tools like create_reggae_arrangement and create_clave.

  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 context by enumerating six reggae styles with characteristics and tempo ranges, which implicitly tells the user when to select each style. However, it does not explicitly compare alternatives or state when to use this over sibling tools like create_reggae_arrangement or create_drum_pattern.

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

• mcp_opendaw_evaluate_rawA
  3.8/5.0
  Behavior1/5

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

  The description says 'Execute arbitrary JavaScript in the DAW V8 context,' which implies full access to potentially destructive operations, while the annotations declare readOnlyHint=true. This is a direct contradiction: the tool may not be read-only. The description does add useful context about script wrapping and access to globals, but the contradiction forces a score of 1 per the rules.

  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 sentences, front-loaded with the core purpose, followed by use-case context and a clearly labeled parameter explanation. Every sentence earns its place with 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?

  Given the tool's high complexity (arbitrary JS execution) and the presence of an output schema, the description adequately covers purpose, usage, script format, and available globals. It lacks explicit warnings about side effects or error handling, but the 'power users and debugging' framing partially covers the risk. The annotation contradiction is a separate issue, so this dimension remains at a 4.

  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 a 'script' string with 0% description coverage, so the description must compensate. It does: it explains that the script must be a function body wrapped in an async arrow, and that it has access to window.DAW and DAW_ globals. This adds meaningful semantics beyond the raw schema, though it stops short of examples or edge cases.

  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: 'Execute arbitrary JavaScript in the DAW V8 context and return the result.' It clearly distinguishes this tool from musical/DAW operation siblings by emphasizing arbitrary script execution. The intended use case (power users and debugging) further clarifies its purpose.

  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 context for when to use the tool ('For power users and debugging — explore openDAW internals directly'), which implies it is for low-level inspections not covered by higher-level tools. However, it does not explicitly mention alternatives or exclusionary conditions, so it earns a 4 rather than a 5.

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

• mcp_opendaw_get_script_device_codeA
  3.8/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, and the description adds context by specifying the exact output components (full code string, header line, code length). It does not disclose side effects or error conditions, but for a read operation this is largely covered by annotations and the return description.

  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: two sentences front-load the primary action and return value list. No filler or repetition of schema fields.

  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 read tool, the description specifies the resource and return payload, and annotations cover safety. However, the lack of parameter documentation (0% schema coverage) leaves gaps in how to invoke the tool correctly, and no prerequisites are mentioned. Overall adequate but incomplete for correct invocation.

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

  Parameters2/5

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

  The input schema has three parameters with zero description coverage, and the tool description does not explain the meaning or valid values of device_type, unit_index, or device_index. Since the description does not compensate for the missing schema documentation, an agent must guess the parameter semantics from names alone.

  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 the specific verb 'Read' and identifies the exact resource ('current user JavaScript code from a scriptable device'), clearly distinguishing from sibling tools like mcp_opendaw_set_script_device_code. It also outlines the returned data, making the tool's function 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?

  The description implies usage for reading script code but does not explicitly state when to prefer this over alternatives or provide exclusions. No mention of the set counterpart or conditions under which to use this tool. The context is clear but not decision-oriented.

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

• mcp_opendaw_list_script_samplesA
  3.8/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description discloses useful behavioral details: each slot is a WerkstattSampleBox with label, index, and a file pointer, and the pointer is null until a sample is loaded. This adds meaningful context about the return structure and null-state 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, with three sentences that each add value: the main purpose, the slot structure, and the auto-creation/null behavior. It is appropriately front-loaded and free of 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?

  The description covers the domain concepts and return semantics well, and the presence of an output schema helps with the return side. However, the complete lack of parameter explanations leaves a significant gap in how to invoke the tool, especially with three required parameters and no schema descriptions.

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

  Parameters1/5

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

  The schema descriptions cover 0% of the three required parameters, and the description does not compensate. It mentions 'scriptable device' but never explains how device_type, unit_index, or device_index map to that concept. The agent is left with no guidance on how to fill the required arguments.

  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 'List @sample declaration slots on a scriptable device', which uses a specific verb and resource, and distinguishes this tool from siblings like mcp_opendaw_list_samples by focusing on @sample declarations and scriptable devices. The additional details about WerkstattSampleBox slots make the scope 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 provides clear context for when to use the tool (inspecting sample slot declarations on a scriptable device) and clarifies that slots are auto-created from code declarations. It does not explicitly name alternatives or exclusion criteria, but the context is strong enough to guide tool selection.

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

• mcp_opendaw_move_automation_eventA
  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 mentions the return value ('Returns success with old and new positions') but does not disclose potential errors, side effects, reversibility, or prerequisites beyond the implied index. For a mutating tool, this is insufficient 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 concise and front-loaded with the purpose, followed by parameter definitions and return behavior. Every sentence is informative, with no waste 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?

  The description covers the essential purpose, parameters, and return value, making it moderately complete. However, with no annotations, it lacks guidance on error handling, invalid indices, or any behavioral constraints. The output schema exists, but the description could do more to explain what 'success' entails and any side effects.

  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 each parameter's meaning, including the source for event_index and the type of new_position_beats. This adds significant meaning beyond the schema's bare property titles.

  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 'Move an automation event to a new position on the timeline,' which clearly states the specific verb and resource. This distinguishes it from sibling tools like delete_automation_event or update_automation_event, which focus on other aspects of automation events.

  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 noting 'event_index: Event index (from list_automation_events),' indicating a prerequisite workflow. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, so usage guidance is only 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.

• mcp_opendaw_remove_midi_effectA
  3.8/5.0
  Behavior2/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 of behavioral disclosure. It mentions 0-based indexing, but does not state whether the removed effect is permanently deleted, what happens if the index is out of range, whether the operation is reversible, or if subsequent effect indices shift. For a destructive 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.

  Conciseness5/5

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

  The description is extremely concise: two sentences plus two parameter lines, all front-loaded and directly relevant. Every word adds value, with no redundant explanations 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 tool with two integer parameters and an output schema, the description covers the core operation and parameter meanings. It omits practical context like verifying the effect exists or noting index shifting after removal, but the presence of an output schema and the tool's low complexity make this 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?

  Schema description coverage is 0%, but the description compensates by defining both parameters: unit_index as 'Audio unit index' and effect_index as 'MIDI effect position to remove (0-based)'. This adds essential meaning beyond the raw schema property titles, clarifying the 0-based nature of the index.

  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 'Remove a MIDI effect from an audio unit's MIDI chain' uses a specific verb (remove) and clearly identifies the target resource and container. It distinguishes this from sibling tools like remove_effect (audio effects) and add_midi_effect, making its 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?

  The description states what the tool does but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like list_midi_effects for obtaining valid indices or remove_effect for audio effects. Usage is implied by the name and purpose but not explicitly contrasted with alternatives.

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

• mcp_opendaw_save_effect_presetA
  3.8/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 mentions output_path and its default, but does not state whether existing files are overwritten, whether directories are created, or any permission requirements. The internal reference to PresetEncoder.encodeEffects() adds implementation detail but not side-effect transparency.

  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 efficiently structured: a one-line summary, a brief implementation note, and a parameter list. The mention of PresetEncoder.encodeEffects() is slightly extraneous, but the overall size is appropriate and front-loaded with the main action.

  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 complexity (5 parameters, output schema present), the description covers core semantics and defaults effectively. It omits details like overwrite behavior and precise return values, but the output schema exists and the parameter explanations are sufficient for typical use.

  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 compensate. It fully explains each parameter: unit_index, effect_index, name, description, and output_path, including the default behavior for output_path. This adds essential meaning beyond the bare schema properties, making parameter usage 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 description clearly states it saves an audio effect as a .opb preset file, with a specific verb and resource. The phrase 'audio effect chain' is slightly ambiguous (it saves a single effect), but the next sentence clarifies it encodes the specified effect and its position. It doesn't explicitly distinguish from sibling tools like export_effect_chain, but mention of the load counterpart adds 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?

  The description gives a clear use case: the file can be shared, drag-and-dropped, or loaded via mcp_opendaw_load_effect_preset. It provides context for when to use the tool, but lacks explicit exclusions or comparison to alternatives like export_effect_chain. The 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.

• mcp_opendaw_set_bus_colorA
  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 full burden for behavioral disclosure. It does state 'Returns success or error.' revealing the return type, and specifies the hue range and HSL color model. However, it does not disclose side effects, mutation of existing state, or potential errors beyond a generic success/error, which is a moderate transparency gap for a simple 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 well-structured. It front-loads the primary action in the first sentence, then neatly lists parameter definitions, and concludes with the return type. Every sentence adds value, and there is no redundant or vague 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 simple setter with two parameters and an output schema, the description is largely complete. It covers the action, parameter semantics, and return type. The only minor gaps are lack of prerequisite context (e.g., bus existence) and any note about the color model beyond hue, but these are not critical given the tool's simplicity.

  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 must compensate. It provides brief parameter definitions: 'bus_index: Bus index. hue: Color hue 0-360 (HSL).' These add meaning beyond the raw schema, clarifying the hue range and color model. However, details like bus_index indexing base (0 or 1-based) and valid ranges are missing, so compensation is only partial.

  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 with a specific verb and resource: 'Set the color (hue 0-360) of an audio bus.' This distinguishes it from sibling tools like set_bus_label or set_bus_enabled, 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?

  The description implies when to use the tool (when needing to change a bus color) but provides no explicit guidance on when not to use it, prerequisites (e.g., bus must exist), or alternatives. No sibling tools are referenced for cross-comparison, so usage context is minimal but inferable from the action.

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

• mcp_opendaw_set_marker_labelA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided. The description only states the operation is a rename, without disclosing side effects, error behavior on invalid indices, or whether changes are persistent. As a mutation tool with no annotations, the burden falls on the description, which remains 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 concise and well-structured: one summary line followed by bullet-style parameter explanations, 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 rename tool with an output schema present, the description covers the core workflow. It does not address error cases (e.g., invalid index) but is adequate 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?

  Schema description coverage is 0%, but the description compensates by explaining marker_index is obtained from list_markers and is 0-based, and label is the new text. This 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 uses 'Rename a timeline marker' – a specific verb and resource that clearly distinguishes from sibling marker tools like add_marker, delete_marker, and set_marker_position. It is direct and 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?

  The description provides a usage hint via 'marker_index: Index from list_markers (0-based)', implying the index should come from list_markers, but it does not explicitly state when to prefer this over alternatives or provide exclusions. Basic workflow hint but no explicit guidance.

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

• mcp_opendaw_set_playfield_sample_enabledA
  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 explaining side effects. It clearly states that setting enabled to false mutes the pad, and explains the auto-detect behavior of unit_index. However, it does not disclose return values, error conditions, or whether the operation is reversible, leaving some behavioral aspects unknown.

  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 highly concise: a single-sentence summary followed by three bullet-point parameter explanations. Every sentence earns its place with no redundant or irrelevant content.

  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?

  Given the simple nature of the tool and the presence of an output schema, the description covers the core action and parameters adequately. However, it lacks usage context (when to use vs. siblings) and preconditions (e.g., whether the unit must already exist), making it not fully complete for an agent selecting the 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?

  The input schema provides no descriptions (0% coverage), but the description compensates fully by explaining each parameter: sample_index is a 0-based pad index, enabled toggles enable/mute, and unit_index supports -1 for auto-detect. This adds clear 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 uses a specific verb ('Enable/disable') and clearly identifies the resource ('a drum pad on a Playfield drum machine'). It distinguishes the tool from sibling tools like list_playfield_samples and create_playfield_sample by indicating its 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 provided on when to use this tool versus alternatives, nor any exclusions or prerequisites. It does not mention related tools such as create_playfield_sample or list_playfield_samples, leaving the agent to infer the appropriate context.

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

• mcp_opendaw_set_region_colorA
  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 full burden of behavioral disclosure. It reveals that the tool returns old and new hue values, describes the unit_index behavior (-1 = search all AUs), and notes that regions/clips use an Int32Field. However, it does not mention potential side effects, error conditions, or reversibility. For a simple setter, this is moderate transparency, but more detail could be provided.

  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 well-structured and front-loaded with the primary action. It includes helpful context and parameter details without excessive verbosity. The examples are useful and earn their place. Slightly longer than strictly necessary, but concise enough for the information conveyed.

  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, the description covers most essential context: purpose, parameter semantics, usage examples, and return values. It references the output ('Returns old and new hue values'), fulfilling the return value disclosure since an output schema exists. It doesn't discuss edge cases or error handling, but for a basic setter, the description is largely complete for an agent to decide and execute.

  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. It does excellently: each parameter (track_index, region_index, hue, unit_index) is explained with meaning, ranges, and examples (e.g. '0=red, 120=green, 240=blue'). This fully covers the semantic gap left by the schema, providing the agent with all necessary context to invoke 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 clearly states 'Set the color (hue) of a region or clip' with a specific verb and resource. It explains the hue system and gives examples, making the purpose unambiguous. However, it does not differentiate from the sibling tool 'mcp_opendaw_set_clip_hue', which may have overlapping functionality, so it loses a point for lack of 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 provides usage context ('Use this to visually distinguish sections, e.g. red for choruses, blue for verses') and explains the hue scale. It implies when this tool is appropriate but does not explicitly state when to use it over alternatives like 'set_clip_hue' or provide exclusions. This is adequate but not fully explicit.

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

• mcp_opendaw_set_send_levelA
  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 must carry the full behavioral disclosure burden. It states that the tool sets a send level but does not mention any side effects, constraints on level_db (e.g., range or clipping), error conditions for invalid indices, or what the tool returns. The description adds minimal behavioral context beyond the core 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: one purpose sentence followed by two-sentence parameter definitions. It is front-loaded with the action and then provides exactly the needed parameter semantics. No waste, every 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?

  Given that this is a simple setter with an output schema, the description provides sufficient operational details: what the tool does, what each parameter means, and a hint about obtaining send_index from create_send. The main gap is behavioral transparency (covered separately), but for executing the call correctly, the description is largely 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 has 0% description coverage, so the description must compensate. It fully explains each parameter: src_unit is the source audio unit index, send_index is the send index obtained from create_send return, and level_db is the send level in dB. This is useful and goes beyond the bare schema, though it omits any range or constraint 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 clear action: 'Set the send level for an existing aux send.' This uses a specific verb ('set'), identifies the resource ('send level'), and scopes it to 'aux send.' It clearly distinguishes from sibling tools like set_send_pan and set_send_routing, which address different aspects of sends.

  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 'for an existing aux send' implies that the send must already have been created, and 'send_index ... from create_send return' provides a workflow hint. However, there is no explicit guidance on when to choose this tool over alternatives (e.g., set_send_pan for panning) or mention of exclusions. Usage is implied rather than directly stated.

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

• mcp_opendaw_create_afrobeat_arrangementA
  3.9/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. It does reveal the behavioral output: notes created per track, total, the four track roles, and default tempo/bars/root. However, it does not state whether existing notes on the target tracks are overwritten or appended, nor does it mention required preconditions like the engine being running or tracks needing to exist. This leaves some important side-effect ambiguity for a create/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.

  Conciseness3/5

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

  The description is front-loaded with a clear overview and uses a structured bullet list for tracks. The example block is useful. That said, it is somewhat verbose with repeated stylistic flourishes (e.g., 'polyrhythmic heartbeat,' 'Fela's preference') and could be tightened without losing the essential genre context.

  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 high-complexity tool with 11 parameters and no annotations, the description is above average but not complete. It covers most parameters and includes an output summary, but it omits velocity and start_beat semantics, and does not clarify whether the tool adds to or replaces existing notes on the target tracks. More explicit preconditions would make it fully self-sufficient.

  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 documents 9 of 11 parameters with helpful musical meaning: bpm range (100-130, default 120), bars (8-32), root (F as Fela's key), octave (C2=36), unit_index, and track indices. It also provides a usage example. However, it omits 'velocity' and 'start_beat', which are left entirely to the schema's bare defaults.

  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 is explicit: 'Create a full afrobeat arrangement — polyrhythmic drums + bass + horns + guitar across 4 tracks.' This identifies the verb ('create'), the resource ('afrobeat arrangement'), and its core components. It also distinguishes itself from sibling genre-arrangement tools by emphasizing the non-electronic, 4-track organic texture.

  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 strong context for when this tool is appropriate: Fela Kuti-style afrobeat, 120 BPM, 12/8 feel, and the contrast with electronic arrangements ('horns and guitar add organic texture that electronic arrangements don't have'). It lacks explicit exclusions or direct alternatives, but the genre context is clear enough for selection among many arrangement siblings.

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

• mcp_opendaw_create_blues_arrangementA
  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 mentions that notes are created and returns the count, but it does not disclose whether the tool overwrites existing notes on the specified tracks, whether tracks must pre-exist, or whether it is additive. This is a notable 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.

  Conciseness3/5

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

  The description is heavily padded with music-theory background—shuffle feel, blue notes, 12-bar history—that is educational but not strictly necessary for tool invocation. While well-structured with headings and parameter list, the extra prose makes it longer than needed; a more concise version would be equally effective.

  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 11-parameter tool with no annotations and no visible output schema, the description covers the core parameters, defaults, and return value. However, it is incomplete on operational expectations: it doesn't state prerequisites like whether tracks already exist, how existing notes on those tracks are handled, or what happens if track indices are invalid. Given the complexity, these gaps prevent a higher score.

  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 no parameter descriptions (0% coverage), so the description compensates by explaining most parameters: bpm, bars, root, octave, unit_index, and track indices. It adds crucial meaning like 'bars must be multiple of 12' and 'bpm 70-160', but omits velocity and start_beat entirely, leaving those two parameters undocumented.

  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 'Create a full blues arrangement' and enumerates concrete components (shuffle drums, walking bass, dominant 7th chords, blues scale lead), making the tool's purpose unmistakable. It also distinguishes itself from sibling genre-arrangement tools by explicitly naming blues-specific elements.

  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 context for when to use the tool (creating blues arrangements) and includes examples for different tempos and roots, showing usage flexibility. However, it does not explicitly state when not to use it or name alternatives, such as other genre-arrangement tools.

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

• mcp_opendaw_create_claveA
  3.9/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 transparency and delivers detailed behavioral information: exact beat positions for each clave type, return values, and parameter meanings. However, it does not disclose potential side effects like whether existing notes are overwritten or how the pattern interacts with the target track.

  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 well-structured, front-loaded with a clear purpose, and uses bullet lists and examples effectively. It is somewhat long and includes minor redundancy (e.g., all bars defaults are 2), but every section adds value.

  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 core concept and most parameters, and the output schema handles return values. However, it misses start_beat and unit_index semantics, and does not explain how the pattern is placed in the project or whether it clears existing notes, which is a notable gap for a complex 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 description richly explains clave_type with beat mappings for all six variants, and gives meaning to bars, pitch, velocity, and duration. However, start_beat and unit_index are not described, and track_index only appears in examples, leaving a few parameters without semantic coverage.

  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 it creates an Afro-Cuban clave pattern and explains it is a timeline pattern, not a drum pattern. This gives a specific verb+resource, but it does not explicitly distinguish itself from sibling tools like create_tumbao or create_drum_pattern beyond the musical concept.

  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 strong musical context, explaining that the clave is the rhythmic skeleton all other rhythms align to and that every Afro-Cuban rhythm has a direction. This implies when to use the tool, but it does not explicitly state when not to use it or name alternatives.

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

• mcp_opendaw_create_disco_arrangementA
  3.9/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 for operational behavior. It describes the musical content in detail and says 'Returns notes created per track and total,' but it never discloses whether existing notes on the target tracks are overwritten or cleared, and it assumes a unit with note tracks exists without stating that prerequisite. For a mutating tool, this is 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 long but well-organized: a one-sentence summary, then track-by-track breakdown, progression, tempo, parameter list, return note, and examples. The detail helps distinguish it from the many sibling genre arrangements, but some of the genre-history comparisons could be trimmed without losing needed guidance.

  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 complexity (4 tracks, 11 parameters, genre-specific behavior), the description is quite complete: it specifies musical content, progression, rhythms, parameter constraints, and the return value. It is missing only operational behavior around overwriting and prerequisites, which prevents a perfect score.

  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 well: bpm range and default, bars must be multiple of 4, root note context, octave meaning, unit_index, and all four track indices are explained with musical rationale plus example calls. However, velocity and start_beat are not mentioned, so coverage is not total.

  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: 'Create a full disco arrangement' and details exactly what it produces across four tracks. It strongly distinguishes itself from siblings by repeatedly contrasting disco with house and other genres ('fundamentally different from house', 'the fundamental differences from all 13 other arrangements').

  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 it clear this is the disco tool through genre comparisons and names the track roles, but it never explicitly states 'use this when you want a disco arrangement' or lists when not to use it. Context is clear, yet no formal exclusions or alternative tool names are given, 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.

• mcp_opendaw_create_electronic_bassA
  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 richly details the rhythmic patterns for each genre (e.g., 'sustained notes on the "&" of each beat'), providing transparency about the output musical behavior. However, it doesn't disclose whether it creates a new note region, overwrites existing notes, or requires an existing track, and it leaves track_index/unit_index semantics unexplained.

  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 appropriately sized for a complex tool. It starts with a concise purpose, then uses a compact bullet-style list for the six bass_type options, a brief parameter list, return info, and examples. Every line adds value, and the length is justified by the need to explain genre-specific patterns.

  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 tool has 8 parameters and no schema descriptions, and the description covers the musical core but leaves three technical parameters (start_beat, unit_index, track_index) undefined. This is a significant gap for correct invocation, though the presence of an output schema may partially cover return-value expectations.

  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 coverage is 0%, so the description must compensate. It explains bass_type (with six detailed options), bars, root, octave, and velocity, but omits start_beat, unit_index, and track_index. The examples use track_index without defining it, which could confuse an agent trying to invoke 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?

  The description clearly states 'Create an electronic bassline pattern — genre-specific bass for dance music,' specifying the verb, resource, and scope. It distinguishes this from melodic basslines by emphasizing rhythmic engine characteristics, and the genre-specific options (house, techno, dnb, dubstep, acid, garage) clearly separate it from sibling tools like create_bassline or create_walking_bass.

  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 context for when to use this tool: for electronic/dance music basslines that lock with the kick drum, contrasting them with melodic basslines. It implicitly guides the agent to use this for genre-specific rhythmic patterns, though it doesn't explicitly name alternative 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.

• mcp_opendaw_create_jazz_arrangementA
  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. It discloses the musical content in detail (ride pattern, walking bass, comping, horn lead) and mentions 'Returns notes created per track and total.' However, it does not state whether existing notes on the target tracks are overwritten, appended, or if any other side effects occur, leaving operational behavior ambiguous.

  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 well-structured with sections and line breaks, but it is verbose. It repeatedly emphasizes the 'fundamentally different' and 'signature' jazz elements across multiple sentences (e.g., re-explaining triplet feel and ii-V-I harmony). Some educational content could be trimmed without losing invocation-relevant information.

  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 11-parameter tool with no annotations, the description covers the core functionality and most parameters, plus a brief return-value note. However, it leaves out velocity and start_beat parameters, does not explain behavior with existing notes, and relies on an unseen output schema to clarify return structure. These gaps make it incomplete for fully 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 coverage is 0%, so the description must compensate. It explains most parameters with added meaning: bpm range (60-200), bars range (4-32), root note example (F for horns), octave example (F2=41), unit_index purpose, and the four track indices. However, it omits velocity and start_beat entirely, which are present in the schema with defaults but no 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 opens with a specific verb+resource+scope: 'Create a full jazz arrangement — swing drums + walking bass + comping piano + horn across 4 tracks.' It clearly distinguishes this from sibling genre arrangement tools by emphasizing jazz-specific elements like swing feel and ii-V-I harmony, and by naming the exact track roles.

  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 'Jazz with swing feel and ii-V-I harmony — fundamentally different from all other arrangements' and later reiterates that swing 8ths and ii-V-I set jazz apart. This implies when to use this tool (when a jazz arrangement is needed) and contrasts it with other arrangements, though it does not name specific alternatives.

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

• mcp_opendaw_create_montunoA
  3.9/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 disclose behavioral traits. It provides extensive musical theory and parameter explanations, but it does not describe the tool's operational behavior in the DAW: whether it creates a new note region or appends to an existing one, whether it overwrites notes, or what side effects it has on the track. The description even says 'Returns notes created, chord progression, and pattern info' but does not explain how the notes are placed or if any destructive action occurs. This is a significant transparency gap 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.

  Conciseness4/5

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

  The description is well-structured with clear sections: definition, differentiation, pattern types, rhythm options, and args. It is longer than average, but that is justified for a complex musical generation tool with 12 parameters. The front-loaded definition and contrast help quickly orient the reader. Some repetition of musical concepts could be tightened, but overall it earns its length.

  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?

  Given the complexity (12 params, no annotations, 0% schema coverage), the description does a good job covering parameter semantics and musical context. However, it lacks operational completeness: it does not explain DAW-level behavior such as which track/unit the pattern is written to, whether it is additive, or how start_beat interacts with the existing timeline. The output schema exists, so return values are not fully needed, but the missing behavioral context prevents a higher score.

  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 no parameter descriptions (0% coverage), so the description's 'Args:' section is the only documentation for all 12 parameters. It explains each parameter's purpose, with examples for chord_prog and clear definitions for pattern and rhythm values. This fully compensates for the schema's lack of textual descriptions and adds meaning beyond types/defaults.

  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's function: 'Create a montuno — a repeating Latin/jazz piano ostinato pattern.' It distinguishes this from related concepts like arpeggiators and ostinato patterns, making the purpose specific and well-scoped. The tool name 'create_montuno' is also descriptive, but the description adds real semantic content beyond the name.

  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 contrasts with arpeggiators and ostinato patterns: 'Unlike arpeggiators... or ostinato patterns... a montuno combines...' This gives clear guidance on when to choose a montuno over those alternatives. However, it does not name sibling tools like mcp_opendaw_create_ostinato or mcp_opendaw_create_arpeggio directly, nor does it discuss scenarios where another pattern generator would be preferred. The pattern and rhythm enumeration also gives context for selecting variants, but no explicit 'when-not to use' is stated.

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

• mcp_opendaw_create_rock_arrangementA
  3.9/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. It discloses the tracks created, optional keys track, and return value, but doesn't state whether existing notes on those tracks are overwritten or if specific prerequisites (such as pre-created tracks) are needed beyond the unit_index note.

  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 summary and then organized by track, but includes extended musical theory paragraphs (e.g., Beatles to AC/DC) that could be trimmed without losing essential info.

  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 complexity (11 params, 4 tracks) and presence of an output schema, the description provides extensive detail on arrangement structure, defaults, and examples. It lacks explicit side-effect warnings but covers most operational 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?

  Schema coverage is 0%, and the description compensates by explaining 9 of 11 parameters (bpm, bars, root, octave, unit_index, and track indices) with ranges and musical context. However, velocity and start_beat are left undocumented.

  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 'Create a full rock arrangement — rock beat drums + bass + power chords + riff across 4 tracks,' with a specific verb and resource. It distinguishes from sibling genre tools by detailing the rock-specific track layout and musical style.

  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 it (when a rock arrangement is needed) but doesn't explicitly contrast with sibling tools like create_reggae_arrangement or provide exclusions. It gives examples and parameter guidance but no '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.

• mcp_opendaw_create_tumbaoA
  3.9/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 behavioral traits. It explains the pattern characteristics and mentions it returns notes created, tumbao type, and stroke breakdown. However, it does not disclose side effects like whether it replaces existing notes, creates new regions, or has prerequisites such as a selected track.

  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: concise purpose, contextual background, parameter list, return value, and example. Each section earns its place, and the length is justified given the need to compensate for missing schema descriptions.

  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 tool has 9 parameters and no annotations, and the description covers most but not all relevant aspects. It omits clarifications for start_beat, unit_index, and track_index, and does not explain how the tool integrates with existing DAW state (e.g., whether it creates a new region or modifies an existing one). The output schema reduces the need to describe return values, but gaps remain.

  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?

  The schema has 0% description coverage, so the description must compensate. It explains tumbao_type, bars, low_pitch, open_pitch, slap_pitch, and velocity in detail, and track_index appears in the example. However, start_beat, unit_index, and track_index are not explicitly described, leaving a gap for those 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 states the tool's purpose: 'Create an Afro-Cuban tumbao (conga) pattern'. The verb 'create' is specific and the resource is well-defined, distinguishing it from sibling tools like create_clave or create_cascara by focusing on a tumbao specifically.

  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 context by explaining that tumbao is the rhythmic foundation of salsa and describes each tumbao_type variant. However, it does not explicitly compare with alternatives or state when not to use this tool, so it lacks explicit exclusions.

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

• mcp_opendaw_export_stemsA
  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 discloses that it uses OfflineEngineRenderer, includes effects, and returns a list of exported files. However, it does not mention side effects (e.g., file writes to disk, overwriting), prerequisites (e.g., engine running), or error conditions. This is neutral but 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 concise and well-structured: it starts with the core purpose, adds technical detail (OfflineEngineRenderer), states the return type, and ends with a workflow. Every sentence contributes value without verbose 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 tool with an output schema and moderate complexity, the description provides the essential workflow and return type. It does not explain file location, sample rate semantics, or potential pitfalls, but the output schema likely covers return values. This is slightly below complete but adequate for most use cases.

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

  Parameters2/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. The description only indirectly implies parameter use (filename_prefix, sample_rate) but does not explicitly explain their meaning or constraints. The parameter names are self-explanatory to some extent, but no additional semantics are provided, making this a weak spot.

  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's purpose: 'Export each audio unit as a separate stem WAV file.' This is a specific verb+resource combination that distinguishes it from sibling tools like export_mix or export_single_stem. The mention of per-AU export and effects included further clarifies the unique 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 provides a clear workflow (create_instrument_track(s) → load_audio → place_audio_region(s) → add_effect(s) → export_stems), which gives the user context on when to use this tool. However, it does not explicitly mention alternatives or when NOT to use it, so it falls short of the top score.

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

• mcp_opendaw_get_signature_eventsA
  3.9/5.0
  Behavior4/5

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

  The annotation readOnlyHint already signals a safe read operation. The description adds value by clarifying the default base signature (4/4) and the detail that PPQN positions are accumulated, which gives the caller insight into the data structure beyond the annotation.

  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 concise and front-loaded with the main purpose. Minor redundancy exists with two sentences both starting 'Returns', but the overall structure is efficient and easy to parse.

  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 read-only listing tool with an output schema, the description is fully complete. It explains the return structure including the base signature and the event fields (index, position, bars, nominator/denominator), providing the agent all necessary context to call and interpret 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?

  There are no parameters, so there is no parameter detail to add. The description appropriately focuses on return value semantics, which is sufficient since the schema has zero parameters and no ambiguity.

  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 lists all time signature change events and specifies the returned base signature and event fields. It is a specific verb+resource, though it does not explicitly distinguish itself from the sibling tool mcp_opendaw_list_signature_changes.

  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 time signature information from the project, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternatives. Given there are related tools like list_signature_changes, more direct comparison would have improved this score.

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

• mcp_opendaw_list_effectsA
  3.9/5.0
  Behavior3/5

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

  The annotation readOnlyHint=true already conveys the safety profile. The description adds that the tool returns a list of effect types, but nothing beyond that. Given the annotation coverage, 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?

  A single clear sentence, front-loaded with the action and resource. 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, read-only tool with an output schema, the description is complete. It states what is listed (audio and MIDI effect types) and the annotation covers safety. No additional context 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 are no parameter semantics to explain. The description is not burdened by parameter details, and the schema coverage is trivially 100%.

  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: 'List all available audio and MIDI effect types.' It clearly states what it returns and implicitly differentiates from sibling tools like mcp_opendaw_list_midi_effects by including both audio and MIDI.

  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 on when to use this tool versus alternatives. The sibling mcp_opendaw_list_midi_effects likely overlaps, but the description does not mention it or clarify when to choose one over the other.

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

• mcp_opendaw_schedule_clip_playA
  3.9/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 does not explain whether scheduling is immediate or queued, whether it affects transport, or what happens if a clip is already playing. The phrase 'live triggering' gives some context but leaves key behavior 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 two sentences plus an args definition, immediately stating the primary purpose and then clarifying the parameter. No redundant information, 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 tool has one parameter and a simple purpose, but the description lacks details about scheduling semantics (e.g., when the clips actually trigger, whether they stop previous clips). It is minimally adequate but leaves room for confusion in a DAW context where scheduling could imply timed behavior.

  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%, but the description compensates by explaining that clip_ids is a comma-separated list of clip UUIDs to trigger. This adds format and value semantics beyond the bare schema, though it could be more explicit about requiredness or 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 clearly states the tool's function: scheduling clips to play in session view for live triggering. The verb 'schedule' plus resource 'clips' and context 'session view (live triggering)' make it distinct from sibling tools like schedule_clip_stop.

  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 (session view live triggering) that differentiates it from similar clip operation tools, though it does not explicitly name alternative tools or exclusion criteria. This is adequate for a simple tool.

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

• mcp_opendaw_separate_stemsA
  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. It discloses that it 'Returns paths to separated stem files' and provides a default output_dir, implying disk writes. However, it doesn't explicitly state whether the input is modified, whether files are overwritten, or performance requirements. It gives useful context but isn't 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 long but every part is necessary—the model list is essential because the schema lacks enums. It front-loads the purpose, then details models, parameters, and an example, 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?

  Given the presence of an output schema and detailed parameter descriptions, the tool is well-covered. The description includes all three parameters, model options, defaults, and an example. It could mention input file format support or overwriting behavior, but it's largely 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%, and the description compensates fully: it explains input_file, model with a complete list of valid values and their tradeoffs, and output_dir with default. The example clarifies the return structure.

  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 'Separate audio into stems using SOTA AI models' with a specific verb (separate) and resource (audio into stems), and lists named models. However, it doesn't explicitly differentiate from sibling tools like 'split_stems' or 'export_stems', so it misses 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 provides model selection guidance (e.g., 'bs6' for fast, 'polarformer' for best vocals) and says it's 'much better than Demucs alone', but doesn't explicitly state when to use this tool instead of alternatives like split_stems or export_stems. No exclusions or alternative tool references.

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

• mcp_opendaw_set_audio_region_time_baseA
  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 explains the semantic behavior of each time-base mode and states the return value ('Returns old and new time base'). However, it does not disclose potential side effects—such as how switching modes may affect the region's current timeline duration—or any prerequisites like valid indices, making it adequate but with meaningful gaps 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 compact and well-organized: a lead sentence, a formatted bullet list for the core concept, a parameter summary, and a return-value note. Every sentence earns its place, and the layout is front-loaded with the primary purpose.

  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 core semantics of musical vs. seconds are thoroughly explained, and the output schema covers the return value, so the description needn't detail it. However, the description omits important contextual detail for a complete picture: what happens to an existing region's duration when you change its time base, and what error behavior occurs if indices are invalid. These gaps leave the description workable but incomplete for a mutation tool.

  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 must compensate entirely. It enumerates all four parameters and gives brief definitions, with the time_base parameter receiving substantial semantic depth (the bullet list explaining musical vs seconds). However, the index parameters ('AU index', 'Track index within the AU', 'Audio region index') are nearly tautological with their names, lacking details like zero-based indexing or relationship 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 statement ('Set the time base of an audio region') and expands with a clear explanation of the two modes. This distinguishes it from sibling region tools like set_region_duration or set_audio_region_gain by naming the unique operation, and the conceptual elaboration adds value beyond the tool name.

  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 context for when this tool applies: it controls how the region's duration is interpreted. It also explains the two mode options (musical follows tempo, seconds is fixed wall-clock time), which directly guides the agent's choice of the time_base value. No exclusions or alternatives are mentioned, but no direct sibling tool competes for this operation.

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

• mcp_opendaw_set_device_labelA
  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 full burden. It discloses the return behavior ('Returns success, or error') and explains MIDI vs audio targeting via is_midi_effect. However, it omits potential error conditions, side effects, or prerequisites like the existence of the device chain.

  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: action first, then parameter definitions, then return value. No unnecessary 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 simple rename operation, the description covers all inputs and the return value. It could improve by specifying how to obtain indices (e.g., via list_effects) or clarifying zero-based indexing, but it is largely complete for the task.

  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 compensates fully by explaining all four parameters: unit_index, effect_index, label, and is_midi_effect, including the default behavior for MIDI effects. This adds meaningful context beyond bare parameter names.

  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 'Rename an effect or MIDI effect device,' identifying the action and target. It distinguishes this tool from siblings like set_region_label or set_bus_label by focusing on device labels.

  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 explicit guidance on when to use this tool versus alternatives like rename_unit or set_bus_label. The tool's purpose is clear, but no alternatives, prerequisites, or exclusions are mentioned.

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

• mcp_opendaw_set_time_signatureA
  3.9/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 burden of behavioral disclosure. It only says 'set', implying a mutation, but gives no information about side effects on existing signature changes, reversibility, or required project state. For a write operation, 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.

  Conciseness5/5

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

  The description is two short sentences plus a structured breakdown of the two parameters. Every line adds value, with no filler or repetition of schema details. It is front-loaded with the main purpose.

  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 the core function and both parameters adequately for a simple setter, and an output schema exists so return values need no explanation. However, it omits constraints like valid denominator ranges and does not address differences from add_signature_change, leaving minor gaps. Overall it is sufficient but not exhaustive.

  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 specifies integer types with no descriptions (0% coverage). The description compensates fully by explaining numerator as 'Number of beats per bar' and denominator as 'Note value per beat,' including mappings like 4=quarter and 8=eighth. It adds substantial semantic meaning and usage examples 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 opens with 'Set the project time signature'—a specific verb+resource. It provides concrete examples (4/4, 3/4, 6/8, 7/8) and distinguishes the tool by scoping it to the project time signature. This clearly differentiates it from siblings like set_bpm or set_groove_shuffle.

  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 the action, but does not explicitly say when to use this tool versus alternatives like add_signature_change. It offers no when-not-to-use conditions or exclusions. The context is clear but not differentiated from related time-signature tools.

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

• mcp_opendaw_set_tuningA
  3.9/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 disclosing behavioral traits. It only states the action itself and offers parameter examples, but does not mention whether the setting is global or per-track, whether it affects playback or recording, whether it is reversible, or if any prerequisites exist (e.g., engine running). This is a notable 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 extremely concise: two short sentences, with the purpose in the first and parameter details in the second. There is no filler or redundant information. Every sentence serves a clear function, making it 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 a simple setter with only one parameter and an output schema present, the description covers the essential semantics: what the tool does and what the parameter means. It lacks broader context about the scope (global vs. per-track) but this is a minor omission given the tool's simplicity and the presence of an output schema that likely covers return values.

  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 (only type 'integer' and title 'Frequency'), so the description must compensate. It does so excellently: 'A4 frequency in Hz. Default 440. Common alternatives: 432 (verdi), 415 (baroque), 466 (baroque organ).' This adds units, a default, and meaningful examples, 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 clearly states the tool's purpose: 'Set the A4 base frequency (concert pitch tuning).' It uses a specific verb ('set') and resource ('A4 base frequency'), and the parenthetical 'concert pitch tuning' distinguishes it from other set tools like set_bpm or set_time_signature. This is unambiguous and not a tautology.

  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 does not explicitly state when to use this tool versus alternatives or provide prerequisites or exclusions. The use case is implied by the tool name and the phrase 'concert pitch tuning,' but there is no direct guidance on when to choose this over sibling tools. This is implied usage rather than explicit, warranting a midpoint score.

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

• mcp_opendaw_set_vaporisateur_osc_paramA
  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 transparency burden. It does disclose that the tool returns old and new values, which is helpful, and provides value ranges for parameters. However, it does not mention side effects, error behavior on invalid inputs, or whether the operation is reversible. This is a moderate level of transparency for a write 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 well-structured and information-dense, using bullet-like formatting to list each parameter and its allowed values. The purpose statement is front-loaded, and every sentence provides useful detail. No fluff or redundancy beyond the minor 'value: New value' line, which is still functional.

  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 moderate complexity (4 required parameters, no annotations, output schema present), the description covers param semantics, value domains, and return behavior (old and new values). It is complete enough for an agent to invoke it correctly without additional lookup. Missing only explicit usage context and edge-case handling, which 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?

  Schema description coverage is 0%, so the description must fully document parameters, and it does. It explains the valid range for osc_index (0,1), enumerates all accepted param_name values with exact mappings (waveform: 0=Sine, etc.), describes volume dB range, octave integer offset, tune float offset, and the special auto-detect behavior of unit_index. 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 opens with 'Set a parameter on a Vaporisateur oscillator,' which clearly identifies the action (set), the target resource (parameter on a Vaporisateur oscillator), and distinguishes it from other set_* tools that target different resources (e.g., set_effect_parameter, set_instrument_param). The parameter details further clarify the scope.

  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 explicit guidance is provided about when to use this tool versus alternatives like mcp_opendaw_list_vaporisateur_params or set_instrument_param. The description implies usage for any Vaporisateur oscillator parameter change, but does not mention prerequisites (e.g., looking up valid param names via the list tool) or scenarios where a different tool 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.

• mcp_opendaw_compare_to_profileA
  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 safety/behavior burden; it discloses that the tool 'returns deviation analysis with severity-ranked suggestions' and gives example output, but it does not explicitly state that the operation is read-only or non-destructive, or how invalid filenames/genres are handled.

  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 core action, uses a scannable bullet list for output dimensions, and then gives parameter details and an example. It is slightly long but every section 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?

  The description covers inputs, output style, dimensions, and example; output schema handles return details. It could mention prerequisites (e.g., exported WAV existence) but is otherwise complete for a two-parameter analysis 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 coverage is 0%, yet the description documents both required parameters: filename (WAV in exports dir or absolute path) and genre (with an explicit list of accepted values). It even provides an example call, going well 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 leads with 'Compare your mix against a professional genre reference profile' and enumerates the exact deviation dimensions (LUFS, spectrum, stereo width, dynamics, spectral centroid), making it distinct from generic analysis tools and the sibling compare_to_reference.

  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 frames the tool's use case (genre-standards comparison) and provides a concrete example, but it never explicitly states when to prefer this over sibling tools like compare_to_reference or match_to_reference, nor 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.

• mcp_opendaw_create_arabic_percussionA
  4/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 disclosure burden. It does convey that the tool creates an ensemble and returns notes/instrument breakdown, but it omits side effects such as whether it appends to an existing region or replaces notes, and any prerequisites. There is no contradiction with annotations (none provided).

  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 well-structured with headings for strokes, rhythms, and args, and it front-loads the purpose. However, it is lengthy with extensive educational detail on each rhythm pattern; while informative, this detail could be trimmed to a more concise summary without losing invocation-critical 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?

  Given the tool's cultural specificity and 9-parameter schema, the description covers the musical context, rhythm definitions, stroke vocabulary, and return values. The output schema (not shown in text) likely covers exact return fields, and the description provides a high-level of that. It would benefit from explicit mention of what the tool does not alter or how it interacts with existing tracks, but overall it is complete enough for an agent to select and invoke.

  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's Args section is essential. It adds ranges ('bars: 2-16, even'), valid values for rhythm, velocity range, and pitch meanings with MIDI equivalents. It leaves unit_index and track_index slightly ambiguous ('AU index', 'Note track index') but still adds substantial value 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: 'Create an Arabic/Middle Eastern percussion ensemble — darbuka, daf, and zills.' This clearly states the tool's function and distinguishes it from sibling percussion tools (e.g., create_djembe_ensemble, create_reggae_percussion) by naming the specific instruments and cultural 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?

  The description provides clear context by stating this is for Arabic/Middle Eastern percussion, and the rhythm names (maqsum, baladi, saidi, etc.) make the use case explicit. However, it does not explicitly mention when not to use it or name alternative tools for other percussion styles, stopping 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.

• mcp_opendaw_create_basslineA
  4/5.0
  Behavior3/5

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

  With no annotations, the description does explain defaults (octave 2, velocity 0.9), pattern semantics, and return value. But it doesn't disclose whether it overwrites existing notes, requires an empty track, or what happens on invalid input, which is a significant 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.

  Conciseness4/5

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

  The description is reasonably concise despite its length, front-loading the core purpose and defaults before diving into detailed pattern syntax. Each sentence contributes, and the use of examples is effective.

  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 8-parameter tool with no annotations, the description covers all parameters, includes examples, and states the return value. It could additionally discuss error handling or prerequisites, but it's largely 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 input schema has 0% parameter description coverage, so the description fully compensates by explaining root note names, pattern syntax with special characters and examples, and providing details for all 8 parameters including defaults and ranges.

  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 'Create a bassline from root note + rhythmic pattern' with a specific verb and resource. It distinguishes from create_note by noting it replaces 8-20 calls, but doesn't differentiate from other bassline tools like create_walking_bass or create_electronic_bass.

  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 context on when to use this tool (creating a bassline with a root and pattern) and contrasts with create_note calls. However, it doesn't explicitly state when NOT to use it vs. other bass-generation siblings, leaving some ambiguity.

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

• mcp_opendaw_create_binary_formA
  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 transparently discloses the generated output structure (A/B sections, repeat behavior), the side effect of creating melody on track_index and bass on track_index+1, and musical behavior details like modulation types. It does not address operational consequences such as overwriting existing notes or error conditions, but the disclosed behavioral traits go well beyond a minimal description.

  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 well-structured, with a clear front-loaded purpose, a section on modulation types, and a line about repeat behavior. The music theory background is useful but somewhat verbose; each sentence earns its place for a creative tool, though it could be tightened.

  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 musical concept, modulation options, and track targeting adequately. With an output schema present, return values need not be described. However, operational details such as how bars_per_section, start_beat, and unit_index affect the generation, and what happens to existing notes, are missing. This leaves the description sufficient for basic invocation but incomplete for nuanced use.

  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 must compensate. It explains three parameters indirectly: modulation (via the modulation types list), repeat (via 'With repeat=True'), and track_index (via the track assignment note). However, it leaves key_root, scale_name, start_beat, unit_index, bars_per_section, and velocity unexplained, which is a significant gap for an agent choosing parameter 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 first sentence — 'Create binary form — two contrasting sections (A|B) with optional repeats' — uses a specific verb and resource, clearly distinguishing this tool from siblings like create_ternary_form or create_sonata_form. The rest of the description reinforces the formal structure with musical 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?

  The description provides clear usage context by situating binary form in specific musical genres (Baroque dance suites, folk, early jazz, pop), which implies when this tool is appropriate. However, it does not explicitly mention alternatives or state when NOT to use it, leaving some room for ambiguity against sibling form-creation tools.

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

• mcp_opendaw_create_drum_fillA
  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 full burden. It discloses the operation (creates notes), the return value ('Returns notes created per lane and total'), and the unit_index prerequisite. However, it does not mention potential side effects, whether any existing notes are overwritten, what happens if no AU with a note track exists, or any error conditions. The description is informative but not fully transparent about behavioral traits.

  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 well-structured: it opens with the high-level purpose, then usage guidance, then a clear parameter reference with bullet points. It is longer than the minimal examples but every sentence earns its place by explaining a parameter or use case. It is not overly verbose, though the parameter details could be considered slightly lengthy — still, they are all relevant.

  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 moderate complexity (5 params, no enums in schema, but detailed explanatory descriptions), the description covers all necessary aspects: what it does, when to use it, parameter semantics, and return value. It does not explain prerequisites like needing an existing drum track or what happens if no matching AU is found, but it is largely complete for an agent to select and invoke the 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 description must compensate, and it does excellently. Every parameter is explained: fill_type has all five enumerated values with definitions, bars has a range and time interpretation, start_beat is defined, density lists its options, and unit_index is clarified with the -1 fallback. 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.

  Purpose4/5

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

  The description clearly states it 'Create a drum fill or transition pattern' and elaborates that it 'Generates rhythmic fills between song sections with increasing/decreasing density.' This is a specific verb+resource with a clear scope. However, it doesn't explicitly name or contrast with sibling tools like create_drum_pattern or create_break, so it doesn't fully distinguish itself from 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 provides explicit usage context: 'Useful for transitions: verse→chorus, breakdown→drop, outro buildup.' This tells the agent when to use it. It also mentions the efficiency benefit ('one call replaces 10-30 note creations'), giving a rationale. It does not mention when not to use it or name alternatives, so it falls short 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.

• mcp_opendaw_create_drum_patternA
  4/5.0
  Behavior3/5

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

  With no annotations, the description must disclose behavior. It explains velocities, unit_index default behavior, and the return value. However, it does not state whether existing notes on the target unit are overwritten or deleted, nor does it describe error handling for invalid patterns or missing units. Some behavioral transparency is present, but key side effects are omitted.

  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-line purpose, followed by a structured breakdown of the pattern format, lanes, example, and parameter explanation. Each section contributes value; the example is somewhat long but enhances understanding. Well-organized and concise overall.

  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 a complex input format, the description provides enough to construct a valid call: complete pattern syntax, target unit selection, and return value. It does not cover edge cases or failure modes, but the core usage is fully addressed given the output schema exists and the description mentions the return value.

  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 the description fully compensates. It defines the pattern JSON format in detail, including allowed step characters, velocity values, lane names, and provides an example. It also explains unit_index semantics with its -1 default. No ambiguity remains for either 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 opens with a specific verb and resource: 'Create a drum beat from compact step-sequencer notation.' It further distinguishes itself by noting 'one call replaces 10-20 note creations,' making it clear this tool is for efficient drum pattern creation rather than individual note placement or other rhythmic 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 explains how to use the tool with pattern syntax and unit_index, and includes an example, but it does not explicitly state when to prefer this tool over alternatives like create_drum_fill or create_euclidean_rhythm. Usage context is implied rather than explicitly guided.

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

• mcp_opendaw_create_genre_sectionsA
  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 the transformation behavior, per-section velocity multipliers, which musical elements are included/excluded in each section, and the return summary. However, it does not mention potential side effects on existing tracks (e.g., overwriting notes) or whether it is destructive.

  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 well-organized with clear sections: purpose, energy progression, parameter details, and examples. It is somewhat long and repeats section_lengths details, but every section adds meaningful info for a complex tool.

  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 musical behavior is thoroughly explained, and return values are stated. However, with 9 parameters, 5 are undocumented in the description, and there is no mention of how the tool interacts with the existing project (e.g., whether it creates new tracks or reuses existing ones). This leaves gaps for an agent attempting to invoke it correctly.

  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?

  The description adds valuable semantics for genre, bpm, root, and section_lengths, including examples and constraints. But it completely omits explanations for the 5 remaining parameters (bass_track, drum_track, unit_index, melody_track, harmony_track), which are critical for routing the sections to the correct tracks. Since schema coverage is 0%, this is a notable gap.

  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: 'Create a multi-section electronic track from loop-based arrangements' and details the exact section flow (intro → buildup → drop → breakdown → outro). This clearly distinguishes it from generic arrangement tools and sibling genre-specific 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 intended use is clear: it is for electronic genres only (dnb, house, techno, etc.) and transforms loop-based arrangements into song structure. It explains the energy progression and likely use cases, but does not explicitly name alternatives (e.g., create_dnb_arrangement) 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.

• mcp_opendaw_create_genre_trackA
  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 burden of behavioral disclosure. It clearly states what is created and what is returned (AU indices, note counts, suggested next steps), and lists genre presets. However, it does not mention potential side effects like whether a new track is created in the current project state, how many tracks are generated, or any prerequisites. The description is not misleading but lacks deeper 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.

  Conciseness4/5

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

  The description is well-structured and front-loaded with the core purpose. The genre list is somewhat long but entirely necessary to convey valid parameter values. Each section (purpose, genre, bpm, return value) serves a clear purpose without redundant fluff. It could be slightly more concise by grouping similar genres, but it remains 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?

  Given the moderate complexity (one required enum-like parameter, one optional override) and the presence of an output schema, the description is largely complete. It covers purpose, parameter options, defaults, and return values. It does not mention project-level prerequisites or whether the tool works within the current project context, but this is likely implied by the tool family. The only notable gap is not specifying the number of tracks created or the exact nature of the 'basic mix'.

  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 fully compensates by providing detailed semantics for both parameters. The 'genre' parameter lists all valid values with musical component breakdowns and default BPMs. The 'bpm' parameter is explained as an override with per-genre defaults. This far exceeds what the bare schema offers, making the tool invocable with confidence.

  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 ('Create a genre-specific starting track') and clearly enumerates the components (synth, beat, basic mix) and scope (full section). It distinguishes itself from sibling tools by emphasizing 'genre-specific' and 'one call builds a full section', which sets it apart from generic track creation tools like create_synth_track or create_audio_track.

  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 context: when you need a genre-specific starting track that includes synth, beat, and mix. It does not explicitly state when to prefer this over alternatives (e.g., arrangement tools or create_genre_sections) nor provide exclusions. The 'one call builds a full section' suggests efficiency, but no clear guidance on alternatives is given.

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

• mcp_opendaw_create_notes_batchA
  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 states 'All notes go into one region on the specified note track. If no region exists, one is created,' which is useful. However, it does not disclose whether existing notes in the region are overwritten, appended, or how errors like invalid JSON are handled, leaving notable behavioral gaps.

  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 well-structured: purpose first, then parameter details, an example, and a behavioral note. It is a bit longer than strictly necessary, but each section adds value and the format is scannable. Nothing is 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?

  The tool has 3 parameters (one required string containing JSON) and an output schema. The description covers purpose, usage, the main parameter, and basic behavior. Missing are explanations of unit_index, handling of empty/invalid notes arrays, and whether existing region contents are affected. Given the absence of annotations, these gaps reduce completeness.

  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 must compensate. It thoroughly explains the 'notes' parameter with field breakdown (pitch, start, duration, velocity), defaults, and an example. However, it only implicitly refers to 'track_index' and does not explain 'unit_index' at all, so not all parameters are semantically 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 clearly states the action: 'Create multiple MIDI notes in a single call — batch creation for melodies, chords, arpeggios.' It distinguishes from siblings like mcp_opendaw_create_note by emphasizing batch creation. The target resource (MIDI notes on a track) is explicit.

  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 (create_note) and gives a concrete reason to prefer this tool: 'Faster than calling create_note repeatedly — one round-trip, one editing.modify() block.' It also indicates when the tool is appropriate (melodies, chords, arpeggios), providing clear usage context.

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

• mcp_opendaw_create_songo_patternA
  4/5.0
  Behavior3/5

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

  With no annotations, the description must carry behavior details. It explains the pattern structure, note placements, and available variations, and discloses the return value ('Returns notes created, stroke breakdown, and pattern info'). However, it doesn't disclose side effects like whether existing notes are overwritten/appended, or how unit_index/track_index affect the insertion target, which is a notable 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.

  Conciseness2/5

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

  The description includes extensive historical and musical background (two paragraphs on the history and feel of songo) that isn't necessary for invoking the tool. While the opening is clear and sections are labeled, the length makes it much less concise than needed for an agent to process quickly.

  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?

  Despite the verbosity, the description is functionally complete: it explains all parameters, variations, and output expectations. The presence of an output schema and the description's return-value statement cover the result. It's missing minor operational details (e.g., whether notes are inserted or replace existing content), but overall it's sufficient for an agent to use the 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 description is the sole source of parameter meaning. It covers all 10 parameters with ranges and defaults (bars 2-16 even, velocity 0-1, pitch defaults), and provides one-line definitions in the Args section, fully compensating 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.

  Purpose5/5

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

  The opening sentence 'Create a songo drum pattern' states a specific verb and resource. The description further differentiates from related tools by contrasting songo with clave, tumbao, and cascara, explicitly noting it is a complete drum-kit groove, which distinguishes it from sibling tools like create_clave and create_tumbao.

  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 strong context by distinguishing songo from clave, tumbao, and cascara and detailing the variations (classic, modern, fusion, songo_funk), helping agents choose the right pattern. It doesn't explicitly state when to avoid this tool or name alternative tools, 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.

• mcp_opendaw_create_trap_arrangementA
  4/5.0
  Behavior3/5

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

  The description discloses the musical output (notes, tracks, patterns) and return value ('Returns notes created per track and total'), but it does not clarify operational behavior such as whether existing notes on the target tracks are overwritten, whether tracks are expected to exist beforehand, or if the tool creates new tracks. With no annotations to rely on, these are meaningful gaps for a mutation tool that writes 3 tracks of notes.

  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 well-structured with an initial summary, bullet points for track content, a parameter list, output note, and examples. It is slightly verbose due to repeated emphasis on the 808 bass's musical character, but for a tool with 10 parameters the length is justified and 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?

  Given the tool's complexity (10 params, no annotations, output schema present but not detailed), the description covers the main functionality, parameter meanings, and examples, but leaves two parameters unexplained and does not state prerequisites (e.g., whether note tracks must exist or be empty). These are clear gaps for a creative generation tool that writes to specific tracks.

  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 description compensates for the 0% schema description coverage by explaining 8 of the 10 parameters with concrete ranges, defaults, and musical context (e.g., 'octave: MIDI octave for 808 bass (1 = C1=24)', 'root: Root note (F# minor is the most common trap key)'). However, it omits 'velocity' and 'start_beat', which remain undocumented in both the schema and description.

  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 ('Create a full trap arrangement') with a defined scope ('drums + 808 bass + bell melody across 3 tracks in one call'). It distinguishes itself from sibling arrangement tools by naming the exact genre and characteristic elements like 'trap hi-hat rolls' and '808 sub-bass slides'.

  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 contextual guidance for when to use this tool: to generate a modern trap arrangement. It gives concrete parameter guidance with ranges and defaults ('bpm: Tempo (130-160, default 140)', 'bars: Arrangement length (4-32)'), plus usage examples. It does not explicitly mention alternatives for other genres, but the naming and context make the intended use obvious.

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

• mcp_opendaw_force_scale_notesA
  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 full burden and handles it well: it explains the algorithm (moves every note not in scale to the nearest in-scale note), describes the effects of direction and preserve_octave, and states the return payload (count, per-track breakdown, changed notes). It does not explicitly mention irreversibility or how the target region is selected, 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.

  Conciseness4/5

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

  The description is well-structured with a one-line summary, a rationale/use-case paragraph, a parameter breakdown, and a return-value note. It is slightly longer than necessary due to enumerating all scales and root notes, but that information is directly useful and not wasted. Overall it is efficient for a tool with seven parameters.

  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 core operation, use cases, key parameters, and return value. However, it omits how the target region is identified (defaults of unit/track/region indices are not explained) and does not mention potential side effects or whether the operation is undoable. Given no annotations and no schema descriptions, this gap is notable but the description is still largely usable.

  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?

  The description provides detailed semantics for four of seven parameters: root_note (with full note list), scale (with full scale list), direction (with values and meanings), and preserve_octave (behavior for true/false). However, unit_index, track_index, and region_index are completely undocumented, and schema descriptions are absent (0% coverage). This leaves a significant gap for selecting which region to operate on.

  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 ('force'/'moves') and resource ('all notes in a region') with a clear goal: snap notes into a target scale. It further distinguishes itself from the sibling quantize_notes by calling itself the 'harmonic equivalent', making its purpose unambiguous even among many 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 explicitly names when to use the tool ('after audio-to-MIDI transcription, random generation, or importing MIDI from unknown sources') and contrasts it with quantize_notes to clarify the harmonic-vs-timing distinction. It does not list exclusions or alternative tools beyond quantize_notes, so it falls just short of full usage guidance.

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

• mcp_opendaw_get_device_chain_detailA
  4/5.0
  Behavior3/5

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

  Annotations provide readOnlyHint=true, which already signals a safe read operation. The description adds context about what data is returned (instrument info, audio_effect array, midi_effect array) and mentions parameter counts. However, it does not disclose details like whether the AU must exist, error behaviors, or performance implications. Still, it adds some value beyond 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?

  The description is compact and well-structured, with a brief overview, a clear statement of what one call does, a parameter line, and a list of return sections. Every sentence adds information 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?

  Given there is an output schema (not shown in detail) and the tool is simple (one param, no nested objects), the description is sufficient. It explains the input and the high-level return structure. It could mention whether the response includes names of effects or just counts, but the output schema likely covers that, and the return arrays are stated.

  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 description explicitly explains the sole parameter 'unit_index: AU index.' Although the schema already includes the parameter name and type, the description adds the semantic meaning (AU index) which is missing from the schema. With 0% schema description coverage, this is crucial and compensates well.

  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's verb ('Get detailed info') and resource ('all devices on an AU — instrument, audio effects, MIDI effects'). It specifies what is returned (instrument name/type, effects labels, enabled state, minimized state, parameter counts) and includes a parameter description. This distinguishes it from sibling tools like list_effects or get_effect_chain by focusing on the full device chain detail.

  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 inspecting a complete device chain on a given AU, but it doesn't explicitly state when to use this vs alternatives like get_effect_chain, list_effects, or list_midi_effects. There is minimal context about use cases (e.g., 'One call to inspect the full device chain'), but no exclusions or alternative recommendations.

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

• mcp_opendaw_get_engine_statusA
  4/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the description doesn't need to restate that. It adds a useful enumeration of return fields, but no additional behavioral traits such as whether the engine must be running, potential latency, or error conditions. This is adequate 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 concise and well-structured: a single-sentence summary followed by a clean list of return fields. Every line adds information with no redundancy 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 low-complexity read-only getter with no parameters and an output schema, the description covers the essential purpose and return values. It lacks explicit usage context or caveats, but given the simplicity, the completeness is sufficient though not exceptional.

  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%. Per rubric, a no-parameter tool receives a baseline of 4 since there is nothing to document.

  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 ('Get') and resource ('real-time engine status'), and clearly enumerates key fields (playing state, position, BPM, CPU load). This distinguishes it from sibling tools like get_project_state or get_mixer_state, which cover 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 Guidelines3/5

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

  No explicit guidance is given on when to use this tool versus alternatives such as get_project_state or get_mixer_state. The read-only nature is implied by 'Get', but there are no stated exclusions, prerequisites, or alternative recommendations.

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

• mcp_opendaw_move_signature_eventA
  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 full burden of behavioral disclosure. It does disclose that subsequent event positions are automatically recalculated and that it returns success or error, which adds context beyond a bare 'move' operation. However, it omits details about permissions, reversibility, undo behavior, or error conditions, so it is only partially 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 written in a few short sentences covering purpose, side effect, parameters, and return value without excessive fluff. Each sentence adds value beyond the schema, and the structure flows logically from summary to behavior to parameters, though it could be slightly tightened.

  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 tool with two parameters and an output schema, the description provides essential invocation details but lacks some contextual completeness. It doesn't mention what happens with invalid indices, whether the move is undoable, or how it relates to other signature management tools like set_time_signature or change_base_signature, leaving some gaps for a new 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?

  Because the input schema has 0% description coverage, the description is the sole source of parameter meaning. It explains event_index as the index from the add_signature_change list and target_ppqn as the new PPQN position, which is workable and clear. It doesn't define PPQN or give valid ranges, but it compensates well 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.

  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 ('Move') and resource ('a time signature change event') plus destination ('new PPQN position'), clearly distinguishing it from sibling tools like add/delete/list signature changes. It also references the add_signature_change list as the source for event_index, reinforcing the specific 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 gives meaningful context for when to use the tool by explaining that the event_index comes from the add_signature_change list and noting that subsequent events are recalculated. This implies it is for moving existing events rather than adding or deleting, but it doesn't explicitly name alternatives or state when-not-to-use conditions, so it falls short of full explicitness.

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

• mcp_opendaw_move_trackA
  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 burden. It discloses that it uses AudioUnitBoxAdapter.moveTrack and 'reindexes the track,' and mentions the return value ('new index or error'). However, it does not describe potential side effects on other tracks, validation, permissions, or reversibility.

  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, followed by implementation note, parameter explanations, and return value. Every sentence is informative with no redundancy 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?

  The description covers the action, parameters, behavior, and return value. Since an output schema exists, return details are not required. Minor gaps include bounds or error conditions, but overall it is sufficiently complete for a simple move 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?

  Schema descriptions are absent (0% coverage), but the description explains each parameter: unit_index as 'AU index,' track_index as 'Track index within AU,' and delta with explicit semantics ('-1 up, +1 down'). This adds clear meaning beyond the bare schema fields.

  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 'Move a track up or down within an audio unit,' which uses a specific verb, resource, and scope. It distinguishes itself from sibling tools like move_audio_unit by clarifying track_index is within an AU, and it explains the delta direction.

  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 for reordering tracks inside an audio unit but gives no explicit 'when to use' or 'when not to use' guidance, nor does it mention alternatives such as move_audio_unit or move_effect. It is adequate but lacks explicit exclusions.

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

• mcp_opendaw_remove_sendA
  4/5.0
  Behavior2/5

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

  With no annotations provided, the description must disclose behavioral traits on its own. It reveals the destructive nature (removing a send) but does not mention potential side effects (e.g., audio routing changes, irreversibility, or error conditions). This is a significant gap for a mutation tool, warranting a low score.

  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 front-loaded: the first sentence states the purpose, followed by two brief parameter definitions. Every sentence earns its place with no redundancy 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 two-parameter operation, the description is largely sufficient: it explains the operation and both parameters, and an output schema exists so return values do not need elaboration. It could benefit from noting that the send index comes from list_sends, which it does, but does not mention prerequisites like the audio unit existing. Overall, it is complete enough for the tool's low complexity.

  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 parameter names and types with 0% description coverage, so the description compensates by explaining both parameters clearly: 'unit_index: Source audio unit index' and 'send_index: Send index to remove (from list_sends)'. This adds actionable meaning beyond the schema, though it does not elaborate on constraints or formats.

  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 ('Remove an aux send') and the target resource ('an audio unit'). This distinguishes it from sibling tools like create_send, list_sends, and set_send_level, which have different verbs and purposes.

  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 tool is used when you want to delete an existing aux send, and the parameter hint 'from list_sends' provides useful context about how to obtain the correct send_index. However, it does not explicitly name alternatives or state when not to use the tool, 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.

• mcp_opendaw_set_bus_labelA
  4/5.0
  Behavior3/5

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

  No annotations exist, so the description carries full burden. It discloses the effect (set label) and return ('Returns success or error') but does not mention failure modes, overwriting behavior, or whether an invalid bus index produces an error. For a simple setter this is minimal but acceptable.

  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?

  Extremely concise: purpose statement first, then per-parameter clarifications, then return value. No unnecessary words or filler. Every sentence holds the needed 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 setter with an output schema available, the description covers operation, parameter semantics, and return status. It doesn't discuss boundary conditions like invalid bus index, but the simplicity of the tool makes the description sufficiently 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 has 0% description coverage, so the description compensates by explaining 'bus_index: Bus index from create_audio_bus' and 'label: New name for the bus' with concrete examples ('Reverb Bus', 'Drum Bus'). This adds useful meaning beyond the bare types in 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?

  Description opens with 'Set the label (name) of an audio bus' – a specific verb+resource+object. It clearly distinguishes from sibling tools like set_bus_color by targeting exactly the label/name 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/when-not-to-use or alternatives, but 'Bus index from create_audio_bus' implies a prerequisite, providing some usage context. The operation is self-evident for renaming a bus, but the tool doesn't state exclusions or compare with other bus-related setters.

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

• mcp_opendaw_set_clip_hueA
  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 full burden. It discloses the return behavior ('Returns success with old and new hue') and the hue range (0-360), but omits details about error conditions, side effects, or whether existing hue values are overwritten.

  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 purpose sentence, a parameter list, and a return-value note. Every sentence earns its place with no 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 simple setter tool with an output schema, the description covers the essential aspects: what is set, parameter meanings, and return behavior. It doesn't address possible failure scenarios, but given the output schema and simplicity, this is adequately complete 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?

  With schema description coverage at 0%, the description compensates by explaining each parameter: unit_index as AU index, track_index within the AU, clip_index, and hue range (0-360). This clarifies the hierarchical addressing scheme that the bare 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 states 'Set the color (hue) of a clip in the session view' with a specific verb, resource, and scope. It clearly indicates the exact attribute being modified, distinguishing it from sibling tools like set_clip_mute or set_clip_label.

  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 for setting a clip's hue but provides no explicit guidance on when to use this tool versus alternatives. It mentions the 'session view' context but no exclusions or alternative recommendations.

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

• mcp_opendaw_set_studio_settingA
  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 full burden. It discloses value formats ('true'/'false' for booleans, strings for enums) and lists example settings, but it does not mention persistence, immediate application, validation behavior, or error handling. This is useful context but not complete transparency.

  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 well-structured: one clear purpose sentence, an Args block, and a Common settings list. It is longer than minimal but every section provides operational value. The category list is partly redundant with the common-settings dotted keys, but not severely bloated.

  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 3-parameter tool with no schema descriptions and no annotations, the description is quite complete. It covers all categories, value representations, and a substantial set of common settings. It lacks explicit return-value/error behavior and a way to discover all keys, but the output schema existence reduces the need to describe return values.

  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 explains allowed category values, gives key examples, describes the value parameter's encoding, and provides a common-settings table with types and enum options. 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 opens with 'Set a studio preference setting,' which is a specific verb + resource statement. It clearly distinguishes this tool from sibling read/settings tools like mcp_opendaw_get_studio_settings and from per-track/effect setters by limiting scope to 'studio preference settings' and enumerating categories.

  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 labeling the tool as a studio preference setter and listing categories/common settings, but it never explicitly states when to use it versus alternatives or when not to use it. It provides no exclusions or comparisons to sibling tools.

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

• mcp_opendaw_transfer_regionA
  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. It discloses important behavioral traits: copies all dependencies (notes, events, audio files), shares preserved resources rather than duplicating them, supports delete_source for move semantics, and reports the new region's type/position/duration or error. This is valuable and goes beyond a simple mutation statement.

  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 well-structured: a one-line summary, a behavior paragraph, a parameter list, and a return-value note. It is longer than strictly necessary, but each part contributes meaningful information. The formatting is logical and front-loaded, making it easy to scan.

  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 complexity (7 parameters, mutation semantics, cross-AU operation) and the existence of an output schema, the description is largely complete. It covers all parameters, key behavioral nuances, and return values. It could mention failure/error conditions more explicitly, but the 'or error' note is sufficient given the output schema.

  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 no property descriptions (0% schema coverage), but the description thoroughly explains all seven parameters. It adds semantics not present in the schema: region_index is 0-based and sorted by position, insert_position is in beats, and delete_source controls move vs copy. 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?

  Description clearly states the tool transfers/copies a region to another track at a specified position, naming the operation (TransferRegions.transfer) and key capabilities such as cross-AU support and dependency copying. However, it does not explicitly differentiate from sibling tools like copy_region_to_track or move_region_to_track, leaving some ambiguity.

  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 context for usage (e.g., works across different audio units, preserved resources are shared, optional source deletion), which implies when this tool is appropriate. However, it does not explicitly state when to use this tool over alternatives or mention any exclusions, leaving the agent to infer the best choice.

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

• mcp_opendaw_copy_playfield_sampleA
  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 discloses that the sample is duplicated with a specific list of parameters and that it returns success or error. However, it lacks edge-case behavior such as whether an existing target_index is overwritten or replaced, which is important 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 concise and well-structured: an action sentence, a details paragraph enumerating copied parameters, parameter definitions, and the return type. Every sentence earns its place, and the important verb 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 tool with three simple integer parameters and an output schema, the description covers the operation, parameter meanings, and return value. It is missing minor behavioral details (e.g., target slot overwrite behavior), but overall it is sufficiently complete 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?

  The input schema provides only integer types with no descriptions (0% coverage). The description fully compensates by giving clear one-line explanations for each parameter: unit_index (AU index), sample_index (source slot), and target_index (destination slot). This is strong added 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 opens with a specific verb+resource+destination: 'Copy a Playfield (drum machine) sample to a new index slot.' It clearly states the operation and lists the exact parameters that get duplicated, which differentiates it from create_playfield_sample or other sample-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 description implies usage (copying/duplicating rather than creating) but does not explicitly state when to use this tool instead of siblings like create_playfield_sample. No exclusions or alternative tools are mentioned, leaving the usage decision partly to the agent's inference.

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

• mcp_opendaw_create_cascaraA
  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 of disclosing behavior, and it does so extensively. It explains the two stroke heights (high/unaccented vs. low/accented), the detailed rhythmic structure for each cascara_type, velocity offsets (high +0.1, low -0.05), and the return value (notes created, type, direction, stroke breakdown). It does not mention potential side effects like whether existing notes are replaced or whether the pattern is added to a specific region, but the additive nature is implied by 'Create' and 'Returns notes created.'

  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 well-structured. It front-loads the purpose, provides musical context that is relevant to usage, and then systematically breaks down each cascara_type with a compact notation. The parameter descriptions are concise and the examples at the end are useful. While slightly verbose, every major section earns its place, and the formatting aids readability.

  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?

  As a rhythmic pattern generator with 8 parameters, the description is quite complete: it defines the pattern variants, stroke semantics, velocity behavior, bar-length guidance, and examples. It does not explain three placement-related parameters (start_beat, unit_index, track_index) or describe edge cases like quantization or interaction with existing notes, but the output schema exists to cover return details, and the musical content is thorough. The gap on placement parameters prevents a perfect score.

  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 must compensate. It thoroughly documents 5 of 8 parameters: cascara_type (with per-type notations), bars, high_pitch, low_pitch, and velocity. However, it leaves start_beat, unit_index, and track_index completely undocumented, relying on parameter names and examples alone. Since these are crucial for placement within the DAW, the description only partially compensates for the total absence 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 opens with a specific verb and resource: 'Create an Afro-Cuban cáscara pattern — the timbale shell rhythm that fills space around the clave.' It clearly distinguishes this from sibling tools like create_clave and create_tumbao by explaining the cáscara's complementary role as one of the three pillars, and it details specific pattern types (son_3_2, son_2_3, guaguanco, mambo). This avoids ambiguity and anchors the tool's identity precisely.

  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 about when this tool is appropriate: it is used for creating a cáscara pattern that interweaves with clave and tumbao in Afro-Cuban music. It also implies the complementary relationship ('Together with clave and tumbao...'), which helps an agent decide between this and related pattern tools. However, it does not explicitly state when NOT to use it or name alternatives, so it stops short of a perfect 5.

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

• mcp_opendaw_create_colotomicA
  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 states it creates notes and returns notes created, gong layer breakdown, and cycle info, and lists parameters like unit_index, track_index, and start_beat, implying it places notes in a DAW. However, it does not disclose side effects such as whether it overwrites existing notes, requires a pre-existing track, or modifies existing regions—important 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.

  Conciseness4/5

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

  The description is long but well-organized, front-loading the purpose, then providing musical context, differentiation, structure/tempo lists, args, and returns. Some educational content (e.g., the role of melodic instruments) could be trimmed without loss, but the length is largely justified given the complexity of the 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?

  For a tool with 10 parameters, no schema descriptions, and no annotations, the description is quite complete: it explains the musical concept, all parameter options, structure specifics, and return value. It lacks explicit info on how output relates to the output schema and some behavioral edge cases, but it is sufficiently rich for an agent to select and invoke 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?

  Schema description coverage is 0%, so the description must compensate, and it does with an 'Args' section that explains all 10 parameters, including allowed structures, tempo densities, ranges for cycles/octave, and the meaning of unit_index/track_index. It omits some specifics (e.g., root note format beyond examples, whether values are case-sensitive), but overall it adds significantly beyond the raw property names.

  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: 'Create a colotomic structure — interlocking gong layers marking cyclic time.' It clearly differentiates from siblings by contrasting with polyrhythm and additive rhythm, making the tool's unique 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 provides strong contextual guidance by explaining when colotomic structure is appropriate ('foundation of Indonesian gamelan, Javanese klenengan, and Balinese ritual music') and explicitly distinguishes it from polyrhythm and additive rhythm. However, it does not explicitly name alternative tools or state 'use this instead of X', 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.

• mcp_opendaw_create_counter_melody_from_progressionA
  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 pattern options (contrary, oblique, parallel_third, parallel_sixth, call_response) and default values for octave, velocity, and track_index, which gives insight into the generated output. However, it does not mention side effects such as whether existing notes on the target track are overwritten, what exactly is created (e.g., a MIDI region), or any prerequisites beyond having a progression. This is adequate but 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.

  Conciseness4/5

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

  The description is well-structured: a definition, context about the harmonic quintet, a bulleted list of pattern options, a parameter list, and three examples. It is longer than the minimum but every section adds value—the pattern explanations are particularly useful. It could be slightly trimmed (e.g., the example code block is long), but it remains efficient and front-loaded with the core purpose.

  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 8 parameters and moderate complexity, the description covers most key aspects: purpose, patterns, defaults, track placement, and examples. It is incomplete regarding start_beat and unit_index, and it does not specify the expected format of the progression string beyond the example 'Am-F-C-G'. Since an output schema exists, the lack of return-value documentation is acceptable. Overall, it is a thorough description with minor 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 input schema has no parameter descriptions (0% coverage), so the description must compensate. It explains pattern, bars_per_chord, octave, velocity, and track_index, including detailed sub-values for pattern. The examples also demonstrate parameter usage. However, two parameters—start_beat and unit_index—are not mentioned at all, leaving them unexplained. This is a significant but not total gap, so a 4 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?

  The description opens with 'Create a counter-melody (second melodic line) from a chord progression,' which clearly names the verb and resource. It further distinguishes this tool from the related melody_from_progression by emphasizing it is the secondary line, and explicitly places it in the harmonic quintet alongside chord_pads, arpeggiated_progression, bass_from_progression, and melody_from_progression.

  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: it should be used to add a second melodic line over an existing progression/melody, and it is the final piece of the harmonic quintet. It also advises placing it on track 4 to avoid clashing with the melody on track 3. However, it does not explicitly name alternative tools or say when not to use it, 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.

• mcp_opendaw_create_dembowA
  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 burden of explaining behavior. It discloses the pattern structure for each dembow variant, the velocity adjustments, and that the tool returns notes created, dembow type, and stroke breakdown. However, it does not mention potential side effects like whether existing notes on the target track are overwritten or how it interacts with the current project state.

  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 relatively long but well-organized with a clear opening, a musical background, enumerated variants, and parameter details. Each section earns its place, and the examples add practical value without excessive 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?

  Given the tool's complexity (8 parameters, no annotations), the description is quite complete: it defines dembow, lists variants with exact beat positions, explains pitch and velocity defaults, and provides examples. Missing details on start_beat and unit_index prevent a perfect score, but the overall context is sufficient for most use cases.

  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 must compensate. It thoroughly explains dembow_type, velocity, bars, kick_pitch, and snare_pitch, and shows track_index in examples. However, start_beat and unit_index are left entirely undocumented, leaving a significant gap for two of the eight 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 states the tool's purpose: 'Create a dembow rhythm — the foundational beat of reggaeton and Latin dancehall.' It uses a specific verb and resource, and the detailed explanation of what a dembow is and its variants (classic, dancehall, trap_latino, etc.) distinguishes it from the many other rhythm-creation tools 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 implies the tool should be used when a dembow rhythm is needed, providing context on the pattern's musical role and examples of usage. However, it does not explicitly state when not to use it or contrast it with alternative tools like create_clave or create_boom_bap, so it stops short of a full usage guide.

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

• mcp_opendaw_create_funk_arrangementA
  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 transparency burden. It discloses that it creates an arrangement across tracks, returns "notes created per track and total," and mentions requiring a unit_index with note tracks. However, it does not state whether existing notes are overwritten, whether it creates missing tracks, or any prerequisites beyond the unit_index reference.

  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 (several paragraphs) but well-structured with bullet-style track breakdowns, param definitions, and examples. The front-loaded first sentence states the core purpose immediately. Some historical references are colorful but not essential; still, every paragraph contributes to understanding the style and parameters.

  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 complexity (4 tracks, 11 parameters, genre-specific behavior), the description is quite complete: it explains musical roles, defaults, ranges, and even provides example calls. The output schema exists, so detailed return-value documentation is not required. The main gaps are behavioral side effects and the two undocumented parameters, which prevent a perfect score.

  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 0% description coverage, so the description must compensate. It adds meaningful semantics for bpm, bars, root, octave, unit_index, and the four track indices, including ranges, defaults, and musical intent. However, it omits two schema parameters (velocity and start_beat), which are left undescribed.

  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: "Create a full funk arrangement" across four named tracks (drums, bass, guitar, horns). It clearly distinguishes itself from other arrangement tools by emphasizing the vamp-based, one-chord funk style, explicitly contrasting with chord-progression-based genres.

  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 is for James Brown / Parliament-Funkadelic style funk, vamp-based rather than chord-progression-based, and contrasts with "all other arrangements" that change chords. It does not explicitly name alternative tools or state 'do not use when X', but the genre and stylistic guidance are enough to infer appropriate use cases.

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

• mcp_opendaw_create_harmonic_arrangementA
  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 full behavioral transparency burden. It discloses track placement (pads on track 2, arp track 3, bass track 1, etc.), default shared tracks, and skip values. However, it does not state whether this creates new tracks or modifies existing ones, whether the operation is destructive, or what happens if target tracks already contain content.

  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 well-structured: summary, layer/track details, parameter list, and four worked examples. It is appropriately sized for a 15-parameter composite tool and front-loads the core purpose, though some redundancy exists between the initial layer list and the parameter explanations.

  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 complex tool with 15 optional parameters and no annotations, the description covers layers, defaults, skip behavior, track assignment, and gives multiple usage examples. An output schema exists, so return values don't need explanation. Gaps remain: start_beat and unit_index are undocumented, and side effects on existing tracks are unclear.

  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 significantly by explaining 13 of 15 parameters, including pattern options (up/down/updown/random/bass), octaves, skip sentinels, and bars_per_chord. It omits start_beat and unit_index, which remain entirely undocumented and could confuse the agent.

  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 a specific verb+resource: 'Create all five harmonic layers from one progression string in one call.' It clearly differentiates from siblings by naming the five component tools it replaces (chord_pads, arpeggiated_progression, bass_from_progression, melody_from_progression, counter_melody_from_progression) and enumerating the exact layers produced.

  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 states it replaces five separate calls and names them, giving strong guidance on when to use this composite tool. It also provides skip conditions for individual layers (e.g., melody_pattern='' to skip melody), but it does not explicitly say when to prefer the individual tools over this composite.

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

• mcp_opendaw_create_house_arrangementA
  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 of behavioral disclosure. It offers rich detail about the musical pattern (four-on-the-floor kick, off-beat bass, chord stabs) and states that it returns notes created per track. However, it does not disclose whether existing notes are overwritten, whether the target tracks must pre-exist, or any side effects. This is a notable 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.

  Conciseness4/5

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

  The description is well-structured with a lead summary, detailed element breakdown, parameter explanations, and usage examples. It is longer than minimal but each section adds value. The examples at the end are practical and concise. No wasted sentences, though the bullet list partially repeats the initial summary.

  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 10-parameter tool, the description covers the creative logic, musical style, parameter meanings, defaults, and return value. The output schema covers return details, so not describing it fully is acceptable. Missing information includes prerequisites (e.g., whether tracks must exist) and overwrite behavior, which prevents a perfect score.

  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 0% description coverage, but the tool description compensates by explaining most key parameters: bpm with range and default, bars with range, root as 'root note for bass and stabs', octave mapping to MIDI, and track index meanings. However, it omits 'velocity' and 'start_beat', so not all parameters receive the same level of semantic explanation.

  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's purpose: 'Create a full house music arrangement — drums + bass + stabs across 3 tracks in one call.' It specifies the verb (create), the resource (house music arrangement with drums/bass/stabs), and the scope (3 tracks), distinguishing it from sibling genre arrangement tools like create_techno_arrangement or create_afrobeat_arrangement.

  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 context for when to use the tool: when a full house arrangement with a classic Chicago/Detroit feel is needed at 124 BPM. However, it does not explicitly mention alternatives or when not to use this tool, so it lacks exclusions. This gives clear context but no direct comparison to sibling tools.

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

• mcp_opendaw_create_korean_percussionA
  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 full burden. It thoroughly explains the musical behavior of the generated ensemble (instrument roles, style-specific patterns) and states return values ('Returns notes created, instrument breakdown, and style info'). However, it does not disclose operational side effects such as whether existing notes are overwritten, whether a new region is created, or what happens if the specified track/unit is invalid. This is a notable 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.

  Conciseness3/5

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

  The description is well-structured with clear sections (introduction, instruments, styles, Args), and the opening sentence is front-loaded. However, it is excessively long, with cultural details like elemental associations and historical notes that are not strictly necessary for invoking the tool. While educational, it could be trimmed without losing operational guidance.

  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 the musical domain, all parameters, styles, and return values, making it highly informative for a complex generation tool. It does not explicitly address operational context (e.g., track/unit setup or side effects), but the output schema likely handles return structure, and the tool's name and sibling set provide some context. Overall, it is nearly complete for its complexity.

  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 includes an 'Args' section that explains every one of the 11 parameters. For example, it clarifies that 'janggu_chwe_pitch' is the left low head, and it defines each style. This adds substantial meaning beyond the bare schema titles, fully compensating for the lack of property 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 opening line states exactly what the tool does: 'Create a Korean traditional percussion ensemble — nongak (farmers' music).' The verb 'create' and resource 'Korean traditional percussion' make the purpose unambiguous, and the detailed instrument and style descriptions further distinguish it from other percussion tools 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 provides rich context for when to use the tool (Korean traditional percussion) and includes detailed style descriptions that guide style selection (e.g., 'nongak' for rural, driving rhythms, 'samul_nori' for modern stage). However, it never explicitly contrasts with alternative percussion tools (like taiko or djembe), leaving the agent to infer boundaries from the name and content.

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

• mcp_opendaw_create_modulated_songA
  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 modulation happens automatically between keys, that pattern parameters apply to all sections, and that setting drum_genre causes pads and bass to be skipped. It also states the default song structure (24 bars, specific sections). Missing are details about whether the tool creates new tracks/regions, overwrites existing data, or any side effects, but for a creation tool this is less critical.

  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 well-structured: it front-loads the purpose, then gives a precise section format, defaults, modulation explanation, parameter details, and examples. Each segment earns its place, though it could be trimmed slightly (e.g., the modulation explanation in prose could be moved to comments). The examples are valuable for an agent.

  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 complex tool with 9 parameters and no annotations, the description is largely complete: it covers the core sections syntax, defaults, drum genre behavior, and usage examples. It does not explain the global velocity parameter or unit_index, and relies on a sibling-tool reference for pattern values, which are minor gaps given the output schema exists. Overall, an agent could call this tool correctly for most intended uses.

  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 must compensate. It thoroughly explains sections, drum_genre (with valid values), and bpm (when used). However, it leaves velocity and unit_index entirely unexplained, and the pattern parameters are only vaguely referenced as 'Same as create_harmonic_arrangement' without listing valid values. This partial coverage warrants a 3, not higher.

  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: 'Build a multi-section song with key modulation between sections — one call.' It clearly differentiates from siblings like create_harmonic_arrangement by emphasizing the multi-section, key-modulating capability and the 'one call' convenience. The scope (sections, progressions, energy) is 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?

  The description provides clear context: use this when you want a multi-section song with automatic key modulation, and it explicitly contrasts with manual start_beat calculation. It also references create_harmonic_arrangement for pattern semantics, implying when that simpler tool might be used, and includes examples for various drum genres. However, it does not explicitly state 'use this instead of X' or list exclusions, preventing a 5.

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

• mcp_opendaw_create_mordentA
  4.1/5.0
  Behavior3/5

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

  There are no annotations, so the description must disclose behavior. It explains the note pattern, parameter defaults, and return value, but does not disclose potential side effects like whether notes are inserted or appended, or any prerequisites beyond specifying unit/track indices.

  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 well-organized, front-loading the purpose, but includes several paragraphs of music theory that, while helpful, could be trimmed; still, no wasted filler and the parameter list is clear.

  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?

  All parameters are explained with defaults and ranges, the return value is stated, and the musical behavior is fully described. Given the absence of schema descriptions, the description is complete enough 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%, and the description compensates thoroughly by documenting all 8 parameters with defaults, ranges, and musical meaning (e.g., interval 1=half step, 2=whole step; duration 0.25-4 beats).

  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 'Create a mordent — main note → neighbor → back' which clearly states the action and output. It distinguishes this from sibling ornament tools by specifying the mordent pattern and its upper/lower variants.

  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 musical context (baroque ornament, Bach/Mozart) implying when a mordent is appropriate, but does not explicitly contrast it with create_trill, create_turn, or create_appoggiatura, or 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.

• mcp_opendaw_create_reggae_arrangementA
  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 must carry the full burden of behavioral disclosure. It thoroughly describes the musical output (patterns per track, BPM feel, bass role) and states returns ('notes created per track and total'). However, it does not disclose critical side effects: whether existing notes on the specified tracks are overwritten, whether tracks must already exist, or whether the tool creates tracks. 'unit_index: AU index with note tracks' implies an existing unit, but the mutation behavior is unstated.

  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 well-structured with bullet points per track and a clear opening summary. It includes examples and front-loads the primary purpose. However, it is somewhat repetitive: the 'one-drop' concept and 'bass is the lead' are explained multiple times (in the intro, in track descriptions, and in the BPM paragraph). Some trimming could improve conciseness without losing substance.

  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 11 parameters, 0% schema coverage, and no annotations, the description is largely complete: it covers musical style, defaults, parameter meanings, and return behavior. It also references the output schema ('Returns notes created per track and total'). Gaps remain: two parameters undescribed and no mention of prerequisite/destructive behavior. Despite these gaps, the description provides enough context for an agent to decide whether and how to invoke 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?

  Schema coverage is 0%, so the description must compensate. It adds meaningful context for 9 of 11 parameters: bpm (65-95 range, 80 = classic roots), bars (4-16), root ('A is a classic reggae key — Am'), octave ('2 = A2=45, standard reggae bass register'), unit_index, and all four track indices. However, it omits 'velocity' and 'start_beat', leaving those two parameters without any additional explanation beyond the schema defaults.

  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: 'Create a full reggae arrangement — one-drop drums + melodic bass + skank guitar + organ across 4 tracks.' It clearly distinguishes this tool from siblings by explicitly contrasting reggae's one-drop feel with rock and funk, and by stating 'fundamentally different from all 10 other arrangements.' The musical specifics (track 0 = drums, track 1 = bass lead, etc.) remove any ambiguity about the tool's 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 implies clear usage context: use for roots reggae arrangements at 65-95 BPM, with examples of classic keys (A) and tempos (72, 80). It differentiates from other genres by explaining how rock and funk handle kick placement versus reggae's drop on 3. However, it does not explicitly name alternative tools (e.g., create_rock_arrangement) or state when NOT to use this tool, so it falls short of full exclusion guidance.

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

• mcp_opendaw_create_second_lineA
  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 describes the instrument behaviors and style variations in detail (e.g., 'BASS DRUM — Deep boom. Plays the street beat'), which is valuable. However, it does not disclose operational side effects such as whether existing notes are overwritten, whether a target track must pre-exist, or how the tool mutates project state beyond 'Create'.

  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 purpose, followed by well-organized sections for instruments, styles, args, and return value. Though it includes a historical paragraph that may be extraneous for tool invocation, the structure is clear and every section serves a purpose.

  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 11-parameter tool with 5 style options and an output schema, the description covers all parameters with constraints, enumerates styles with musical detail, and mentions the return value. It lacks explicit operational prerequisites or side-effect warnings, but given the available output schema and complexity, it is largely 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 compensate. It adds constraints and examples: bars ('4-16, even'), velocity ('0-1'), pitches ('36 = C1'), and style values are enumerated with character descriptions. However, unit_index and track_index are only minimally described as 'AU index' and 'Note track index', which is terse but understandable.

  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: 'Create a New Orleans second line percussion ensemble — street parade groove.' This clearly states the tool's function and distinguishes it from sibling tools like create_drum_pattern or create_clave, which are generic or for other genres.

  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 usage context: 'Create a New Orleans second line percussion ensemble' tells the agent when to invoke it. However, it does not explicitly exclude alternatives or mention when not to use it, such as preferring a different genre tool, so it falls short of providing explicit guidance.

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

• mcp_opendaw_create_techno_arrangementA
  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 must disclose behavior. It describes the musical output in detail and says it returns notes created per track and total. However, it does not state whether it overwrites existing notes, requires pre-existing tracks, or any destructive side effects, leaving operational behavior unclear.

  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 well-structured with a clear opening, bullet-pointed track breakdown, parameter docs, and examples. Some stylistic phrases could be trimmed, but overall every section earns its place given the tool's complexity.

  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 purpose, musical style, parameters, and return value, which is strong for a 10-parameter tool. It misses prerequisites (e.g., that tracks must already exist) and the two undocumented parameters, so it's 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?

  Schema coverage is 0%, so the description compensates by explaining bpm, bars, root, octave, unit_index, and track indices with ranges and defaults. It does not mention velocity or start_beat, which leaves two parameters undocumented.

  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 states it creates a full techno arrangement with specific elements (drums, sub-bass drone, percussive stabs) across 3 tracks. It clearly distinguishes from siblings by naming the tracks and explicitly noting the sub-bass drone is the key difference from house.

  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 context for when to use it: for Berlin/Detroit techno, and notes the difference from house. It provides recommended parameter ranges (130 BPM, longer forms) but does not explicitly list when not to use or alternatives beyond the house comparison.

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

• mcp_opendaw_create_ternary_formA
  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 transparency burden. It discloses key behaviors: melody is placed on track_index and bass on track_index+1, a_prime_ornamented adds ornaments to the return, and each b_contrast type has distinct musical characteristics. It does not mention side effects like overwriting existing notes, but provides substantial behavioral clarity.

  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 lengthy but well-structured, with clear sections for form definition, usage examples, B section types, A' behavior, and track placement. It front-loads the primary purpose, and each section earns its place. Slightly verbose but appropriate for the musical complexity.

  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 complexity (10 params, no schema descriptions, no annotations), the description covers most essential aspects: the form's structure, historical/usage contexts, parameter semantics for key musical choices, and output placement. An output schema exists, so return values are not required in the description. It is nearly complete but could mention prerequisites or unit behavior.

  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 must compensate. It adds deep meaning for b_contrast (five types with detailed musical descriptions), a_prime_ornamented (ornamentation effect), and track_index (placement). However, parameters like a_bars, b_bars, velocity, scale_name, start_beat, and unit_index are not explained beyond their names, leaving gaps.

  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 'Create ternary form — ABA with contrasting middle section,' clearly stating the verb (create), resource (ternary form), and structure (ABA). It distinguishes this tool from siblings like create_binary_form and create_sonata_form by specifying the ABA layout.

  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 rich usage context, listing musical genres where ternary form is appropriate (minuet & trio, da capo aria, Chopin nocturnes, pop/jazz ballads). It explains B section contrast types and A' ornamentation, helping users decide when to use this tool. However, it does not explicitly contrast with alternative form-generation tools.

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

• mcp_opendaw_create_value_clipA
  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 transparency burden. It does disclose that the clip is created empty ('an empty ValueEventCollectionBox') and that it operates on the specified automation track. However, it does not mention potential side effects such as overwriting an existing clip at the given clip_index, failure behavior on invalid indices, or whether the operation is reversible. This is a moderate level of 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 and well-structured: a one-sentence purpose, an implementation note, a four-item parameter list, and a one-line return note. Every line earns its place, with no repetition of schema details and 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?

  The tool is a simple creation operation, and the description covers the core behavior, parameters, and return value. The output schema exists (per context) so the vague 'Returns clip creation details' is acceptable. Missing context includes prerequisites (did the automation track exist?) and behavior when the clip slot is already occupied, but these are not critical for a basic creation 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?

  The schema provides zero description coverage, but the description compensates fully by listing each parameter with a brief explanation: unit_index (audio unit), track_index (with the special -1 value), name (label), and clip_index (0-based). This adds meaning well beyond the bare schema property names and also teaches the indexing conventions.

  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+object+context: 'Create a value clip (automation clip) on an automation track in session view.' This clearly distinguishes this tool from siblings like create_audio_clip or create_note_clip, and the reference to ProjectApi.createValueClip further cements its purpose.

  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—creating an automation clip on a Value-type track—but does not explicitly state when to use this tool over alternatives (e.g., create_automation_event or add_automation) or when not to use it. No exclusions or alternative tool mentions are provided.

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

• mcp_opendaw_delete_automation_eventA
  4.1/5.0
  Behavior3/5

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

  The annotations already declare destructiveHint=true, so the description does not need to restate that deletion is destructive. It adds the scoping detail that only a single event is removed and notes that success or error is returned, but it does not disclose additional traits like irreversibility or effects on neighboring events.

  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 action, followed by a clean parameter list. Every sentence and line adds value, 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?

  The tool is simple, and the description covers the core function, parameters, and return behavior. It could improve by mentioning how to discover the correct indices (e.g., using list_automation_events) and any side effects, but given the output schema exists and the operation is straightforward, it 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 zero description coverage for parameters, and the description fully compensates by defining each index: unit_index (audio unit), track_index (track within the unit, specifically an automation track), and event_index (event within the track's value region). This adds meaningful hierarchical semantics beyond the bare integer names.

  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 'Delete a single automation event (ValueEventBox) from an automation track', using a specific verb and resource. It distinguishes from sibling tools like create, update, move, and duplicate automation events by focusing on deletion of a single event.

  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 (when you need to remove an automation event) and explains the meaning of each index parameter, but it does not explicitly state when to use this tool versus alternatives or mention that one might need to list events first to obtain valid indices. This is adequate but not fully guiding.

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

• mcp_opendaw_delete_markerA
  4.1/5.0
  Behavior3/5

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

  The destructiveHint annotation already declares the operation is destructive, aligning with the 'Delete' verb. The description adds no extra behavioral context such as irreversibility or index shifting after deletion. It does not contradict the annotation, but adds minimal value beyond it.

  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 the main action first and the parameter explanation second. Every word contributes; there is no padding or repetition. It is appropriately sized for the tool's simplicity.

  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 delete operation with an output schema present, the description covers the core functionality and parameter semantics. It could mention that deleting a marker may shift subsequent indices, but this is a minor gap given the simplicity and the annotation coverage.

  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 an integer title for marker_index with no description. The description compensates fully by explaining 'marker_index: Index from list_markers (0-based)', which gives the source and base for the index—essential 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?

  The description states 'Delete a timeline marker by index' with a specific verb ('delete') and resource ('timeline marker'). This clearly distinguishes it from sibling tools like delete_warp_marker and set_marker_position, which operate on different marker types or actions.

  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 referencing list_markers for the index, suggesting a prerequisite call. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or context beyond the index source.

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

• mcp_opendaw_detect_problemsA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the safety profile is known. The description adds input path expectations (WAV in exports dir or absolute path) and output structure (severity + recommendation), which are useful behavioral details beyond annotations.

  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 summary, and the detailed bullet list is substantive rather than redundant. It's somewhat long but each item adds useful information about the detected problems, and the example is helpful.

  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 an output schema, the description covers input format, output shape, and the problem categories. It could mention limitations such as file size or duration handling, but overall it is sufficiently complete for straightforward 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 provides no description for the single 'filename' parameter (0% coverage). The description compensates by defining what filename means ('WAV file in exports dir, or absolute path') and gives a concrete example call, making the parameter semantics clear.

  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 explicitly states the tool detects technical audio problems and enumerates 7 specific issue types (clipping, DC offset, hum, sibilance, mud, harshness, resonances), giving a clear, specific verb+resource. This distinguishes it from sibling analysis tools like analyze_spectrum or measure_lufs, which focus on different aspects.

  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 when technical mix problems are suspected, but gives no explicit guidance on when to choose this over alternative analysis tools. There are no exclusion criteria or named alternatives, leaving the agent to infer the tool's appropriate context.

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

• mcp_opendaw_expand_intervalsA
  4.1/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 explains the transformation algorithm in detail (interval multiplication, anchor handling, snapping) and parameter constraints. However, it does not disclose side effects like undo behavior or whether notes are modified in-place, though the mutating nature is inherent.

  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: a one-line summary, a short explanation with examples, and a parameter breakdown. Despite its length, every sentence adds value, and the most critical 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 complex transformation with 7 parameters, the description covers the core logic, anchoring, snapping, and concrete examples. It does not mention prerequisites (e.g., region must contain notes) or potential clipping/range limitations, but the output schema likely handles return value 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%, and the description fully compensates by explaining all 7 parameters, including defaults, constraints (factor 0.25-4.0), and the meaning of each anchor option and snapping scale. This goes well beyond the bare 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 'Expand or compress melodic intervals by a factor' — a specific verb and resource — and elaborates on the mechanism. It does not explicitly reference sibling tools for differentiation, but the unique interval-multiplication behavior makes it distinct.

  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 in motivic development ('This is a fundamental transformation in motivic development') and provides factor examples, but it does not explicitly state when to choose this tool over alternatives such as invert_notes or double_melody, nor does it mention any exclusions.

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

• mcp_opendaw_freeze_audiounitA
  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. It discloses the offline rendering mechanism, the caching behavior, and the fact that frozen AUs play from cache instead of real-time processing. It also mentions potential errors (sidechain dependents block freeze). This goes beyond a generic 'freeze' and explains real-world 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 organized into a summary, implementation details, a constraint, a parameter note, and a return note. It is about 80 words and contains no filler. The internal API reference (audioUnitFreeze.freeze()) is slightly extra but adds credibility without bloating the 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 single-parameter tool with an output schema, the description covers purpose, mechanism, constraints, parameter meaning, and possible return. It does not mention related operations (unfreeze, freeze status) or performance implications (long render time), but these are available as sibling tools. Overall, it is nearly complete for a focused freeze operation.

  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?

  The only parameter is unit_index, and the schema description coverage is 0%. The description adds 'AU index to freeze,' which clarifies what the index refers to, but does not explain how to discover the AU index (e.g., via list_effects or get_effect_chain) or whether it is zero-based. This is minimal compensation for the schema gap.

  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: 'Freeze an audio unit — pre-render its output offline to save CPU.' This clearly distinguishes it from siblings like unfreeze_audiounit and get_unit_freeze_status, and explains the primary benefit.

  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 a clear use case (save CPU by pre-rendering) and gives an explicit exclusion: 'Cannot freeze AUs with sidechain dependents or the Output unit.' It doesn't explicitly point to alternative tools for unfreezing or status checks, but the context is sufficient for an agent to decide when to invoke it.

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

• mcp_opendaw_get_full_project_stateA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the description only needs to add context. It adds that the tool returns a complete snapshot in one call, enumerating the included data categories. This is a useful disclosure of scope without contradicting 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?

  The description is two sentences: the first states the function and contents; the second adds the usage context. Every word contributes to understanding the tool, 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?

  Given the tool's simplicity (no parameters, read-only annotation, output schema present), the description is sufficient. A brief note about the potential size of the response or comparison to mcp_opendaw_get_project_state could enhance completeness, but it's not necessary.

  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 already covers everything. The description's mention of the snapshot scope (AUs, tracks, regions, effects, mixer state) indirectly explains what the single call returns, but no parameter details are needed beyond 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 uses a specific verb ('Get') and a clearly defined resource ('complete snapshot of the project') with enumerated components (AUs, tracks, regions, effects, mixer state). However, it does not explicitly distinguish itself from the sibling tool mcp_opendaw_get_project_state, relying on the word 'full' to imply 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?

  Explicitly states the ideal context: 'Useful for agents to understand the current state before making changes.' This provides clear guidance on when to use the tool, though it does not 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.

• mcp_opendaw_get_note_rangeA
  4.1/5.0
  Behavior3/5

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

  The annotations already declare readOnlyHint: true, so the safety profile is covered. The description adds minimal behavioral context beyond that: it mentions 'or error' and lists return fields, but does not detail error conditions, permissions, or any other behavioral traits. With annotations in place, the description does not carry the full burden, so a 3 is appropriate.

  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 well-structured: opening sentence, return summary, parameter list, and return list. It is front-loaded and each line serves a purpose, though the opening sentence and the return list slightly overlap in stating the outputs.

  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 read-only getter with an output schema, the description covers all necessary aspects: purpose, parameters, and return values. The mention of error behavior is vague, but the overall tool is simple and the annotations plus output schema fill in the rest.

  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 description coverage, so the parameter definitions in the description are essential and valuable. Each parameter (unit_index, track_index, region_index) gets a concise semantic explanation ('AU index', 'Note track index within the AU', 'Note region index'). While not exhaustive, it compensates well 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.

  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 ('Get') and resource ('pitch range and max duration of notes in a note region'), and immediately distinguishes itself from sibling tools by specifying exact outputs (min pitch, max pitch, longest note duration). The name is reinforced and 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?

  The description provides clear context for when to use the tool ('useful for determining the vocal/instrument range and planning transpose operations'), but it does not explicitly mention alternatives or exclude other tools. This is sufficient for a simple getter, though it could be stronger with explicit 'use instead of' guidance.

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

• mcp_opendaw_get_piano_modeA
  4.1/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals this is a safe read operation. The description adds the list of return fields, which is useful context, but does not disclose potential error scenarios or how the data is structured beyond the output schema. This is adequate for a simple getter but not rich in behavioral detail.

  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, front-loaded with the core purpose, and lists the return elements efficiently. No superfluous words 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?

  Given the simplicity of the tool (no parameters), the presence of an output schema, and the annotation, the description is complete. It covers what the tool does and what it returns, which is all that 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 the schema coverage is 100% (no properties). The description doesn't need to explain parameters, and the baseline for zero-parameter tools is 4. It provides no parameter semantics because none exist, but this 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?

  The description clearly states the tool's function: 'Get piano roll view settings' and enumerates the exact fields returned (keyboard type, time range, note scale, note labels, transpose). This distinguishes it from sibling tools like set_piano_keyboard and set_piano_time_range, making its 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?

  The description implies when to use the tool (when you need to retrieve piano roll view settings) but does not explicitly mention alternatives or when not to use it. The sibling setter tools are evident from context, but the description itself provides no direct comparison or exclusion guidance.

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

• mcp_opendaw_get_project_durationA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds the specific definition of duration (end of last region) and return format (beats and seconds), plus the possibility of an error. This enriches behavioral understanding without contradicting 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?

  The description is two concise sentences with no redundant wording. It front-loads the main verb and resource, then adds definition and return format. 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, read-only getter, the description fully covers what it does, what it returns, and how duration is computed. The output schema provides the rest. No major 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 tool has zero parameters, so the schema fully covers parameters. The description appropriately omits parameter details. Baseline of 4 applies due to zero-parameter design.

  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 retrieves the total project duration, defined as the end position of the last region across all tracks. This specific definition differentiates it from other getters like get_project_info. The mention of return units (beats and seconds) further clarifies 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?

  The description provides no guidance on when to use this tool versus alternatives. It doesn't mention exclusions or context where another tool should be used. The usage is implicitly clear from being a simple getter, but the description itself lacks explicit guidance.

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

• mcp_opendaw_get_studio_settingsA
  4.1/5.0
  Behavior3/5

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

  The readOnlyHint annotation already declares the safe read-only nature. The description adds that it returns all settings categories with current values, which is useful but minimal. No additional behavioral traits such as response format or error conditions are 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 two clear, front-loaded sentences with no redundancy. The parenthetical list of categories adds value without bloating the text.

  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, read-only getter with an output schema, the description is complete. It states what is returned (all settings categories with current values), and the annotation covers the safety profile. No critical context 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 the input schema is fully empty (coverage 100%). The description correctly adds no parameter details, which is appropriate. A baseline of 4 is warranted for zero-parameter 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 clearly states the tool retrieves all studio preferences/settings and enumerates the specific categories (engine, visibility, editing, debug, storage, time-display, pointer). This is a specific verb+resource description that distinguishes it from sibling tools like set_studio_setting.

  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 to fetch current settings but does not explicitly state when to prefer it over other getter tools (e.g., get_engine_status, get_project_state) or mention any exclusions. 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.

• mcp_opendaw_get_unit_freeze_statusA
  4.1/5.0
  Behavior4/5

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

  With readOnlyHint=true already indicating a safe read, the description adds valuable context: the meaning of freeze status, the sidechain-dependent limitation, and the exact return fields (frozen, can_freeze, has_sidechain_dependents). It does not contradict annotations, and the added behavioral detail goes beyond the structured data.

  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: it states the primary purpose in the first sentence, then gives a one-sentence concept explanation, a one-line parameter note, and a one-line return description. Every sentence earns its place with no redundant 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 read-only query with one parameter, the description covers the purpose, key constraints, and return values, which is sufficient for an agent to invoke it correctly. A minor gap is the lack of detail about valid unit_index values, but overall it is nearly complete for the tool's simplicity.

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

  Parameters2/5

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

  The only parameter, unit_index, is described merely as 'AU index,' which essentially restates the schema title 'Unit Index.' It does not explain whether indices are zero-based, how to discover valid indices, or what happens on an invalid index, so it fails to compensate 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 opens with a clear verb+resource: 'Check if an audio unit is frozen and whether it can be frozen,' which precisely identifies what the tool does. It also distinguishes itself from sibling tools like freeze_audiounit and unfreeze_audiounit by being a query rather than a mutation.

  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 when the check is relevant: freeze status indicates pre-rendered audio, and an AU with sidechain dependents cannot be frozen. This implies the tool should be used before attempting to freeze, but it does not explicitly name 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.

• mcp_opendaw_list_samplesA
  4.1/5.0
  Behavior3/5

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

  The readOnlyHint annotation is present, so the safety profile is already known. The description adds that it returns UUIDs and metadata, which is useful context, but it does not disclose additional behavioral traits such as pagination or performance implications. It does not contradict 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?

  The description is two short, front-loaded sentences with no redundant wording. Each sentence adds value: the first defines the action and scope, the second specifies the return content. Optimal conciseness.

  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 simplicity (no parameters, read-only, output schema present), the description is complete. It clearly states what is listed (all audio file samples used in the project) and what is returned (UUIDs and metadata), leaving no ambiguity about the tool's purpose.

  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, and the schema is empty. Per the rubric, the baseline for 0 parameters is 4. The description does not need to explain parameter semantics since none exist, and it correctly focuses on the output.

  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 ('List') and resource ('audio file samples used in the project'), and specifies the scope ('all'). It distinguishes from sibling tools like list_playfield_samples by focusing on samples 'used in the project'.

  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 when one needs to list project samples, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. No comparison to list_playfield_samples or other similar tools is given, leaving the context inferred.

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

• mcp_opendaw_list_vaporisateur_paramsA
  4.1/5.0
  Behavior4/5

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

  Annotations already mark this as read-only, and the description adds meaningful context: the unit_index '-1 = auto-detect' behavior and a detailed breakdown of the returned state. This goes beyond the annotation by explaining what specific data will be returned and how to target the synth, though it does not address error cases like a missing Vaporisateur unit.

  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 efficiently structured with a one-line summary, parameter explanation, and a bulleted return breakdown. The trailing 'etc.' is vague but does not significantly undermine the overall clarity; every major section 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 single-parameter read tool with an output schema and read-only annotation, the description covers the essential aspects: what state is retrieved, how to target the synth, and the structure of the response. It lacks only edge-case behavior (e.g., no Vaporisateur found), which is minor for a getter.

  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%, but the description explicitly explains the only parameter: 'unit_index: Audio unit index (-1 = auto-detect Vaporisateur)'. This adds semantic value beyond the bare integer type, including the special sentinel value, making the tool usable.

  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 'Get full Vaporisateur synthesizer state' which uses a specific verb and resource, clearly distinguishing it from sibling setters like set_vaporisateur_osc_param and generic getters like list_instrument_params. The listed sections (oscillators, LFO, noise, main) further clarify scope.

  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 context implies this tool is for reading all Vaporisateur parameters at once, but no explicit alternatives or exclusions are mentioned. An agent might not know when to prefer this over get_effect_state or list_instrument_params, though the specialized name and return structure give reasonable guidance.

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

• mcp_opendaw_load_audioA
  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 transparency burden. It discloses the URL-vs-base64 loading behavior and performance implications, but does not clarify side effects (e.g., whether a track is created, overwrite behavior, or error handling). Some behavioral insight is provided but not comprehensive.

  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-line purpose followed by per-parameter explanations. Every sentence adds useful information without redundancy or 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?

  The description covers the two main parameters and loading behavior, but leaves ambiguity about what 'load into the DAW project' means in practice (e.g., does it create an audio track or just import an asset?). With an output schema present, return values are not needed, but broader operational context could be clearer.

  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?

  Both parameters are explained beyond the schema: file_path describes required absolute path and the public-directory optimization; name is described as optional with a default, though the schema marks it required (a minor inconsistency). This substantially 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 ('Load') with a clear resource ('audio file') and destination ('DAW project'), and lists supported formats (WAV/MP3/FLAC/OGG). This clearly distinguishes it from sibling tools like create_audio_track or import_audio_to_tracks, which serve different actions.

  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 practical guidance on when to use certain loading paths, such as placing files in headless-daw/public/ for faster URL-based fetching versus base64 otherwise. It does not explicitly compare against alternatives, but the context is clear and actionable.

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

• mcp_opendaw_measure_lufsA
  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 full responsibility. It reveals the algorithm implementation details (K-weighting, gating, formula), which is highly transparent about how measurements are computed. It also states the return values, though it doesn't mention failure modes or 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 efficiently organized with a summary, algorithm bullet points, parameter explanation, and returns. It's slightly verbose due to the algorithm details, but those 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?

  The tool is simple (one parameter) and has an output schema, so the description needn't detail return structures. It covers the main aspects, though it omits prerequisites like ensuring the file exists or that the export is 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 a 'filename' string with a title, but the description adds crucial meaning: it's a WAV file in the exports directory, without path. This compensates well for the schema's 0% 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 it measures LUFS and true peak of an exported WAV file, with a specific verb and resource. The detailed algorithm description further distinguishes it from other analysis 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?

  It specifies the target (exported WAV file) but does not offer explicit guidance on when to choose this over sibling analysis tools like analyze_dynamics or get_audio_file_info. The use case is implied for loudness measurement, but no exclusions or alternatives are listed.

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

• mcp_opendaw_repeat_phraseA
  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 clearly explains the repetition, transposition, placement, and cross-track preservation behavior. However, it does not explicitly state whether the default operation modifies the source region, whether it creates new regions, or if the operation is reversible — significant gaps 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.

  Conciseness4/5

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

  The description is front-loaded with a clear one-sentence summary, followed by useful musical context and a well-organized Args section. The musical examples (Bach, jazz, etc.) are somewhat verbose but add context. The length is justified by the 0% schema coverage, though it could be trimmed slightly.

  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 complexity (13 parameters) and the presence of an output schema, the description is highly complete. It explains the operation, all parameters, options, and even musical applications. It lacks only explicit side-effect statements, but the detailed parameter and behavior documentation covers nearly all necessary 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%, but the description fully compensates with a detailed Args section covering all 13 parameters, including ranges, defaults, examples, and mode explanations. This goes far beyond the schema's mere titles and defaults, making parameter meanings immediately 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 description opens with a specific verb+resource+scope: 'Repeat a melodic phrase N times with transposition.' It distinguishes from repeat_notes, but confusingly attributes the entire-phrase copy behavior to 'create_sequence' rather than this tool, which may blur identity with the sibling create_sequence. This is a clear purpose with a minor naming 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?

  The description explicitly contrasts with repeat_notes (individual notes vs entire phrase) and explains the musical context for sequences, giving clear when-to-use signals. However, it does not provide explicit when-not-to-use guidance beyond the repeat_notes contrast, and the create_sequence reference introduces ambiguity about which tool to choose.

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

• mcp_opendaw_replace_from_presetA
  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. It explains that the tool swaps the instrument, optionally keeping effects/timeline (defaults imply they are not kept), and specifies the compatibility constraint. It also mentions the return type (success or error). This is meaningful behavioral context beyond the schema, though it doesn't discuss reversibility or 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 concise and well-structured: a purpose statement, a method reference, a compatibility note, a bullet-style parameter list, and a return statement. Every sentence earns its place 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?

  The description covers purpose, parameters, constraints, and return behavior. Given the tool's complexity (5 params, mutation, no annotations) and the presence of an output schema, it is quite complete. It could add guidance on when to use it (covered under usage guidelines) or what happens with invalid presets, 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?

  Schema coverage is 0% (no property descriptions in the schema), but the description thoroughly explains each parameter: unit_index, preset_b64, and the three keep_* flags. This fully compensates for the schema gap and adds precise meaning, including defaults and provenance (preset_b64 from export_preset).

  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 'Replace an audio unit's instrument/effects/timeline from a preset' with a specific verb and resource. It also names the underlying method and the optional elements (MIDI effects, audio effects, timeline). However, it does not explicitly differentiate from similar tools like mcp_opendaw_replace_instrument, so it falls 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?

  The description implies usage with presets from 'export_preset' and notes the compatibility requirement (MIDI→MIDI, Audio→Audio), but it does not explicitly state when to use this tool instead of alternatives such as mcp_opendaw_replace_instrument or mcp_opendaw_import_preset. No exclusions or alternative tool references are provided.

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

• mcp_opendaw_set_clip_propertiesA
  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 full burden of behavioral disclosure. It does reveal important behaviors: skip semantics for optional updates, that it operates on session-view clips, and that it 'Returns updated clip properties.' However, it does not address error cases, side effects, or permissions, leaving room for improvement.

  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. It leads with a clear purpose, then uses a compact parameter list with inline skip semantics. Every sentence adds value, with no redundancy 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?

  Given the 7 required parameters and the presence of an output schema, the description is nearly complete. It covers all parameter meanings, special sentinel values, and the return value. It lacks explicit statements about index base (zero vs one) and error handling for invalid indices, but overall it's sufficient for correct invocation in most 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 coverage is 0%, so the description must compensate. It does so excellently by explaining every parameter, including skip values, ranges (hue 0-360), source (clip_index from list_clips), and units (duration in beats). This is far beyond the bare schema titles.

  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's function: 'Set properties on a clip (session view): label, color, mute, duration.' This specific verb+resource+fields combination distinguishes it from single-property siblings like set_clip_mute, set_clip_label, and set_clip_hue, and the session view qualifier adds further specificity.

  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: when you need to set multiple clip properties at once. It hints at a workflow by noting 'clip_index (from list_clips).' However, it never explicitly contrasts with the sibling set_clip_* tools or states when NOT to use this tool, so guidance is 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.

• mcp_opendaw_set_modular_module_paramA
  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 of disclosing behavior. It states the tool returns success or error and provides meaningful parameter context (e.g., physical units for value), but it does not discuss side effects, prerequisites, or potential pitfalls like invalid parameter names. It is not misleading, but it 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 compact and front-loaded: one sentence for purpose, a bullet-like list of parameter meanings, and a one-sentence return note. Every sentence earns its place with no 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?

  The tool has five required parameters, no annotations, and no schema descriptions. The description provides enough detail to invoke it correctly, including the meaning of each parameter. It could further clarify valid ranges for indices or how to discover module types, but those are likely discoverable via sibling list tools, and the 'success or error' note covers return handling.

  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 the description fully compensates by explaining every parameter: au_index (Audio unit index), effect_index (Effect index within the AU), module_index (Module index), param_name with concrete examples, and value with units (dB, ms). This goes far beyond the bare schema field names.

  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's action: 'Set a parameter on a module in a Modular device.' It specifies the target resource (module parameter) and includes examples like "gain" for ModuleGain and "time" for ModuleDelay, which distinguishes it from sibling tools like set_effect_parameter.

  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 does not explicitly state when to use this tool versus alternatives such as set_effect_parameter or set_instrument_param. Usage is implied by the name and parameter context, but no exclusions or alternative references are provided, leaving the agent to infer 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.

• mcp_opendaw_set_region_loopA
  4.1/5.0
  Behavior4/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 that loop_beats=0 disables the loop and describes how offsets shift loop/event positions, adding valuable operational detail. It does not, however, cover potential side effects, idempotency, or error conditions.

  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?

  Purpose is stated in the first sentence, with subsequent lines dedicated to behavioral clarification and parameter meanings. Each line serves a distinct purpose; the structure is efficient and easy to scan.

  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?

  Output schema exists, so return values are covered elsewhere. The description documents all six required parameters and explains loop semantics, making it self-contained for invocation. Minor gaps like how to obtain indices or what happens to existing loop settings are acceptable given the schema.

  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?

  All six parameters receive semantic explanation beyond the bare schema titles: loop_beats includes a concrete example (4.0 = 1 bar in 4/4), unit_index documents the -1 sentinel, and region_index notes 0-based indexing. This 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.

  Purpose4/5

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

  States 'Set loop parameters for a note region' with a specific verb and resource, followed by behavioral explanation of looping. However, it does not differentiate from similarly named sibling tools like mcp_opendaw_set_loop_region or mcp_opendaw_set_region_duration.

  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?

  Provides contextual detail about loop behavior and region duration but offers no explicit guidance on when to choose this tool over alternatives. No exclusions or alternative tool references are mentioned, so it's 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.

• mcp_opendaw_set_region_positionA
  4.1/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 action and parameter details but does not mention reversibility, side effects, permissions, or edge-case behavior. For a mutating tool, this is 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.

  Conciseness5/5

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

  The description is extremely concise: a single-sentence purpose followed by bullet-like parameter definitions. Every line adds value and the structure is immediately 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?

  All required parameters are fully explained, including practical examples. An output schema exists, so return values need not be described. Minor gaps like error conditions or range validation are absent but not critical for this 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?

  The description provides thorough explanations for all five parameters, including units (beats), concrete examples (4.0 = start of bar 2), valid values (note/audio), and special sentinel behavior (unit_index -1 = search all AUs). This far exceeds the bare schema titles.

  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 'Move a region to a new position on the timeline,' which is a specific verb+resource statement. It clearly identifies the operation and distinguishes it from sibling tools like set_region_duration or move_region_to_track.

  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 conveys when to use this tool: to reposition a region on the timeline. It does not explicitly mention alternatives or exclusions, but the context is unambiguous for this operation.

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

• mcp_opendaw_set_script_device_codeA
  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 does well: it details the compilation process (parsing @param/@sample, validation, registering worklet module, writing code back), and even states the effect on the device. It doesn't mention potential side effects or failure modes, but the covered steps are informative and honest.

  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 moderately long but well-structured with bullet points and a clear explanation of the compilation steps. Every sentence adds value, and the @param/@sample syntax examples are useful. It could be slightly shortened without losing information, but it remains focused and readable.

  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 complexity of scriptable devices and a 4-parameter schema, the description is largely complete. It explains the tool's behavior, the device types, and the code syntax. It also points to external references (plans/apparat.md) for further API details. Since an output schema exists, return values don't need explanation. The main gap is the lack of clarity about unit_index/device_index, but overall context is solid.

  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 must compensate for the lack of parameter documentation. It adds meaning for 'code' (JavaScript code defining a Processor class) and 'device_type' (listing 'apparat', 'werkstatt', 'spielwerk'). However, 'unit_index' and 'device_index' are not explained beyond their schema names, leaving a gap for an agent that needs to know how to address the correct device.

  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's function: 'Set the user JavaScript code on a scriptable device (Apparat/Werkstatt/Spielwerk).' It uses a specific verb ('Set') and resource ('user JavaScript code on a scriptable device'), and the parenthetical enumeration of device types adds clarity. It is easily distinguished from siblings like get_script_device_code.

  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 when to use this tool: when setting user JavaScript code on scriptable devices, via the OpenDAW ScriptCompiler. It lists the device types and details the compilation steps, giving clear context. It doesn't explicitly exclude alternatives, but the context is sufficient for selecting this tool in most cases.

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

• mcp_opendaw_set_send_routingA
  4.1/5.0
  Behavior3/5

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

  With no annotations, the description defines the two routing modes and their meanings ('pre-fader, before volume/pan' vs 'post-fader'), which explains the main behavior. However, it does not disclose potential side effects, prerequisites (e.g., send must exist), or error conditions.

  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: a single purpose sentence followed by three one-line parameter definitions. Every sentence adds necessary information with no redundancy 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 setter with three parameters, the description covers all necessary aspects: purpose, parameter meanings, and value explanations. It could optionally mention whether indices are zero-based or that the send must already exist, but these are not critical 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%, but the description fully documents every parameter: unit_index (source audio unit index), send_index (send index), and routing with allowed values and their meaning. This entirely 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 clearly states 'Set the routing mode for an aux send', specifying the exact action and resource. It distinguishes itself from sibling tools like set_send_level and set_send_pan by focusing on routing mode (pre/post).

  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 its clear purpose, but does not explicitly state when to use this tool versus alternatives or provide exclusions. It is unambiguous enough for an agent to infer, but lacks explicit guidance.

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

• mcp_opendaw_set_stereo_tool_panningA
  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 must carry the full behavioral burden. It discloses the allowable values for panning_mixing (0=linear, 1=equal-power, or other supported values), which is useful. However, it does not state whether the operation is reversible, whether it triggers any side effects, or what the return value/output is. This is adequate for a simple setter but leaves some 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?

  The description is concise: a one-sentence purpose followed by three compact parameter lines. Every sentence earns its place, and the structure is front-loaded with the core purpose before parameter details. 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 simple setter, the description covers the essential aspects: what it does, all parameter meanings, and constraints (must be StereoTool). The presence of an output schema means return-value details are not required in the description. A minor gap is the lack of guidance on what happens if effect_index does not point to a StereoTool, but this is not critical for a basic setter.

  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 explicitly defines all three parameters, adding semantic meaning beyond the input schema's bare titles. It clarifies that unit_index is the AU index, effect_index is the index in the audio effect chain (with the StereoTool requirement), and panning_mixing includes explicit value mappings. This 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 opens with a specific action-verb and resource: 'Set the panning mixing mode on a StereoTool effect.' This clearly differentiates it from sibling tools like set_track_panning (which targets track-level panning) and generic set_effect_parameter tools. 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 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 a StereoTool exists in the effect chain) by stating 'must be a StereoTool.' However, it does not explicitly contrast with alternatives such as set_effect_parameter_int or other effect-specific setters. It provides a necessary precondition but no exclusion or alternative guidance.

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

• mcp_opendaw_set_vocoder_band_countA
  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 full burden. It adds useful behavioral context (band count range and the vocoder requirement) but does not disclose side effects, error behavior, or what happens if the effect is not a Vocoder. This is minimal but not inadequate for a simple 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 extremely concise: one sentence for purpose followed by three lines of parameter explanations. It is front-loaded with the main action and contains no filler, making every line earn 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 simple setter tool with an output schema present, the description is quite complete: it covers purpose, parameter meanings, and the key constraint (must be a Vocoder). It does not detail error handling or return values, but the output schema likely covers that, so the description suffices for its complexity.

  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 JSON schema has 0% description coverage, and the description manually explains all three parameters: unit_index ('AU index'), effect_index ('Effect index in the audio effect chain (must be a Vocoder)'), and band_count ('Number of bands (8, 16, 24, 32 are common values)'). 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.

  Purpose5/5

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

  The description clearly states the tool's action: 'Set the band count on a Vocoder effect' and adds context about typical values (8-32). This is a specific verb+resource combination that distinguishes it from other effect-specific setters 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 Guidelines3/5

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

  The description provides the constraint that effect_index 'must be a Vocoder', which is useful context, but it does not explicitly mention when to use this tool over generic parameter setters like set_effect_parameter_int. There are no alternatives or when-not-to-use statements, so usage guidance is only implied.

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

• mcp_opendaw_set_vocoder_modulator_sourceA
  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 responsibility of disclosing behavior. It states the action ('Set') and lists allowed source values, which clarifies that it is a mutation of a setting. However, it does not describe side effects, prerequisites beyond the effect type, or error behavior. The listing of valid source values adds some transparency, but the description is relatively thin.

  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 well-structured: a single opening sentence followed by a bullet list of parameter explanations. No unnecessary words or repetition. Every sentence carries information. It is front-loaded with the core purpose.

  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 operation, the description covers the essential context: the target effect type (Vocoder) and the parameter meanings. It does not explain return values, but an output schema exists and likely covers that. Missing are details about side effects or behavior when constraints are violated, but given the low complexity, the description is nearly 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 input schema provides only names, types, and required status, with 0% schema description coverage. The description fully compensates by explaining each parameter: unit_index as 'AU index', effect_index with the constraint 'must be a Vocoder', and source with an explicit list of allowed values ('noise-white', 'noise-pink', 'noise-brown', 'self', 'external'). This adds substantial meaning 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 clearly states the tool's function: 'Set the modulator source on a Vocoder effect.' This uses a specific verb ('set') and a specific resource ('modulator source on a Vocoder effect'), which distinguishes it from sibling tools like set_vocoder_band_count. 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 Guidelines3/5

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

  The description implies usage context by specifying that effect_index 'must be a Vocoder', but it does not explicitly state when to use this tool versus alternatives. There is no mention of exclusions or alternative tools (e.g., generic set_effect_parameter). The constraint provides some guidance, but the 'when' is only implied.

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

• mcp_opendaw_set_waveshaper_equationA
  4.1/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 does not mention whether the existing equation is overwritten, any side effects, or what happens if the effect is not a Waveshaper. The description only states the action with no behavioral 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 efficiently structured: one purpose sentence, then each parameter explained in a compact format, followed by a bullet-style list of equation values. No redundant wording or unnecessary detail. Every line adds 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 straightforward setter with three parameters, the description covers purpose, parameter semantics, and the range of equation values. The output schema exists, so return value is assumed. It could mention error behavior, but overall it 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?

  Schema description coverage is 0%, but the description fully compensates. It defines unit_index as 'AU index', effect_index with a constraint, and equation with six named options, each accompanied by a concise sonic description (e.g., 'tanh: classic smooth saturation'). This goes 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 opens with 'Set the transfer function equation on a Waveshaper effect.' This is a specific verb+resource statement that clearly identifies the tool's purpose. It distinguishes itself from sibling tools like generic effect setters by targeting the waveshaper specifically.

  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 a key constraint ('effect_index ... must be a Waveshaper') and includes a detailed list of equation choices with descriptions, helping the agent choose appropriate values. It doesn't explicitly name alternatives, but the specialized nature and the constraint provide clear context for when 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.

• mcp_opendaw_spread_voicingA
  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. It explains the algorithmic behavior for each mode: 'move every other note up by spread_octaves octaves' for open, 'collapse all chord tones into the lowest possible octave' for close, etc. It also discloses the return values. However, it does not explicitly state whether the tool modifies the region in place or if any permissions are required, which 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.

  Conciseness4/5

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

  The description is well-structured with clear sections: an overview, mode-by-mode explanations, parameter details, return values, and a usage example. It is longer than necessary but every sentence contributes useful information. The organization aids readability and quick scanning.

  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 tool has an output schema, so return values need not be explained, yet they are listed for clarity. The description covers the core transformation logic, parameter semantics for most parameters, and includes practical examples. It falls short on clarifying side effects (e.g., whether the original notes are overwritten or if the operation is reversible), which is important for an editing tool. Overall, it is quite complete for its complexity.

  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 must compensate. It thoroughly explains 'mode', 'chord_position', and 'spread_octaves' with concrete examples and ranges. However, the required parameters 'unit_index', 'track_index', and 'region_index' are not described at all; the example call (spread_voicing(0, 2, 0, 4.0, ...)) provides a hint but is insufficient for full understanding. The description adds value but does not fully fill the schema gap.

  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's function: 'Spread or compact a chord voicing — open vs close harmony.' It specifies a precise verb+resource pair and differentiates itself from sibling tools by focusing on chord voicing spacing. The detailed mode explanations (open, close, drop2, drop3) further clarify its 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 provides clear context for when to use each mode, e.g., 'open' for jazz piano sounds, 'close' for tight block chords, and 'drop2' as a classic jazz comping technique. It does not explicitly name alternatives but gives enough contextual guidance for an agent to choose among modes. It lacks explicit exclusions or comparisons to other transformation tools.

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

• mcp_opendaw_update_warp_markerA
  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 of behavioral disclosure. It discloses the -1 leave-unchanged behavior and the return of updated marker values. However, it does not describe error conditions, side effects, what happens if both parameters are -1, or any constraints on valid marker indices.

  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, beginning with the core action, followed by the sentinel rule, then a clear parameter list, and finally the return value note. Every sentence serves a purpose, 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.

  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 annotations, no output schema details, and zero schema description coverage, the description covers all parameters, the -1 sentinel behavior, and the return type. It lacks error handling details and a reference to list_warp_markers for obtaining valid indices, but it is sufficiently complete for a straightforward update 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?

  With 0% schema description coverage, the description fully compensates by defining all six parameters: unit_index, track_index, region_index, marker_index, position_beats, and seconds. It explains the meaning of each index and the -1 default semantics for the optional position/seconds parameters, going well beyond the bare schema titles.

  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's action with a specific verb and resource: 'Update a warp marker's position and/or seconds value.' This distinguishes it from sibling tools such as create/delete/list warp markers, and the parameter list reinforces the exact scope of the 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?

  The description uses language like 'Update a warp marker' to imply that it is for modifying existing markers, but it does not explicitly contrast this with create/delete/list alternatives or state when not to use it. The -1 sentinel guidance is helpful for usage mechanics, but no direct usage context versus siblings is provided.

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

• mcp_opendaw_apply_mix_presetA
  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 full burden. It explains the operation, parameter format, and return value, but lacks details on side effects (e.g., whether existing settings are overwritten, behavior on invalid indices), reversibility, or prerequisites. It adds useful context but not complete 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.

  Conciseness4/5

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

  The description is slightly verbose but every sentence is informative. It is front-loaded with the primary purpose, then details the parameter format, examples, and return value. The structure is logical and scannable, though a bit dense.

  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 is quite complete: it covers the main use case, parameter format, built-in options, and return value. However, it does not differentiate from similar batch tools like apply_full_mix or apply_genre_mix, and misses edge cases like invalid presets or partial application. Given no annotations, it's strong but has 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?

  The input schema has a single 'preset' parameter with zero description coverage. The description fully compensates by providing the exact JSON structure, named presets, and multiple examples. This is exemplary parameter documentation that goes far 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 clearly states 'Apply a mix preset to all audio units in one call — volume, pan, mute, solo.' This specifies the action, target scope, and attributes, distinguishing it from individual set_track_* tools. It also mentions the batch nature, which separates it from 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?

  The description explicitly says 'Replaces 10-30 set_track_volume/set_track_panning/set_track_mute calls,' providing a clear alternative and when this tool is beneficial. It does not explicitly state when NOT to use it, but the context strongly implies the batch-vs-individual tradeoff.

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

• mcp_opendaw_automation_sweepA
  4.2/5.0
  Behavior3/5

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

  No annotations exist, so the description carries the full burden. It discloses a key side effect: 'Automatically creates the automation track if it doesn't exist yet.' It also explains it generates multiple events and returns a preview. However, it does not mention whether existing automation events are overwritten, whether the operation is reversible, or any error conditions, which is significant for a write tool.

  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 well-organized with an overview, parameter list, return note, and example. Every section is useful, though it is somewhat long. The parameter list is necessary given the 0% schema coverage, and the example is valuable. Minor redundancy: the first sentence and the later transition mention overlap.

  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 purpose, full parameter semantics, return value, and a notable side effect (track creation). It is complete enough for an 8-parameter tool with no annotations. It lacks explicit error handling or edge-case info (e.g., what if start_beat > end_beat), but the provided details are strong.

  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 zero descriptions (coverage 0%), so the description must compensate. It does so thoroughly: every parameter is documented with units (beats, normalized values 0.0-1.0), defaults (steps=16, curve='linear'), curve options with guidance ('exp' for filter sweeps), and an example that ties them together. This exceeds the baseline 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 clear verb+resource+scope: 'Create a smooth automation sweep (ramp) between two values over a beat range.' It further explains the mechanism (generates interpolated events) and gives concrete examples (filter sweeps, volume fades), distinguishing this general-purpose tool from more specific siblings like create_filter_sweep or create_volume_fade.

  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 context—'creating smooth parameter transitions'—and lists typical use cases (filter sweeps, volume fades, pitch drops). It does not explicitly name alternatives or exclusions, but the use cases make it clear when this tool is appropriate. Lacks explicit 'use this instead of X' guidance.

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

• mcp_opendaw_classify_drum_patternA
  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 behavioral disclosure. It details what is analyzed (drum note positions, pitches with GM mapping, velocities) and the output structure (classification, confidence, features, per-bar breakdown), which gives a thorough understanding of the operation. It does not explicitly state that the tool is read-only, but the analysis-oriented language makes this implicit.

  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 organized into clear sections: a one-sentence summary, analysis method, use cases, parameters, and return value. While it is fairly long, the GM drum map list adds useful domain context for a specialized tool. Each section earns its place; no superfluous 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 covers the essential aspects for using this tool correctly: what it does, what inputs to provide (including default semantics), what it returns, and when it is valuable. Given the complexities of drum pattern classification and the existence of an output schema, the description is sufficiently complete, though it could mention edge cases such as empty regions or non-GM-mapped notes.

  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 zero description coverage, so the description must compensate. It does so effectively by explaining each parameter ('unit_index: AU index (-1 = all AUs)', 'track_index: Note track index (-1 = all note tracks)', 'region_index: Region index (-1 = all regions on track)'), including the meaning of defaults. This goes well 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 clearly states the tool's purpose with a specific verb ('classify') and resource ('a drum pattern from MIDI notes in a region'). It enumerates the pattern types and explains the analysis inputs, making the tool's function unambiguous. However, it does not explicitly differentiate itself from similar drum-analysis siblings like transcribe_drums or extract_rhythm.

  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 explicit use cases under 'Essential for:' (understanding existing drum patterns, matching genre expectations, verifying generated patterns, suggesting variations), giving clear context for when to invoke the tool. It does not mention exclusions or alternatives, which would earn a 5, but the stated purposes are sufficiently specific.

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

• mcp_opendaw_copy_region_fadesA
  4.2/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. It discloses the exact behavior (which fade properties are copied from the source Fading object to the destination Fading object) and the return value ('Returns the copied fade values'), making the mutation of the destination explicit. It does not cover error cases or permissions, but the core side effect is clear.

  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 tightly structured and front-loaded: one purpose sentence, one technical detail sentence, two parameter-grouping lines, and one return statement. There is no filler or repetition; every sentence adds essential 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?

  Given six required parameters and no annotations, the description covers the operation, exact affected fields, parameter roles, and return value. It does not describe how to locate region coordinates or handle invalid selections, but the presence of an output schema and the focused scope make it reasonably complete for invoking the tool.

  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 coverage is 0%, so the description must compensate. It adds grouping: src_unit/src_track/src_region are source coordinates and dst_unit/dst_track/dst_region are destination coordinates, which is useful. However, it does not explain what a 'unit' represents or how the IDs relate, leaving some ambiguity for an agent that is unfamiliar with the DAW model.

  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: 'Copy fade in/out settings from one audio region to another.' It then names the exact fields copied (fadeIn, fadeOut, fadeInSlope, fadeOutSlope), which distinguishes it from related tools like set_audio_region_fade that would modify fades rather than transfer 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?

  Clear context is provided: the tool copies fades from a source region to a destination region, with source/destination coordinate triples described. It does not explicitly compare against alternatives such as set_audio_region_fade, but the copy-versus-set distinction is evident from the wording, and there are no exclusion criteria stated.

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

• mcp_opendaw_create_acid_arrangementA
  4.2/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 substantial behavior: creates 3 tracks at track_index, track_index+1, track_index+2, with detailed drum patterns, bassline velocity variations, and lead placement. It stops short of stating side effects like overwriting existing tracks or preconditions, but the creation behavior is well 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?

  The description is well-organized: a clear opening summary, a background section on acid house, and a numbered list of track details. Every sentence serves a purpose, and the structure makes it easy to scan while providing rich context.

  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 tool has 7 parameters and no annotations, but the description covers core creation behavior, style, and track specifics, and an output schema exists. It lacks parameter-level detail for several fields and side-effect disclaimers, but for a genre-specific arrangement generator, it is largely complete.

  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 must compensate. It explains track_index (via track layout), bpm (125 BPM default), and key_root (A minor). However, bars, velocity, start_beat, and unit_index are not described, leaving several parameters unexplained.

  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 clearly: 'Create an acid house arrangement — TB-303 squelch bassline.' It specifies the verb, resource, and genre, and differentiates from sibling tools by detailing the exact track structure (drums, bass, lead) and musical characteristics. This makes the tool's 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?

  Provides strong contextual cues: genre definition, characteristic elements (TB-303, 909, 125 BPM), and track composition. This helps an agent identify when this tool is appropriate, but it does not explicitly mention alternatives or exclusion scenarios, so it misses clear '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.

• mcp_opendaw_create_euclidean_rhythmA
  4.2/5.0
  Behavior3/5

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

  Since no annotations are provided, the description carries the full burden. It discloses key behaviors: it creates notes, returns a binary pattern and Euclidean notation, and applies velocity accents (+0.15 to first onsets). However, it does not explicitly mention potential side effects like whether it replaces existing notes or appends to a track, nor does it address permissions or reversibility.

  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 useful musical examples, a clear parameter list, return values, and concrete usage examples. Every section earns its place and there is no 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 10-parameter tool with no annotations and an output schema, the description provides substantial context: algorithm explanation, typical patterns, parameter details, return information, and examples. The main gap is the three undocumented parameters (start_beat, unit_index, track_index), which are likely important for target placement.

  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, this description compensates well by explaining onsets, steps, rotation, bars, pitch, velocity, duration, including ranges and constraints (e.g., 'steps must be >= onsets'). It misses start_beat, unit_index, and track_index, which are only shown in the schema, so it is not fully comprehensive.

  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 clear, specific statement: 'Create a Euclidean rhythm — distributes k onsets across n steps as evenly as possible.' It also explains the algorithm and lists classic rhythms (E(3,8)=tresillo, E(7,16)=samba), which clearly differentiates it from sibling tools like create_drum_pattern or create_clave.

  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 rich context about Euclidean rhythms and their musical uses, implying when to use this tool (e.g., for tresillo, samba, or bembé patterns). However, it does not explicitly state when not to use it or name alternatives among the many sibling tools, 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.

• mcp_opendaw_create_hocketA
  4.2/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It explains split modes with concrete examples, defaults, and return values ('notes created, voice assignment, total duration'). However, it doesn't disclose error behavior (e.g., insufficient tracks) or side effects on existing data, leaving minor gaps in transparency.

  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 well-structured with a clear one-line purpose, a brief explanatory paragraph, and a bulleted parameter list. The historical context is interesting but consumes precious space; it could be trimmed without losing functional value. Overall, it's concise relative to the 8 parameters covered.

  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, explains the concept, and mentions return values. It lacks explicit prerequisites (e.g., need for an existing AU with note tracks) and error scenarios, but the default behavior for unit_index is noted. This is nearly complete for a creation tool of moderate complexity.

  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 explaining every parameter: melody format, voices range, split_mode options with distribution examples, unit_index fallback, track_index usage, start_beat, note_duration with default, and velocity range. This is exemplary parameter documentation.

  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 creates a hocket, defined as 'a single melodic line split between voices/tracks'. This specific verb+resource pairing distinguishes it from sibling creation tools like create_chorale or create_counterpoint. The historical context further clarifies the musical technique.

  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 what a hocket is and how the tool works, but provides no explicit guidance on when to choose this tool over alternatives. Sibling tools like create_chorale or create_counterpoint exist for similar melodic splitting tasks, and the description doesn't delineate scenarios where hocket is preferred.

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

• mcp_opendaw_create_instrument_trackA
  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 that the tool creates an instrument AU and track, connects to the output AU's bus, and returns unit_index and track_index. However, it does not mention potential side effects, prerequisites (e.g., engine running), or whether the operation is reversible, which would be valuable for an agent to understand the tool's impact.

  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 sentences, front-loading the core purpose, then adding a parameter note and return value info. Every sentence contributes useful information without redundancy or unnecessary length.

  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 creation tool, the description covers the main aspects: what it creates, why it's needed, and what it returns. It lacks explicit mention of prerequisites or error conditions, but given the simplicity and the presence of an output schema, the description is largely complete for an agent to select and invoke the tool appropriately.

  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 a parameter named 'name' with no description. The description compensates by explaining it is a 'Display name for the instrument (default "Tape")' and also documents the return values for use with place_audio_region. This adds 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 uses a specific verb 'Create' and identifies the resource as 'a new instrument audio unit with a Tape device and an audio track'. It also explains why this is needed ('required for audio playback'), clearly distinguishing it from sibling tools like create_synth_track or create_audio_track by focusing on the Tape device and output bus connection.

  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 context for when to use the tool: 'This is required for audio playback — the Tape device reads audio regions and outputs sound.' This implies the tool is essential for setting up playback, but it does not explicitly name alternatives or state when not to use it, which is a minor gap.

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

• mcp_opendaw_create_pedal_pointA
  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 bears the full burden. It does disclose important behavioral traits: the retrigger_pedal distinction ("pedal re-triggers at each chord change. If false, one long sustained note") and return values ("Returns notes created, chord count, pedal duration"). However, it fails to disclose potential side effects for a write operation in a DAW — crucially, whether existing notes are overwritten or preserved, and what prerequisites must hold for the target track/AU.

  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 well-structured: purpose definition → musical context → parameter breakdown → return values. The front-loaded definition is immediately clear. The musical context paragraph is illustrative but somewhat verbose relative to the agent's needs; it could be condensed to one sentence. The parameter section is necessarily long because schema coverage is 0%, so the length is largely justified.

  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?

  This is a complex 11-parameter compositional tool, and the description covers its function, musical contexts, complete parameter semantics, and return values (output schema exists, so detailed return docs aren't required). The notable gap is the lack of explicit side-effect disclosure — whether the tool appends notes, replaces existing content, or creates new regions — which matters for a DAW writer tool with no annotations. This prevents a perfect score.

  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 11 parameters with rich semantics: defaults and ranges ("bars_per_chord: Bars each chord lasts (1-8, default 1)"), value formats ("Comma-separated chord names (e.g. "Cm,Ab,Eb,Bb")"), supported chord types ("maj, min, m7, maj7, dom7, sus2, sus4, dim, aug"), time signature examples ("3/4=3, 4/4=4, 6/8=6"), and MIDI meaning ("36 = C2, low and powerful"). This far exceeds what the 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+resource: "Create a pedal point — sustained bass tone under changing chords." This precisely defines the tool's function and its musical concept, distinguishing it from similar compositional siblings like create_ostinato, create_bordun, and create_ground_bass by describing a sustained bass under changing harmony (not a repeated pattern). The cultural examples (Hans Zimmer drones, Bach organ preludes, rock ballads) further anchor the purpose.

  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: "A foundational technique in film scoring (Hans Zimmer drones), organ preludes (Bach), and rock ballads" — telling the agent when this technique is stylistically appropriate. However, it does not explicitly name sibling alternatives or state when not to use it (e.g., vs. create_ground_bass or create_chord_progression), 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.

• mcp_opendaw_create_pop_arrangementA
  4.2/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 details how each track behaves across sections, the chord progression, and section lengths. However, it does not mention whether existing notes on target tracks are overwritten or if there are any destructive 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.

  Conciseness3/5

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

  The description is well-structured with sections, bullets, and an example, but it is verbose. The musical theory explanations (chord progression comparisons) are informative but could be trimmed without losing essential guidance. Every sentence earns its place, but some could be more concise.

  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 complex 4-track arrangement tool with 11 parameters, the description covers track behaviors, section structure, parameter ranges, and an example. Given that an output schema exists, return values are not over-explained. Missing operational details like prerequisites for unit_index and handling of existing notes keep it from a 5.

  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 descriptions are absent (0% coverage), so the description compensates by explaining most parameters: bpm range, bars range, root note, octave MIDI value, and track indices. It misses velocity and start_beat, and does not deeply explain unit_index, but overall adds substantial meaning 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 clearly states the tool creates a full pop arrangement with verse-chorus-bridge structure across 4 tracks. It is specific about the output and distinguishes itself from loop-based arrangements and other genre arrangements.

  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 when this tool is appropriate (pop music with real song form) and differentiates it from loop-based arrangements, rock (I-IV-V), and jazz (ii-V-I). It does not explicitly name alternative tools, but the context is clear and actionable.

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

• mcp_opendaw_create_soliA
  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 behavioral transparency. It discloses the core behavior (unison melody with octave doublings), the pattern syntaxes, and the exact track placement ('Creates voices on track_index, track_index+1, ... track_index+voices-1'). However, it does not state whether existing notes are overwritten or whether target tracks must already exist, which 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.

  Conciseness4/5

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

  The description is well-structured with a definition, parameter explanations, and a clear side-effect note. The genre history and fugue/canon comparison are useful albeit slightly lengthy. Every section contributes to understanding, but it could be tightened without losing value.

  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?

  This is a complex 10-parameter tool with no annotations, and while the description covers most core concepts, it omits explanations for unit_index, start_beat, and velocity. It also does not clarify what happens if melody and rhythm pattern lengths differ. The output schema exists, so return values are covered, but the missing parameter semantics are notable for a tool of this complexity.

  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%, but the description compensates well by explaining most parameters: melody/rhythm patterns, key root, scale names, voices, octave spread, and track_index. It leaves velocity, start_beat, and unit_index undefined, so it is not fully complete, but the added detail is substantial.

  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's purpose: 'Create a soli — ensemble unison passage with octave doublings.' It defines what a soli is, provides musical context, and explicitly distinguishes it from fugue and canon, which are sibling tools. The verb and resource are specific and 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 rich musical context (jazz big band, orchestral tutti, rock/metal riffs) and contrasts soli with fugue/canon, implying when to choose this tool over polyphonic or imitative alternatives. However, it does not explicitly name sibling tools or state clear 'use this when...'/'instead of...' exclusions, 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.

• mcp_opendaw_create_synthwave_arrangementA
  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 full transparency weight. It richly details the musical pattern generation (drum hits, arpeggios, chord voicings, BPM range) and mentions return values, but it omits critical operational behaviors such as whether existing notes on the target tracks are cleared, overwritten, or appended, and whether the tracks must pre-exist. This is a notable gap for a DAW 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.

  Conciseness3/5

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

  The description is well-structured with a summary and bullet points, but it is verbose and contains redundancy, such as repeating 'fundamental difference' and elaborating on genre distinctions at length. It front-loads the key purpose but would benefit from trimming redundant prose to focus on essentials.

  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 is comprehensive for a genre-creation tool: it covers all musical parameters, provides two usage examples, states constraints (bars multiple of 4, BPM range), and describes return values. However, it lacks operational context like track prerequisites and overwrite behavior, and doesn't explain velocity or start_beat, which prevents a perfect score.

  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%, but the description compensates by explaining bpm, bars, root, octave, unit_index, and all four track indices with ranges, defaults, and musical rationale. However, velocity and start_beat are absent from the description, leaving those parameters reliant on their self-explanatory names and schema defaults.

  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 'Create a full synthwave arrangement — retro drums + arpeggiated bass + dreamy pads + nostalgic lead across 4 tracks,' which is a precise verb+resource+style statement. It also distinguishes itself from sibling arrangement tools by repeatedly contrasting the arpeggiated bass with house, techno, and reggae, making it unmistakable what this 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 Guidelines5/5

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

  The description provides explicit genre differentiation: 'The arpeggiated bass is the fundamental difference from all 11 other arrangements: house has off-beat stabs, techno has sub drones, synthwave has relentless 16th-note arpeggios.' It also contrasts synthwave with pop to clarify harmonic context, offering clear guidance on when to choose this tool.

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

• mcp_opendaw_create_time_stretched_clipA
  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 disclose behavioral traits. It explains that the tool creates a time-stretched clip in session view and lists parameter semantics, but it does not mention side effects such as replacing an existing clip at clip_index, the need for a valid audio unit/track, or the outcome of the operation (though an output schema exists elsewhere). This leaves some ambiguity about what state changes will 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 efficiently structured: a one-sentence purpose statement followed by a clean list of parameter explanations. There is no redundant or filler content. Every line adds clarificatory value, making it easy to scan and parse quickly.

  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 all parameters and states the session view context, but it lacks important prerequisite and side-effect information: it doesn't warn that the sample must be already loaded via mcp_opendaw_load_audio (though implied by 'ID from'), that the slot must be empty or will be overwritten, or that the audio unit and track must exist. Given the tool's complexity and the absence of annotations, these gaps prevent it from being 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?

  The description explicitly defines each of the 7 parameters, including concrete examples for playback_rate (1.0, 0.5, 2.0) and enumerated values for transient_mode. The schema itself has no descriptions (0% coverage), so the description fully compensates and even adds semantic meaning beyond the schema's basic type 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 clearly states the action: 'Create a time-stretched audio clip in session view.' This is a specific verb+resource+location combination that distinguishes it from related tools like create_pitch_stretched_clip or create_audio_clip. The session view qualifier helps differentiate it from create_time_stretched_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 provides clear context: it creates a clip in session view and references mcp_opendaw_load_audio for sample_id, indicating a prior dependency. However, it does not explicitly mention when to use this tool versus alternatives like create_time_stretched_region, and there are no exclusions stated. Still, the context is sufficient for a user to understand the intended use case.

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

• mcp_opendaw_create_tuplet_groupA
  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 must carry behavioral disclosure. It states the operation is creating a group and ends with 'Returns notes created, tuplet ratio, and timing info', providing some outcome transparency. However, it does not explicitly describe insertion/targeting side effects, whether existing notes are modified/overwritten, or any prerequisites on unit_index/track_index.

  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 definition and uses headings/bullets for readability. The common-tuplets list and genre references add useful context but make it longer than strictly necessary; still, no sentence is pure 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?

  It includes conceptual explanation, parameter semantics, return info, and sibling differentiation, which is substantial for a 14-parameter creation tool. It lacks precise details about unit/track targeting semantics and edge-case constraints, but the presence of an output schema and thorough arg descriptions keeps it largely 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%, yet the Args section documents all 14 parameters with ranges, defaults, and examples (e.g., 'tuplet_number: Number of notes to fit in the span (2-16)', 'base_division... 3 in 2'). This fully compensates for the bare schema and adds real semantic 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?

  Description opens with 'Create a tuplet group — irrational rhythm subdivision within a time span', giving a specific verb+resource. It further distinguishes tuplets from polyrhythm and additive rhythm, and the tool name maps directly to this purpose.

  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 contrasts tuplets with polyrhythm and additive rhythm ('Unlike polyrhythm... or additive rhythm...'), which helps the agent choose among sibling rhythm tools. It also lists common tuplet ratios and musical contexts, but stops short of a direct 'use this when / use create_polyrhythm when' formulation.

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

• mcp_opendaw_delete_clipA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare destructiveHint=true, so the description's 'Delete' is consistent. The description adds useful context (session view, returns remaining clip count) but does not disclose additional behavioral traits such as permanence, undoability, or error behavior. It adds some value beyond the annotation but is 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 extremely concise: one leading verb phrase, a parameter list, and a return-value line. Every sentence is informative with no filler. Ideal structure for quick agent parsing.

  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 simplicity of the operation (3 integer params, no enums), the description covers the action, parameter semantics, return value, and session-view context. With an output schema present, no further explanation of return format is needed. It is complete for an agent to select and invoke 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 compensates by explaining each parameter: unit_index as Audio unit index, track_index as Track index, and clip_index as 0-based. It also clarifies indexing, which the schema lacks. This completely addresses the parameter semantics gap.

  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 'Delete a clip from a track (session view)' – a specific verb+resource with contextual scoping (session view). This clearly distinguishes it from other deletion tools like delete_region or delete_audio_unit, and no competing delete_clip sibling exists.

  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 context via 'session view' and mentions the clip_index is 0-based, but it does not explicitly state when to use this tool versus alternatives (e.g., delete_region, delete_audio_region) or any exclusions. No alternatives are named.

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

• mcp_opendaw_delete_noteA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true, so the destructive nature is disclosed. The description adds useful behavioral context: 0-based indexing, the special unit_index=-1 meaning 'search all AUs', and that the tool returns the remaining note count. No contradiction with 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?

  The description is compact and front-loaded: a one-sentence purpose followed by a parameter list, then a return-value line. Every sentence earns its place with no redundancy 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 destructive operation, the description covers the core behavior, all parameter meanings, and the return value. Since an output schema exists, return structure doesn't need elaboration. It omits explicit error handling or invalid-index behavior, but the destructiveHint annotation and parameter details make it sufficiently 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 provides only type and title with 0% description coverage. The description compensates by explaining all four parameters: note_index (0-based, as returned by list_notes), unit_index (-1 searches all AUs), track_index (within the AU), and region_index (0-based containing region). This adds meaningful semantics 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 clearly states 'Delete a single note from a region' – a specific verb and resource. It distinguishes from siblings like delete_note_region, clear_region_notes, and delete_region by explicitly targeting one note rather than a region or a whole region's notes.

  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 purpose implies when to use it (remove a single note), but there is no explicit guidance on when not to use it or what alternatives exist (e.g., clear_region_notes to delete all notes, delete_region for whole-region deletion). The parameter explanations help clarify the targeting context, but usage boundaries are not articulated.

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

• mcp_opendaw_duplicate_effectA
  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. It discloses the core behavior (copying all parameter values, supports audio and MIDI chains) and the return value. However, it omits side effects such as whether the new effect is inserted immediately after the original, whether index shifting occurs, or if the original is left untouched (though 'duplicate' implies this). This is minimal but adequate.

  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 action in the first sentence, followed by a brief provenance note, parameter explanations, and return value. It is compact and well-ordered, though the issue #273 line is slightly tangential and could be omitted without loss of clarity.

  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 3 parameters and an output schema, the description covers all necessary invocation details: each parameter is defined, the return type is mentioned, and the supported chain types are stated. It lacks minor behavioral details (e.g., index shifting), but overall it provides a complete picture for an agent to use 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?

  The input schema has zero parameter description coverage, but the description explicitly explains all three parameters: unit_index, effect_index, and chain_type, including the default value 'audio' and allowed values. This fully compensates for the schema's lack of descriptions and adds context that is essential 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 opens with a specific verb and resource: 'Duplicate a single effect within an AU's effect chain, copying all parameter values.' It clearly distinguishes this from siblings like duplicate_audiounit (whole unit) and clone_effect_chain (entire chain). The scope (single effect, both audio and MIDI chains) 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?

  The description notes it addresses upstream issue #273 (Ctrl+D for audio effects) and states it works for both audio and MIDI effect chains, giving useful context for when to invoke it. However, it does not explicitly mention any alternatives or when-not-to-use conditions, so it stops short of full usage guidance.

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

• mcp_opendaw_duplicate_regionA
  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. It discloses key behaviors: copy is placed right after the original, find_free_space scans for first gap on any track, and it returns position and index. It does not mention undoability or error handling, but it provides meaningful behavioral context beyond the schema.

  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 well-structured with a clear opening, placement behavior, parameter list, and return value statement. It is slightly longer than necessary but every sentence adds value and the format is readable.

  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 tool has 4 required parameters, no annotations, and an output schema. The description explains the operation, parameter semantics, and return value. It lacks edge-case behavior (e.g., invalid indices, overlap prevention when find_free_space=False) but is sufficiently complete for a duplication 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%, but the description explicitly explains all four parameters, including special values (unit_index=-1 means search all AUs), zero-based region_index, and exact behavior of find_free_space. 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 clearly states 'Duplicate any region (audio, note, or value)' with a specific verb and resource, and the mention of 'using the DAW's built-in duplicateRegion API' adds specificity. It distinguishes itself from sibling tools like duplicate_note_region by covering all region types.

  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 the two placement modes (with and without find_free_space) and param semantics, giving clear context on execution. However, it does not explicitly mention when to use this tool versus alternatives such as duplicate_note_region or duplicate_audiounit, nor does it provide any exclusions or when-not guidance.

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

• mcp_opendaw_export_mixA
  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. It discloses that all method values effectively use offline rendering, that filename should omit the .wav extension, and that it returns the path and audio metadata. This adds meaningful behavioral context beyond the schema, though it omits potential side effects (likely non-destructive for an export).

  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 organized with a one-sentence summary, engine note, then a parameter list. It is slightly verbose but every sentence adds value. The 'same as render_full' phrase is useful context rather than 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?

  The tool has an output schema, but the description still mentions the return type, which is helpful. It explains the method parameter's real behavior and defaults, and covers the key aspects for a straightforward export operation. Missing only explicit error conditions or prerequisites, but the description is sufficient for a simple 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 description's parameter explanations are essential. It clearly defines filename (without extension), sample_rate default, and the method parameter's accepted values and actual behavior (all use offline). This fully compensates for the missing schema documentation.

  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 'Render the full project mix to a WAV file' – a specific verb and resource. It also references render_full for engine context, distinguishing it from other render/export tools. Name and description align well.

  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 for full-mix WAV export but does not explicitly state when to prefer this over render_full, export_stems, or other render tools. It mentions backward compatibility but provides no exclusions or alternatives, leaving the agent to guess based on partial context.

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

• mcp_opendaw_flatten_note_regionsA
  4.2/5.0
  Behavior4/5

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

  The description discloses a key destructive behavior: 'The original regions are deleted and replaced by a single flattened region.' This goes beyond the schema and annotations (which are absent). It also states the return value ('Returns the new flattened region info, or error'), which sets expectations. It doesn't mention undo/reversibility or edge cases, but the core behavioral trait 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.

  Conciseness4/5

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

  The description is compact at roughly 70 words, with a clear breakdown of purpose, behavior, and parameters. There is a slight redundancy between the first sentence and the second paragraph ('Flatten...into a single region' vs. 'Merges...into one'), which loses a point. Otherwise, each section 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?

  Given the complexity of a destructive merge operation, the description covers the transformation, the side effect of deleting originals, the required parameters, and the return value. Since an output schema exists, it doesn't need to detail the return structure. It could mention the 'overlapping' precondition more prominently, but overall it is sufficient for an agent to invoke 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 compensates by defining each parameter: 'unit_index: AU index,' 'track_index: Track index within the AU,' and 'region_indices: Comma-separated region indices to flatten (e.g. "0,1,2").' This provides meaningful semantics and an example for the trickiest parameter. All three required parameters are explicitly explained.

  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 'Flatten (merge) multiple overlapping note regions into a single region,' which is a specific verb+resource action. It further clarifies behavior by noting original regions are deleted and replaced. It doesn't explicitly distinguish from the sibling 'mcp_opendaw_merge_note_regions,' but the term 'flatten' and the detail about overlapping regions provide a clear purpose.

  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 states this is for merging selected note regions on the same track, which tells an agent when to invoke it. It gives no explicit when-not-to-use or alternatives, but the context is unambiguous for a merge operation. The parameter list reinforces the required inputs.

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

• mcp_opendaw_get_audio_file_infoA
  4.2/5.0
  Behavior4/5

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

  The description adds value beyond the readOnlyHint annotation by listing specific return fields (file name, start/end time, sample loading state) and explicitly noting that it returns an error on failure. It does not contradict annotations and appropriately conveys a side-effect-free inspection behavior.

  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 adequately sized but contains redundancy: 'Returns file name, start/end time in seconds...' is followed by 'Returns audio file info, or error.' The parameter lines are clean and front-loaded, but the repeated 'Returns' wastes a sentence. Overall structure is acceptable but not tight.

  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 the tool's purpose, input parameters, and return value summary. An output schema exists, so detailed return structure is not required. It is sufficient for a simple read-only lookup, though it lacks explicit guidance on how to obtain the indices (e.g., via list_tracks), which is minor.

  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 descriptions for unit_index, track_index, and region_index are essential and clearly explain the hierarchical addressing (AU / track / region). They provide enough meaning beyond the property names to guide correct usage, though they are 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 clearly states the tool's function: 'Get metadata about the audio file referenced by an audio region.' It uses a specific verb ('Get') and resource ('audio file metadata'), and distinguishes it from sibling tools like get_region_info or get_sample_info by focusing on the audio file behind an audio region. The returned data (file name, times, sample loading state) reinforces the purpose.

  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 line 'Useful for inspecting audio regions before processing' gives clear context for when to invoke this tool. It does not explicitly mention alternatives or exclusions, but the read-only intent is implied by the readOnlyHint annotation and the 'before processing' phrasing.

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

• mcp_opendaw_get_midi_effect_chainA
  4.2/5.0
  Behavior4/5

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

  The readOnlyHint annotation already indicates a non-mutating operation. The description adds value by disclosing the return format ('ordered list of MIDI effects with type, enabled state, and index'), which is not covered by the annotation. No contradictions; additional behavioral details like error cases are absent but not critical 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 compact: two sentences for the main action and return, plus one line for the parameter. It is front-loaded with the core purpose and contains 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?

  Given the simple read-only nature, one parameter, and existing readOnlyHint annotation, the description covers the necessary behavior and return structure. It doesn't mention edge cases (e.g., invalid unit_index), but the output schema (present but not shown) likely covers return details. Overall, this is sufficiently complete for a tool of this complexity.

  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 unit_index as an integer with no description. The description supplies the meaning: 'Audio unit index.' This compensates for the 0% schema description coverage. It could be more detailed (e.g., how to obtain the index), but for a single-parameter read-only tool, it is adequate.

  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 'Get the MIDI effect chain for an audio unit' with a clear verb and resource. It further specifies the return content (ordered list with type, enabled state, index), distinguishing it from sibling tools like get_effect_chain (audio effects) and list_midi_effects (likely global listing). 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?

  The description implies this tool is for retrieving a specific unit's MIDI effect chain, but it gives no explicit guidance on when to choose it over alternatives such as get_effect_chain or list_midi_effects. No exclusions or alternatives are mentioned, so usage context is only implicit.

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

• mcp_opendaw_get_mixer_stateA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that it returns a list of channel strips, but does not disclose details like return format, pagination, or whether hidden channels are included. This is adequate but not rich 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, front-loaded with the main purpose. The second sentence adds return info and a use case without waste. Every 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?

  The description covers the purpose, return type, and common use case. Since an output schema exists, return values are already structured. It lacks some nuance about what 'full mixer state' includes exactly, but is sufficiently complete for a read-only tool with no parameters.

  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 no parameters and schema coverage is 100% (vacuously), so there is nothing to add. The baseline for 0 params is 4, and the description does not need to explain any 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 states the tool gets the full mixer state with specific fields (volume, panning, mute, solo, type). This is a specific verb+resource that distinguishes it from sibling tools that set individual mixer parameters or get other project state.

  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 context for when to use ('inspecting the mix balance and routing at a glance') but does not explicitly contrast with alternative tools like get_project_state or list_tracks. It gives a use case but no exclusions or alternatives.

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

• mcp_opendaw_groove_transferA
  4.2/5.0
  Behavior3/5

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

  The description details the algorithm (extracts average timing offsets and velocity ratios, applies them to destination notes) and notes that it modifies timing and velocity. However, with no annotations, it doesn't disclose potential side effects (e.g., irreversibility, prerequisite conditions) beyond the core mutation.

  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 well-organized with a clear first sentence, a concise algorithm explanation, and a structured parameter list. While a bit long, every sentence adds value, and the parameter list is necessary given the 0% schema coverage.

  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, the algorithm, the distinction from copying, and mentions return values ('Returns groove template stats and per-region modification counts'). It lacks explicit prerequisites (e.g., source and destination regions must exist with notes), but overall it's sufficient for an agent to select and 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%, but the description provides a complete per-parameter explanation with defaults and ranges (e.g., 'timing_strength: 0-1, how much timing offset to apply'), fully compensating for the schema's lack of 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 explicitly states 'Transfer groove (timing + velocity feel) from a source region to a destination region' and clarifies 'This is NOT copying notes — it transfers the *feel*,' distinguishing it from note-copying tools and providing a specific, actionable purpose.

  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 context with 'A 1-bar drum groove can be applied to a 4-bar programmed pattern' and explains how the groove cycles, but does not explicitly mention alternatives like quantize or humanize, nor when not to use it. Clear context but no exclusions.

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

• mcp_opendaw_import_dawprojectA
  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. It explains the file format (ZIP containing project.xml, metadata.xml, audio samples) and states that it returns track and sample counts. However, it does not disclose potential side effects like whether the current session is overwritten or if the operation is destructive, which would be valuable 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 concise and well-structured: the main action is front-loaded, followed by beneficial context about the format, and then the args and return value. Every sentence earns its place without unnecessary verbosity.

  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 tool with an output schema, the description covers the essential aspects: what it does, the file format, and the return value. It could improve by mentioning whether the engine must be running or if the import replaces the current session, but overall it provides sufficient context for an agent to use 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?

  Schema coverage is 0%, so the description must compensate. It explicitly documents the 'filename' parameter as 'Path to the .dawproject file to import', providing meaning beyond the bare schema. This explains both the type and purpose, though it could add details like path resolution or file existence requirements.

  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 'Import a .dawproject file into the current session', using a specific verb and resource. It distinguishes itself from other import tools by specifying the .dawproject format and mentioning compatibility with Bitwig, Ableton, and other DAWs.

  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 when to use this tool: when you have a .dawproject file created in another DAW. It provides clear context but does not explicitly mention alternatives or when not to use it, though the format specificity makes the use case clear.

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

• mcp_opendaw_list_audio_busesA
  4.2/5.0
  Behavior4/5

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

  With readOnlyHint already provided, the description adds useful context: the precise scope of what is listed (primary output + FX buses) and the exact return fields (bus index, name, enabled state, audio unit index). It is consistent with the annotation and discloses no 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?

  Two concise, well-structured sentences: the first states the primary action and scope, the second lists return fields. 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?

  For a zero-parameter read-only list with an output schema, the description conveys purpose, scope, and return contents. It omits minor details like behavior when no buses exist, but that is adequately covered by the output schema and the simplicity of the 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, so there is no parameter burden on the description. Baseline for zero-parameter tools is 4, which is met; no parameter explanation is 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 the action ('List all audio buses') and the resource ('audio buses in the project'), with explicit scope ('primary output + FX buses'). It also enumerates the returned fields, distinguishing it from sibling tools that mutate, enable, or remove buses.

  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 as a read-only enumeration ('List all audio buses'), but does not explicitly contrast with other tools that might provide similar or overlapping information (e.g., get_mixer_state, get_project_state). No when-to-use or when-not-to-use guidance is offered.

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

• mcp_opendaw_list_instrument_paramsA
  4.2/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, so the description adds value by explaining the unit_index behavior (-1 auto-detect first non-master AU) and describing the return content (instrument type, parameters with values/units/constraints). No side effects are mentioned, which is consistent with read-only.

  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 with separate lines for purpose, parameter semantics, and return details. Each sentence is informative and there is no redundancy or fluff.

  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 simple one-parameter tool, an output schema, and read-only annotation, the description covers purpose, parameter semantics, supported instruments, and return content. It is sufficiently complete for an agent to select and 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?

  The schema provides no parameter descriptions (0% coverage), but the description explains unit_index's meaning and the special -1 value, adding critical context for correct invocation. This fully compensates for the schema gap.

  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 lists instrument parameters for an audio unit, with a specific verb and resource. It lists compatible instruments, which helps distinguish from effect or MIDI effect tools, but does not explicitly differentiate from sibling tools like list_vaporisateur_params.

  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 for inspecting instrument parameters and notes compatible instrument types, but gives no explicit guidance on when to choose this over alternative list tools (e.g., list_effect_parameters, list_vaporisateur_params) or any exclusions.

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

• mcp_opendaw_list_modular_connectionsA
  4.2/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the read-only nature is established. The description adds that it returns connections with source/target info, which is useful but not deeply behavioral. No contradictions with annotations, and the added return description is minimal beyond what the output schema likely provides.

  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-loaded with the main purpose, and uses clear line breaks for parameter explanations. Every sentence serves a purpose with no extraneous 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 simple read-only list operation, the description covers the tool's purpose, parameters, and return format. With output schema present and annotations for safety, there are no significant gaps in 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?

  The description explicitly explains both parameters: 'au_index: Audio unit index' and 'effect_index: Effect index within the AU.' This adds meaning that the schema lacks, since the schema only lists titles with no descriptions. It 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 states 'List all connections (patch cables) in a Modular device' with a specific verb and resource, making it clear this tool retrieves connection data. It distinguishes itself from sibling tools like list_modular_modules and list_modular_devices by focusing on connections.

  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 context by indicating the tool operates on a Modular device and requires au_index and effect_index, implying when it applies. However, it does not explicitly mention alternatives or when not to use this tool, so usage guidance remains 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.

• mcp_opendaw_list_playfield_samplesA
  4.2/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=true, and the description adds useful behavioral detail by specifying what the returned pad list includes (MIDI note, enabled state, effects). It does not contradict annotations and gives enough transparency for a read-only list 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 compact and front-loaded: a one-sentence purpose, a parameter explanation, and a return summary. Every sentence contributes valuable information without redundancy 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?

  Given the simple nature of the tool and presence of an output schema, the description covers the essential parameter and return categories. It could mention error conditions or default behaviors, but for a listing operation 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?

  Schema description coverage is 0%, but the description fully explains the single parameter 'unit_index' including the special -1 auto-detect value. This compensates for the missing schema documentation and is sufficient for one required 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?

  Description uses a specific verb ('List') and clear resource ('drum pads (samples) on a Playfield drum machine'). It distinguishes from sibling tools like list_samples by focusing on Playfield-specific pads and explicitly mentions the returned fields (MIDI note, enabled state, effects).

  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 for querying Playfield pads but does not explicitly state when to use this tool over alternatives like list_samples or set_playfield_sample_enabled. The unit_index explanation with auto-detect gives some context but lacks exclusions or alternative guidance.

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

• mcp_opendaw_list_signature_changesA
  4.2/5.0
  Behavior4/5

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

  The annotation readOnlyHint=true already covers the read-only safety profile. The description adds value by disclosing the return structure (position in beats, numerator, denominator), which assists in understanding what the tool outputs beyond the annotation. This is meaningful behavioral context, though it doesn't cover sorting or limits.

  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: two sentences, no filler. It front-loads the main action in the first sentence and immediately explains the return data 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.

  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, read-only list tool with an output schema present, the description is complete. It names the specific source (signature track), the scope (all changes), and the key return fields (position, numerator, denominator). No further context is needed given the simplicity and annotation coverage.

  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 empty with 100% coverage. The description correctly focuses on what the tool does rather than explaining nonexistent parameters. Per rubric, a zero-parameter tool gets a baseline of 4, and nothing in the description needs to compensate.

  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's action ('List all time signature changes') with a specific resource ('the timeline's signature track') and even details the returned fields. However, it does not explicitly differentiate from the sibling tool get_signature_events, which could overlap in purpose, so it falls 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 Guidelines4/5

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

  The description provides clear context: this is for retrieving all time signature changes on the signature track. It implies usage for inspection/read purposes, and the readOnlyHint reinforces that. But it does not mention alternatives or exclusions, such as when to use get_signature_events or list_tempo_changes instead.

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

• mcp_opendaw_list_tracksA
  4.2/5.0
  Behavior4/5

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

  Annotations include readOnlyHint=true, which aligns with 'List'. The description goes beyond annotations by detailing the returned structure: audio units with tracks (audio/note/automation), effects chain, volume, panning, and region count. This adds useful behavioral context about the output, with no contradictions.

  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?

  Exactly two sentences: the first states the action and scope, the second summarizes the return details. Every word earns its place, with no redundancy or filler. The action is front-loaded in the first 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 read-only listing tool with no parameters and an output schema present, the description covers the essential aspects: what is listed (tracks across all audio units) and what is included (type, effects, regions, volume, panning, region count). It is complete for practical use, though it omits possible edge cases like empty projects or performance considerations.

  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 empty schema is fully covered. Per the baseline for 0-param tools, the description does not need to explain any parameters and correctly focuses on the result. No room for additional parameter 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 clearly states 'List all tracks across all audio units with their type, effects, and regions' – a specific verb, resource, and scope. It distinguishes from sibling list tools (list_markers, list_notes, etc.) by focusing on tracks and their associated data, making its 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?

  The description implies usage: when an agent needs an overview of all tracks and their properties. However, it provides no explicit guidance on when to use this tool versus other listing tools like list_note_regions or list_effects, nor any exclusions. It's a generic read-only listing context with only implied applicability.

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

• mcp_opendaw_list_transient_markersA
  4.2/5.0
  Behavior4/5

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

  The description states return behavior: 'Returns array of transient positions (in samples) or empty if none.' It also explains what transient markers are, adding context beyond the readOnlyHint annotation. No contradiction with the annotation 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 first sentence states the purpose, followed by a brief definition, use case, parameter guidance, and return value. Each sentence earns its place with no unnecessary verbiage.

  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 read-only listing tool with an output schema, the description covers the key aspects: what it lists, why it is useful, how to locate the region, and what to expect as output. It does not clarify whether sample positions are relative to the region or file, but that 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.

  Parameters3/5

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

  With 0% schema coverage, the description provides the only parameter context: 'unit_index/track_index/region_index: Audio region coordinates.' This gives a collective role for the three indices but does not individually explain their hierarchy or meaning. It offers minimal but non-zero compensation.

  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 clearly: 'List transient markers for an audio region's audio file.' The verb 'List' is specific, and the resource 'transient markers' is well-defined as 'auto-detected hit points in the audio.' This distinguishes it from sibling tools like list_markers and list_warp_markers, which are simpler or different 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 Guidelines4/5

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

  It provides a clear usage context: 'Useful for beat slicing and groove extraction.' This tells the agent when the tool is appropriate. However, it does not explicitly state when not to use it or mention alternative tools (e.g., list_markers for manual markers), 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.

• mcp_opendaw_load_projectA
  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 transparency burden. It discloses that loading restores full project state and requires an engine restart, which is useful. However, it does not explicitly warn that loading overwrites the current project or that unsaved changes may be lost, which would be important 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: purpose sentence, restoration scope, engine restart instruction, and parameter definition. Every sentence earns its place with no redundancy 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 single-parameter tool with an output schema, the description covers the essential context: file location, restoration scope, engine restart requirement, and what return value to expect. It could be improved by noting the overwrite behavior, but overall it is sufficiently complete 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.

  Parameters4/5

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

  The input schema only provides type and title for filename, but the description adds key semantics: 'Name of the .odaw file in the exports directory (without path).' This fully compensates for the schema's lack of description and gives the agent actionable guidance.

  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: 'Load a previously saved project from a .odaw file.' It clearly distinguishes this from sibling tools like save_project or reset_project by focusing on the loading action and restoration of full project state.

  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 a critical explicit instruction: 'The engine must be restarted after loading (call start_engine again).' This gives clear when-to-use context (after a project has been saved) and what to do next, though it does not explicitly name alternatives or exclusions.

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

• mcp_opendaw_place_audio_regionA
  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. It adds the key behavioral constraint about the instrument AU and Tape device, which is valuable. However, it does not disclose failure modes, e.g., what happens if the AU lacks a Tape device or if the beat number is out of range. It also does not state whether the operation is destructive (e.g., overwrites existing regions) or if any 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.

  Conciseness4/5

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

  The description is compact and well-structured: a one-sentence purpose, a short parameter list, and a NOTE for prerequisites. Each line earns its place. Minor redundancy exists (default 0 stated twice for different parameters) and the parameter list could be slightly more concise, but overall it is 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?

  The description covers purpose, parameters, and prerequisites, and references related tools (load_audio and create_instrument_track). It does not explain what a 'Tape device' is or why it is required, nor does it mention potential errors or edge cases. With no annotations and an output schema present but not shown, the description is functionally complete but not fully comprehensive.

  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 four parameters in plain language. It specifies that sample_id is the ID returned by mcp_opendaw_load_audio, defines unit_index and track_index as audio unit and track indices with defaults, and describes start_beat as the beat position. This gives agents sufficient semantic meaning to invoke 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?

  The description starts with a clear verb–resource–object statement: 'Place a previously loaded audio sample as a region on a track.' It specifies the input source (sample_id from mcp_opendaw_load_audio) and distinguishes this from sibling tools like list_audio_regions or delete_audio_region by focusing on placement of a loaded sample.

  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 prerequisite: 'The audio unit must be an instrument AU with a Tape device' and gives a direct next step: 'Use mcp_opendaw_create_instrument_track first if no instrument AU exists.' It also references mcp_opendaw_load_audio as the source of sample_id. It does not explicitly list alternative tools or exclusions, 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.

• mcp_opendaw_randomize_note_chanceA
  4.2/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 chance semantics (100 always plays, 50 half the time, 0 never), the five distribution modes, seed reproducibility, and the return value (per-track note counts and chance range). It falls short of a 5 because it does not clarify the meaning of unit_index/track_index/region_index or whether the operation destructively modifies the original notes.

  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 with a clear title, use-case list, mode explanations, parameter definitions, and concrete examples. Despite being long, every section earns its place, front-loading the primary purpose and using bullet points and examples to convey complex information efficiently.

  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 complexity and the absence of annotations, the description covers the core purpose, all modes, parameter meanings (for the main parameters), use cases, and return value. It is slightly incomplete because it omits explicit explanations of the index parameters, and the output schema is not shown, leaving return-value details to a single sentence.

  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 coverage is 0%, so the description must compensate. It thoroughly explains mode (including all five distributions), min_chance, max_chance, and seed, but it does not explain unit_index, track_index, or region_index beyond showing them in examples. This leaves three of seven parameters without explicit semantic guidance.

  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 'Randomize note playback probability (chance) — generative variation,' clearly identifying the tool's function and distinguishing it from siblings like randomize_note_durations. It provides a specific verb+resource (randomize note playback probability) and explains the outcome (sets a random chance value for each note).

  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 'Perfect for' section explicitly lists four generative use cases (ghost notes, generative melodies, call-and-response, evolving textures), giving clear context for when to use the tool. However, it does not mention when not to use it or name alternative tools for different scenarios.

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

• mcp_opendaw_remove_audio_busA
  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 transparency. It discloses the destructive nature: removing the bus and its associated audio unit, and the index-0 restriction. But it does not mention side effects on sends routed to the bus, reversibility (undo), or any permission requirements. The description covers the core destructive action but lacks richer 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 and front-loaded: first line states the purpose, followed by clear parameter guidance and a constraint. Every sentence contributes unique information with no filler. It is well-organized for quick scanning.

  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 focused removal tool, the description covers the main action, parameter sources, and the critical primary-bus limitation. It does not discuss impact on sends/effects that reference the bus or clarify the return value, but an output schema is present, reducing that need. Overall, it is sufficiently complete for an agent to invoke correctly under most circumstances.

  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 compensate. It explains bus_index must be > 0 and preferred from list_audio_buses, and fx_unit_index is an alternative from create_send. This adds meaning beyond the schema's bare 'Bus Index' and 'Fx Unit Index'. However, the 'either/or' phrasing contradicts the schema marking both as required, creating ambiguity about how to supply 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 opens with a specific verb and resource: 'Remove an FX audio bus and its associated audio unit.' This clearly differentiates from sibling tools like create_audio_bus, list_audio_buses, and set_bus_enabled. The object is precisely an FX audio bus, not a generic bus or send.

  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 two parameter sources: bus_index from list_audio_buses and fx_unit_index from create_send, and warns the primary output bus (index 0) cannot be removed. However, it does not compare with related tools like remove_send or delete_audio_unit to clarify when this tool is preferable. The 'either/or' guidance also conflicts with the schema's both-required constraint.

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

• mcp_opendaw_remove_modular_moduleA
  4.2/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. It explicitly discloses a key side effect: 'All connections to/from this module are also removed.' It also notes the return type (success or error). Missing details like irreversibility, but the major behavioral trait 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?

  Five short lines: one for purpose, three for parameters, one for side effect. Front-loaded and every sentence adds value with no 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?

  Given the tool's simplicity (3 integers, no annotations, no output schema richness needed), the description covers the action, parameters, side effect, and return. It could mention how to obtain valid indices or error behavior, but it is sufficient for a focused mutation 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?

  Schema coverage is 0%, so the description compensates by explaining each parameter: 'au_index: Audio unit index', 'effect_index: Effect index within the AU', 'module_index: Module index to remove.' This adds hierarchical context beyond the bare integer names. It doesn't specify zero-based indexing or how to retrieve valid indices, but it is meaningful.

  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 a specific verb+resource: 'Remove a module from a Modular device.' This clearly distinguishes it from sibling tools like add_modular_module, list_modular_modules, and connect_modular_modules.

  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 implied by the action and parameter context, but there is no explicit 'when to use' or exclusion of alternatives (e.g., remove_effect for non-modular chains). It doesn't mention prerequisites like obtaining indices via list_modular_modules, but the operation itself is straightforward.

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

• mcp_opendaw_reverse_notesA
  4.2/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 states that durations and velocities are preserved while only positions are mirrored, and that region_index -1 targets all regions. It also notes the return value (count of notes reversed), which provides useful context beyond the name.

  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 action, then gives essential behavioral details and parameter definitions. It is reasonably concise with no filler, though the parameter lines could arguably be more detailed without harming readability.

  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 transformation tool, the description covers the operation, preservation rules, scope of region_index, and return value. Since an output schema exists, the description does not need to describe return structure. The context is complete for an agent to decide and invoke 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?

  Schema coverage is 0%, so the description must compensate. It provides one-line explanations for each parameter: unit_index is the AU index, track_index is a note track index, and region_index has an explicit default meaning. This goes beyond the bare schema titles, though 'AU index' could be more fully explained.

  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 'Reverse the order of notes in a region — retrograde variation', which clearly identifies the operation and resource. It distinguishes from sibling tools like rotate_notes or invert_notes by specifying the exact transformation and its musical name, so an agent can select it appropriately.

  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 via the phrase 'retrograde variation', but it does not explicitly compare with alternatives or state exclusions. There is no mention of when not to use it, such as for rotating notes instead of reversing. The guidance is implied by the purpose rather than spelled out.

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

• mcp_opendaw_set_audio_region_gainA
  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 burden of behavioral disclosure. It mentions the underlying Float32Field and that the tool returns the updated gain value, but it does not address potential side effects, undo behavior, or error conditions. It gives some useful domain context (dB scale examples) but lacks deeper transparency about the operation's impact.

  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: first sentence states the action, second gives context, followed by a compact parameter list, and ends with the return value. 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.

  Completeness4/5

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

  For a simple setter tool, the description is fairly complete: it explains the gain semantics, lists all parameters, and states the return value. It does not mention zero-based indexing or how to obtain the indices, nor error handling, but the tool's simplicity and the presence of sibling listing tools mitigate this gap. It is more complete than the mid-calibration example.

  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?

  Since the schema has 0% description coverage, the description compensates by listing all four parameters with brief definitions. It adds meaningful semantics for gain_db with concrete examples ('0 = unity, -6 = half volume, +6 = double'), which goes beyond the bare schema type. The index descriptions are merely restatements, but the overall parameter guidance is adequate.

  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's function with a specific verb and resource: 'Set gain (in dB) on an audio region.' It further distinguishes itself by mentioning the per-region gain control and its use case (trim automation or balancing clips), which sets it apart from sibling tools like set_track_volume or set_audio_region_fade.

  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: 'Use this for trim automation or balancing clips within a track.' It does not explicitly mention alternatives or when not to use, but the stated purpose effectively guides the agent in selecting this tool over other setter tools.

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

• mcp_opendaw_set_delay_syncA
  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. It discloses the constraint that the effect must be a Delay and lists the allowed fraction values. However, it does not mention side effects, reversibility, error behavior, or whether the delay must be in sync mode. Mutation is implied but not explicitly 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 front-loaded with the purpose, followed by a compact parameter breakdown and a necessary enumeration of fraction values. Every sentence and element serves a clear function, with no 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 three-parameter setter with an output schema, the description covers the essentials: purpose, parameter meanings, and allowed values. It does not discuss output or error handling, but the existence of an output schema suggests return values are documented elsewhere.

  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 each parameter: unit_index as 'AU index', effect_index as 'Effect index in the audio effect chain', and fraction with a complete list of allowed values. It provides basic meaning but lacks guidance on how to find the indices.

  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+resource: 'Set the synced delay time on a Delay effect using a musical fraction string.' It explicitly identifies the resource (Delay effect) and the operation (setting synced delay time), and naturally distinguishes from generic effect setters like set_effect_parameter.

  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 context for when to use the tool: to set a synced delay time using a musical fraction, and it includes a prerequisite ('must be a Delay'). It does not explicitly name alternatives or exclusions, but the specificity of the purpose makes the usage context clear.

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

• mcp_opendaw_set_script_paramA
  4.2/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden and does so thoroughly. It discloses exact validation behavior per type (bool snapping, int rounding, linear/exp/unipolar clamping) and mentions the `clamped` flag and `range` info in the response. This is rich, non-obvious behavioral information beyond what the schema provides.

  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 front-loaded, with a clear action sentence followed by a compact bullet list of validation behaviors. Every sentence adds useful information—prerequisite, per-type behavior, and response details—without padding or repetition.

  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 core operation and value validation well, and an output schema exists so return-value details are not mandatory. However, it omits error behavior when the parameter does not exist and does not explain how to correctly identify the target device via the three identifier parameters, which is a notable gap given the 0% schema coverage.

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

  Parameters2/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 all parameters. It explains `value` and `param_label` well, but `device_type`, `unit_index`, and `device_index` are left entirely unexplained. The three identifier parameters are ambiguous in a DAW context, so the description only partially compensates for the missing schema metadata.

  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+scope: "Set a parameter value on a scriptable device by label." This clearly distinguishes the tool from siblings like list_script_params or set_effect_parameter by focusing on scriptable device parameters addressed by label.

  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: the parameter must already exist as a `// @param` declaration, implying it is meant to be used after setting script code and perhaps after listing script params. It does not explicitly name alternatives or exclusions, but the prerequisite is a useful usage guideline.

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

• mcp_opendaw_set_transposeA
  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 burden of disclosure. It covers the key behavioral trait (no audio playback), the parameter range, and the fact that it returns old/new values. Yet it does not explain side effects, reversibility, or what 'global' fully entails, leaving notable 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?

  Three compact sentences: purpose, parameter explanation, and return value. Extremely concise, front-loaded, and every sentence contributes value 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?

  Given the tool's low complexity (single parameter) and the existence of an output schema, the description adequately covers the input and return value. It would benefit from a tiny bit more context on scope (e.g., what 'global' means in terms of tracks), but for its simplicity, it's largely 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 'semitones' as an integer with no description. The tool description adds meaning by specifying it's the number of semitones and provides a valid range (-48 to +48), exceeding baseline 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 the verb 'Set' and the resource 'global transpose for the piano roll view', and it explicitly distinguishes itself from audio-affecting operations with 'does not affect audio playback'. This differentiates it well from sibling tools like transpose_notes.

  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: it's for the piano roll view and does not affect audio playback. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of full exclusion guidance.

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

• mcp_opendaw_update_automation_eventA
  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 skip conditions (value >= 0, non-empty interpolation, curve_slope >= 0) and states that it returns success with updated values. However, it does not describe error handling (e.g., invalid event index) or the effect of partial updates on unspecified values, leaving some 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.

  Conciseness4/5

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

  The description is organized and front-loaded with the core purpose, followed by per-parameter lines and a brief return statement. Every sentence adds useful information, though the format is slightly list-heavy. Still concise and 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?

  Given the tool mutates an automation event and has no annotations, the description covers essential context: identifying indices, update ranges, skip behavior, and return value. The reference to list_automation_events helps the agent obtain the correct event_index. It lacks error-case details but is sufficient for most update scenarios.

  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 provides detailed, meaningful semantics for all parameters: unit_index (AU index), track_index (value/automation track), event_index (from list_automation_events), value (normalized 0.0-1.0, skip if -1), interpolation (none/linear/curve, skip if empty), and curve_slope (0.0-1.0, skip if -1). This adds significant 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 clearly states 'Update an existing automation event's value and/or interpolation,' identifying the specific action (update) and resource (automation event). It distinguishes itself from sibling tools like create_automation_event, delete_automation_event, and move_automation_event by focusing on modifying an existing event.

  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 when to use the tool (when updating an existing automation event) and clarifies partial update semantics ('Only updates parameters that are provided'). It also references list_automation_events as a source for the event_index, providing useful context. There is no explicit exclusion of alternatives, 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.

• mcp_opendaw_add_automationA
  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 must carry the transparency burden. It does disclose that the tool creates an automation track, value clip, and value events, and states the prerequisite that the parameter must be automatable. However, it does not mention potential side effects such as overwriting existing automation, whether the operation is destructive, or error behavior if the parameter is not automatable.

  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. It leads with a one-sentence purpose, then a brief behavioral note, followed by a clear bulleted parameter list and a closing constraint. No redundant information; 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 tool with 4 params and no schema descriptions, the description is thorough: it covers all parameters, provides an example, states the automatable requirement, and mentions what it creates. It doesn't elaborate on return values, but an output schema exists, so that is acceptable. Minor gaps are not explaining how to discover valid effect_index/parameter_name values, but sibling tools cover 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%, so the description must fully compensate. It does so admirably: each parameter is individually explained (unit_index, effect_index, parameter_name, points), including the expected format for 'points' with an explicit JSON example. This adds meaning well 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 opens with a specific verb + resource: 'Add parameter automation to an effect on an audio unit.' It further clarifies by listing what is created (automation track + value clip + value events), distinguishing it from sibling tools like add_instrument_automation and create_automation_event by specifying the target is an effect on an audio unit.

  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 want to automate a parameter on an effect. It does not explicitly name alternatives or state when not to use it, but the context is strong and the 'to an effect' scoping implicitly separates it from instrument automation or individual event creation.

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

• mcp_opendaw_add_instrument_automationA
  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 fully disclose behavior. It adds valuable context about sample_level vs top-level parameters and the return value, but it does not mention potential side effects (e.g., whether existing automation is overwritten) or any required permissions, leaving meaningful 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 description is front-loaded with the purpose, then succinctly covers supported fields, parameter semantics, and return value. Every sentence provides useful information without unnecessary repetition or verbosity.

  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 moderate complexity (4 parameters, conditional behavior) and lack of annotations, the description covers the core workflow effectively and even notes the return info. It could optionally mention prerequisites like instrument existence, but the presence of an output schema fills some 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 has no per-property descriptions (0% coverage), so the description's explanations of unit_index, parameter_name, points (including a JSON example), and sample_index (with default value -1) add essential meaning beyond the schema's raw types and names.

  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 ('Automate a parameter on the instrument connected to an audio unit') and provides concrete examples of target instruments and fields (Vaporisateur cutoff, Playfield mute, etc.), clearly distinguishing it from sibling automation tools like add_automation or create_automation_event.

  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 the context (automating instrument parameters on an audio unit) and explains the conditional usage of sample_index, but it does not explicitly name alternative tools or state when not to use this tool, stopping 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.

• mcp_opendaw_add_markerA
  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 clearly states the mutation (adds a marker) and notes that markers are visible on the ruler. However, it does not disclose behavior around duplicate positions, validation, or success/error return, which would be valuable but is not critical for this simple 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 compact and well-structured: a one-sentence action summary, a brief explanatory note about markers, and parameter definitions. No filler or redundant content; every line serves a purpose.

  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 add tool, the description covers purpose, parameter semantics, and basic visibility behavior. An output schema exists, so the omission of return details is acceptable. It could mention duplicate handling or prerequisites, but overall it's complete for the tool's complexity.

  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, but the description compensates fully by documenting both parameters: position_beats (Position in beats) and label (Marker text with examples). This is exactly the compensation needed when schema descriptions are absent.

  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 timeline marker at a position', a specific verb + resource + location. It clearly distinguishes this from sibling tools like list_markers, delete_marker, and set_marker_label by stating it performs an add 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 explains that markers label song structure points and are visible on the timeline ruler, giving clear context for when to use this tool. It doesn't explicitly mention alternatives or exclusions, but the intended use case is well implied.

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

• mcp_opendaw_add_mastering_chainA
  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 disclosure burden. It does clearly state that the tool creates a chain (Revamp EQ → Compressor → Maximizer) on the output/master AU and returns effect indices and parameter values. However, it does not disclose whether this addition replaces or coexists with existing effects on the master bus, nor does it mention any destructive side effects or undo behavior—important 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 front-loads the core purpose in the first sentence, then uses bulleted lists efficiently for parameter details. The final 'Creates' and 'Returns' lines summarize the behavior without redundancy. Every sentence adds value, and the structure is easy to scan.

  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 output schema exists and the description states what is returned, so that area is covered. It clearly defines the target (output bus), the exact effect chain, and the meaning of both parameters. The missing piece is side-effect transparency (whether existing master effects are overwritten), which is not specified but might be inferred from 'add.' Given the tool's moderate complexity, the description is largely complete but leaves this one behavioral 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 schema descriptions are empty (0% coverage), but the description fully compensates by explaining both parameters. target_lufs is given concrete examples (-14 = Spotify, -16 = Apple, -10 = loud), and style is documented with four distinct preset names and their sonic characteristics. This provides far more semantic meaning than 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 opens with a precise action: 'Add a ready-made mastering chain to the output bus — EQ + compressor + maximizer in one call.' It specifies the resource (mastering chain), the target (output bus), and the composition (EQ + compressor + maximizer), clearly distinguishing it from sibling tools like add_effect or add_vocal_chain.

  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 the user wants a ready-made mastering chain on the output bus, saving the need for multiple effect-adding steps. It does not explicitly compare with alternatives like manually adding effects or using apply_full_mix, but the 'in one call' phrasing implies a preferred workflow. No exclusions are stated, which prevents the score from reaching 5.

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

• mcp_opendaw_apply_sidechainA
  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 clearly states that it creates automation events on the volume parameter and returns the event count and pattern info. However, it does not disclose potential side effects such as whether existing automation is overwritten or appended, whether the operation is reversible, or any preconditions like unit/track existence.

  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?

  Well-structured and front-loaded with a one-line summary. The mechanism, parameter list, return info, and an example are all included, and each sentence serves a purpose. The parameter explanations double as usage guidance, keeping the description 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?

  Covers purpose, mechanism, parameters, return value, and an example. With the output schema present, describing return details in more depth is unnecessary. Missing only brief preconditions (e.g., valid unit_index/track_index, potential need for existing AU), but overall complete for an 8-parameter 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 coverage is 0%, and the description fully compensates. Every parameter (unit_index, track_index, bars, start_beat, depth, attack, release, kick_interval) is explained with meaning, ranges, and practical examples—e.g., depth: '0.6 = volume drops to 40% on each kick'—adding far more value than 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?

  Uses a specific verb+resource: 'Apply sidechain ducking via volume automation'. Clearly distinguishes from the sibling connect_sidechain tool by stating it 'Simulates sidechain compression' rather than performing actual routing, and from set_track_volume by describing automation creation.

  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 by describing the effect as 'the signature sound of house, techno, EDM, and modern pop', implying when this tool is appropriate. The description of how it works ('by creating volume automation') implicitly differentiates it from real sidechain tools, but it does not explicitly state 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.

• mcp_opendaw_batch_diagnosticA
  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 transparency burden and does so well: it enumerates the checks, the triage severity categories, the return structure, and the input format. It does not explicitly state that the operation is read-only, but 'diagnostic' strongly implies a non-mutating analysis.

  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 longer than average but well-structured with numbered sub-checks, bullet points, and a short example. The first sentence front-loads the core purpose. Some redundancy exists between 'Produces a prioritized triage report' and the later return summary, but the structure keeps it 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 complex batch tool with an output schema, the description covers the input parameters, the per-stem analysis pipeline, the severity classification, and the result shape. It does not need to detail every return field because an output schema exists, and the provided example gives a concrete preview.

  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 explains filenames as either a JSON array or comma-separated list of WAV filenames, and genre as an optional profile. This adds meaningful type and usage 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 starts with a specific verb and resource: 'Run full diagnostic on multiple stems in one call', listing the three sub-analyses performed. It clearly distinguishes itself from siblings like detect_problems, analyze_phase, and compare_to_profile by framing it as their batch combination.

  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 for multi-stem diagnostics, mentions that phase analysis applies only to stereo files, and notes genre comparison is optional. It does not explicitly state 'use this instead of calling individual analysis tools', but the context is adequately conveyed.

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

• mcp_opendaw_compact_tracksA
  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 must convey behavioral traits. It does disclose the destructive action ('Removes tracks with no regions') and the parameter scope (unit_index, -1 for all AUs). However, it does not mention whether the action is reversible/undoable, what happens to related automation/sends, or any side effects beyond track removal. The core behavior is transparent enough for a simple cleanup tool, but lacks deeper 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 brief and well-structured: an opening statement of purpose, a reference to the underlying API method with a definition, a usage tip, and a parameter explanation. Every sentence adds value, with no redundant or unnecessary 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 tool with one parameter and a clear destructive action, the description covers the essential aspects: what it does, when to use it, and what the parameter means. It does not detail the return value, but an output schema is provided, which likely covers that. Minor ambiguities like 'empty tracks' vs 'tracks with no regions' are immediately clarified, so the description is largely 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 description must explain parameters. It does so fully: 'unit_index: Audio unit index (-1 = all AUs).' This clarifies the parameter's meaning and the special sentinel value, which is critical for correct invocation. No additional detail is needed for this single-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 the tool's purpose: 'Remove empty tracks from an audio unit (or all AUs).' It gives a specific verb+resource and clarifies that it 'removes tracks with no regions,' distinguishing it from sibling tools like delete_track or delete_region. The scope (specific AU or all AUs) is also 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?

  The description provides a clear usage context: 'Useful cleanup after deleting regions or editing.' This tells the agent when to invoke the tool, though it does not explicitly mention alternatives or when not to use it. Still, the guidance is actionable and relevant.

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

• mcp_opendaw_copy_notes_to_trackA
  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 discloses that copies go to the destination track's first region, explains optional transforms, and states the return value. However, it doesn't clarify whether copying adds to or replaces existing notes in the destination region, which is a significant behavioral trait for a music 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 well-structured and front-loaded with the core purpose. It includes a brief summary, use cases, parameter explanations, return value, and examples—all without fluff. Every section earns its place, making it easy to scan.

  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 operation purpose, all 8 parameters, return value, and provides examples. It is complete enough for a copy tool with this complexity, though it could mention edge cases like missing regions or whether destination notes are cleared. The presence of an output schema reduces the need to explain return details further.

  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, so the description must compensate. It describes every parameter with meaningful detail, including defaults, ranges, and examples (e.g., 'transpose: Semitone offset (-127 to 127, 0 = same pitch)'). The examples further clarify parameter usage.

  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 verb and resource: 'Copy notes from one track/region to another track — MIDI layering and doubling.' It distinguishes from siblings like copy_region_to_track by specifying notes, not regions, and by highlighting MIDI layering and doubling use cases.

  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 concrete use cases (layer drums, harmony, echo, doubles) that tell when to use this tool. It doesn't explicitly mention alternatives or when not to use, but the use cases offer clear context for choosing this tool over similar operations.

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

• mcp_opendaw_create_arpeggiated_progressionA
  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 explains the internal arpeggiation behavior (cycling through chord tones, pattern types, bars_per_chord switching) and what is returned, but it does not mention side effects like whether existing notes on the target track are overwritten, added to, or whether a track/region must pre-exist. It also does not explain the meaning of start_beat or unit_index, leaving some behavioral ambiguity for a creation tool with no safety annotations.

  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 longer than two sentences, but it is well-structured with clear sections for introduction, parameter meanings, returns, and examples. Each parameter gets its own line, and the examples are concrete and relevant. There is minor redundancy (e.g., 'synthwave/trance arp engine' followed by listing the same genres elsewhere), but overall it is efficient and front-loaded with the core purpose.

  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 tool with no annotations but an output schema, the description is quite thorough: it explains the core parameters, provides return value hints, and gives three usage examples. Gaps include no mention of start_beat and unit_index, no explicit side-effect/prerequisite discussion, and no detailed output-schema match. These are minor compared to the richness already provided, so it earns a solid 4.

  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?

  Despite 0% schema description coverage, the description compensates well for most of the 9 parameters. It details all five pattern values with note sequences and musical context, explains bars_per_chord, octave ranges, velocity range, step_duration durations, and typical track_index. However, it omits any explanation of start_beat and unit_index, which are less self-explanatory and appear in the schema without 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 opens with a specific verb-resource pair: 'Create an arpeggiated chord progression' and repeatedly calls it an arpeggio engine. It explicitly distinguishes itself from the sibling create_arpeggio by stating 'Unlike create_arpeggio (which takes a single chord), this cycles through a full progression.' This clearly communicates the tool's scope and unique value.

  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 tells when to use this tool versus create_arpeggio: 'Unlike create_arpeggio (which takes a single chord), this cycles through a full progression.' It also references the same progression format as create_chord_pads and gives genre-specific examples (synthwave, trance, house) with concrete parameter choices, which serve as usage patterns. This is explicit alternative and when-not guidance.

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

• mcp_opendaw_create_arpeggioA
  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 transparency burden. It discloses the return value, default velocity, and pattern edge cases (e.g., updown includes top and bottom twice), but it does not state whether notes are appended to or replace existing notes, whether a valid note track must already exist, or how note durations are derived from rate.

  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 opens with a one-line purpose and then uses a clean parameter-by-parameter format that makes the 9 parameters easy to scan. Every sentence provides concrete value (values, defaults, or examples) and no content is wasted.

  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 complexity, the description is largely complete: it covers all parameters, defaults, patterns, and return value. It lacks only a few contextual details such as whether the arpeggio is additive to existing notes and whether the target track must be pre-created, which would make it 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?

  Schema description coverage is 0%, but the description documents all 9 parameters in plain language, including explicit chord root/type lists, pattern options, rate values, defaults, and units. This fully compensates for the bare schema and adds meaning well beyond the property titles.

  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 opening sentence states a specific action ('Create an arpeggio from a chord name') and distinguishes it from the primary alternative by noting it replaces 8-32 create_note calls. This makes the tool's purpose immediately clear and differentiates it from sibling note-creation 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 clearly tells the agent to use this instead of multiple create_note calls, which is an explicit usage context. It does not, however, discuss when to prefer related siblings like create_arpeggiated_progression or create_ostinato, so it falls slightly short of full exclusion guidance.

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

• mcp_opendaw_create_audio_clipA
  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 full transparency burden. It reveals that clips appear in the clip launcher, are independently triggerable, take sample_id from load_audio, and return a UUID and index. It does not address overwriting behavior or permissions, but provides some useful 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 well-structured with an intro, parameter list, and return note. Each sentence contributes either conceptual context or parameter clarification, 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?

  The tool has 5 required params, no annotations, and the description covers purpose, all parameters, and return value. It omits edge behaviors like slot overwriting or prerequisites beyond sample_id, but is largely complete for a creation 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%, and the description compensates fully by explaining every parameter: sample_id's source, unit_index default, clip_index slot semantics, track_index default, and bpm's purpose for warp markers. This is strong added value 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 uses a specific verb ('Create'), names the resource ('audio clip'), and locates it in the session view / clip launcher. It further contrasts with audio regions, distinguishing it from related tools like place_audio_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?

  It explains that clips are session-view counterparts to audio regions, implying when to use this over arrangement-view region tools. However, it does not explicitly name alternative tools or exclusion conditions, so it stops at clear context.

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

• mcp_opendaw_create_bass_from_progressionA
  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 richly describes pattern behaviors (root, walking, pedal, etc.), default values, velocity range, octave mapping, and track index. However, it does not explicitly state side effects like whether it overwrites existing notes on the target track or if it appends to a region. Minor gap, but the level of detail is strong.

  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 well-structured with a clear intro, a pattern list, parameter notes, and multiple examples. It is long but each element adds value. The examples are slightly redundant but effectively demonstrate pattern usage. Front-loaded with the core purpose.

  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 complexity (8 params, no annotations), the description covers the main purpose, pattern options, parameter semantics, and integration with two sibling tools. It omits start_beat and unit_index, and doesn't state side effects, but output schema exists so return values need not be explained. The examples further round out the picture.

  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 thoroughly explains pattern (with enum-like descriptions), bars_per_chord, octave, velocity, and track_index, and examples clarify the progression parameter. However, start_beat and unit_index are completely undocumented, leaving two of eight parameters unexplained.

  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 clear verb+resource: 'Create a bass line from a chord progression string.' It also names its role within the harmonic trio (chord pads, arpeggiated progression, bass foundation), which distinguishes it from sibling tools. This is specific 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 Guidelines4/5

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

  It provides context that this tool is the bass foundation alongside create_chord_pads and create_arpeggiated_progression, and that all three take the same chord string. Genre examples for each pattern give implicit guidance. However, it does not explicitly exclude or compare against other bass-related tools like create_bassline or create_walking_bass, so it stops short of full when/when-not guidance.

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

• mcp_opendaw_create_boom_bapA
  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 burden. It discloses the internal pattern logic (kick on 1 & 3, snare on 2 & 4), velocity offsets for ghost hats and snares, and the return value ('notes created, boom-bap type, stroke breakdown'). It does not mention whether the tool overwrites existing notes on the target track, but overall it provides substantial 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.

  Conciseness4/5

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

  The description is long but well-structured, with clear sections for boom-bap explanation, type definitions, parameter details, returns, and examples. The historical references add flavor but are not strictly necessary. It is front-loaded with the core purpose and remains readable despite the length.

  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 complex 9-parameter tool with no schema descriptions, this description is remarkably thorough. It covers the musical styles, primary parameter semantics, output details, and usage examples. The only gaps are the three unmentioned positional parameters and the lack of clarity on interaction with existing notes, but the output schema helps fill in return structure.

  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 for most parameters: boom_bap_type is thoroughly explained with five style variants, bars has a range, pitches include MIDI note examples, and velocity includes base and offset behavior. However, start_beat, unit_index, and track_index are not described at all, leaving a meaningful gap for those 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 states a specific action: 'Create a boom-bap hip-hop drum pattern.' It defines boom-bap and describes multiple subtypes, distinguishing it from generic drum-pattern tools among siblings. This gives a precise verb+resource+scope that leaves no 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?

  The description makes it clear when to use this tool: when a boom-bap hip-hop drum pattern is needed. It provides detailed guidance for choosing among boom_bap_type styles, but it does not explicitly mention alternatives or when-not-to-use cases relative to sibling tools. This is clear context without exclusions.

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

• mcp_opendaw_create_chopA
  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 describes the operation, parameter effects, and return values ('Returns notes created, segment count, mode used'), but does not disclose potential side effects like overwriting existing notes or prerequisites beyond implied track/unit indices.

  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 long but every sentence earns its place: a crisp purpose statement, musical context, per-parameter explanations, and return summary. The use of line breaks per parameter improves scannability 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?

  Given 12 parameters, no annotations, and an output schema (existence noted), the description covers all parameter semantics, usage context, and return information. Missing only explicit side-effect warnings, but for a 'create' operation this is a minor gap, not a critical deficiency.

  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 compensates fully by explaining every parameter with defaults, ranges, and examples (e.g., stutter_count 2-8, octave_shift -1 for bass chops, velocity_variation 0-0.5). This is far beyond what the 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: 'Create a chop — slice source pitches into segments and rearrange them.' It clearly differentiates from sibling tools like create_stutter by presenting chop as the umbrella technique with multiple rearrangement modes, including stutter as one of 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?

  Provides strong musical context ('quintessential hip-hop/EDM sampling technique', Dilla chops, glitch-hop) that implies when to use this tool. However, it does not explicitly name alternative tools (e.g., create_stutter) or specify when not to use it, leaving some room for interpretation.

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

• mcp_opendaw_create_djembe_ensembleA
  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 thoroughly explains the musical behavior (layering, instruments, pattern structures, returns notes/breakdown/rhythm info), which is valuable. However, it does not disclose important operational effects such as whether existing notes on the target track are cleared, whether it appends to or replaces content, or what unit_index/track_index concretely control beyond 'AU index' and 'Note track index'.

  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 well-structured: purpose, genre context, style details, then explicit Args list. It is front-loaded with the core purpose. Some repetition exists (e.g., kenkeni is described twice), and the cultural context, while useful, could be trimmed. Overall it is dense and organized, though not maximally concise.

  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?

  This is a complex tool with 12 parameters, no annotations, and a declared output schema that isn't shown. The description covers the musical domain richly and explains the return value generally. However, it leaves out crucial operational context: does it create a new track or use the supplied track_index? Does it replace existing notes? How does start_beat interact with the cyclical patterns? Without this, the agent cannot predict the full result of invoking the 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 description must fully compensate for 12 parameters. It does: each parameter is described in the Args section, pitch parameters include MIDI note numbers and note names, style parameters are explained in detail with rhythmic descriptions, and even unit_index/track_index receive minimal but functional definitions. This is strong compensation for a schema void.

  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 begins with a clear, specific verb phrase: 'Create a West African djembe/dunun ensemble — cyclical ostinato with call-and-response.' It immediately identifies the resource (djembe/dunun ensemble) and the musical style, and it distinguishes this tool from related siblings like samba or songo by explicitly contrasting the cyclical, call-and-response structure.

  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 tells when to use this tool by contrasting it with samba and songo ('Unlike samba (parade ensemble) or songo (drum kit), West African drumming is cyclical...'). It also enumerates four traditional styles with their musical characteristics, giving the agent clear criteria for choosing style values. This is explicit 'when to use vs alternatives' guidance.

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

• mcp_opendaw_create_harmonyA
  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 mentions reading source notes and creating copies, implying non-destructive source behavior, but it does not explicitly state whether original notes remain untouched. It also does not clarify whether output to an existing track merges notes or replaces them. The return value is mentioned, but these behavioral ambiguities prevent a higher score.

  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 appropriately sized. It opens with a concise purpose statement, then lists parameters in a scannable format with clear explanations. Every sentence adds value, and the list is not bloated despite covering 8 parameters.

  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 tool has 8 parameters and no annotations, yet the description covers all parameters, source/destination track behavior, and the return value. The output schema exists, so return value details need not be repeated. However, it lacks explicit notes on edge cases such as empty regions or overwrite behavior on existing tracks, so it is complete but not exhaustive.

  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 zero descriptions for its 8 parameters, but the description fully compensates by explaining each parameter's purpose. It details the interval enum values, direction semantics, the -1 sentinel for new_unit_index, and velocity defaults. This is exactly the meaning the schema lacks, making parameter semantics excellent.

  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 it generates harmony parts from existing notes, enumerating specific intervals (thirds, fifths, sixths, octaves). It explicitly says it reads notes from an existing region and creates harmonized copies, distinguishing it from generation tools that create notes from scratch. The verb+resource is specific and 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 provides clear context regarding when to use this tool: it operates on an existing region, supports diatonic and chromatic intervals, and outputs to a new or existing track. However, it does not explicitly name alternative tools (e.g., create_harmony_line) or specify 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.

• mcp_opendaw_create_irish_tradA
  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 behavioral burden, and it does describe the musical behavior (downbeat/offbeat patterns per tune type) and return value ('Returns notes created, tune type info, meter, and pattern breakdown'). However, it does not state operational side effects such as whether the tool appends to or replaces existing notes on the specified track, or what happens with invalid inputs.

  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 the length is largely devoted to necessary tune-type distinctions and parameter semantics, structured under clear headings. The opening sentence immediately states purpose, and each bullet for tune types adds selection-relevant information rather than 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?

  Given 9 parameters, no annotations, and an output schema present, this description is unusually complete: it covers all parameters, explains the style and all tune-type variants, and states the return payload. It could mention prerequisites about the target track, but overall it gives an agent enough to invoke 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 'Args' block provides a semantic description for every parameter, including ranges ('bars: Number of bars (4-32, even)'), value ranges ('velocity: Base velocity 0-1'), and default MIDI pitches. The schema itself has zero descriptions, so this completely compensates for the 0% schema coverage, especially the detailed tune_type guidance.

  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 'Create an Irish traditional music accompaniment — bodhrán + feet for session tunes,' which is a specific verb+resource that clearly distinguishes this from sibling creation tools like create_reggae_percussion or create_tala. It further enumerates six tune types, reinforcing the focused 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 explains that Irish trad is defined by tune types and that the accompaniment is minimal and supportive, providing clear contextual when-to-use guidance. However, it does not explicitly name alternative tools or state when not to use this tool, though the context is sufficient for selection.

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

• mcp_opendaw_create_lofi_arrangementA
  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 full burden of behavioral disclosure. It states the return value ('Returns notes created per track and total'), describes humanization and swing characteristics ('laid-back 16th hi-hat with swing', 'lower velocity, humanized'), and explains how parameters like BPM and root affect the output. However, it does not mention potential side effects like whether existing notes on the target tracks are overwritten, which would be useful.

  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 structured logically: purpose first, then stylistic details, parameter explanations, return info, and examples. It is longer than strictly necessary but the musical detail is arguably essential for achieving the intended genre. The front-loaded first line ensures immediate clarity.

  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 complexity (11 parameters, no annotations, no schema descriptions), the description is impressively complete. It covers the musical genre, per-track behavior, parameter ranges, and return values, and includes examples. It lacks explicit notes on velocity and start_beat behavior and does not detail the output schema content, but overall it equips an agent to invoke the tool correctly for typical lofi generation requests.

  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%, but the description compensates with prose explanations for most parameters: bpm, bars, root, octave, unit_index, and the track index parameters. It provides meaningful defaults and rationale (e.g., '78 = chillhop sweet spot'). However, velocity and start_beat are not described, leaving a gap for those two 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 opens with a specific verb and resource: 'Create a full lofi hip-hop arrangement' and enumerates the components (boom-bap drums, jazzy chords, mellow bass, sleepy melody). This clearly distinguishes the tool from siblings like create_boom_bap or create_jazz_arrangement, which target narrower or different outputs.

  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 context for when to use the tool: it is for generating a complete lofi hip-hop arrangement with specific stylistic characteristics and parameter defaults (e.g., 78 BPM, root F). It does not explicitly mention when not to use it or name alternatives, but the genre-specific details and examples make the intended use case obvious.

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

• mcp_opendaw_create_melodyA
  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 does disclose that it creates melody notes in a specified track and returns a summary, and it explains the pattern syntax. However, it does not state whether notes are appended or replace existing notes, nor does it mention any prerequisites beyond having a note track. This is moderate 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 long but every sentence adds value. It front-loads the purpose, then uses a structured, scannable format for parameters and returns. No redundancy 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 an 8-parameter tool with no schema descriptions and no annotations, the description covers all inputs, gives examples, and states return values. It could be more explicit about side effects (e.g., whether it overwrites existing notes) but is otherwise quite 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 description must and does fully compensate. It documents all 8 parameters, enumerates valid scales and roots, and provides a detailed pattern syntax with examples. This is essential 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 clearly states the tool's function: 'Create a melody from a scale and rhythmic pattern'. It also differentiates from the sibling tool create_note by noting it can replace 10-30 create_note calls, making the purpose and value immediate.

  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 names an alternative ('instead of 10-30 create_note calls'), providing a concrete when-to-use. However, it does not discuss other melody generation siblings like generate_melody, so the exclusion guidance is incomplete.

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

• mcp_opendaw_create_metal_arrangementA
  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 full behavioral disclosure. It details per-track behavior, scale choices, and explicitly states the return value ('Returns notes created per track and total'). However, it does not disclose whether the tool appends to existing notes or overwrites tracks, nor does it fully clarify prerequisites beyond 'unit_index: AU index with note tracks.'

  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 organized clearly: purpose, track breakdown, BPM context, riff theory, parameter list. It front-loads the main point and uses bullet points for readability. Some stylistic flourishes (e.g., 'relentless heartbeat of metal') add flavor but not operational value, making it slightly less concise than ideal.

  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 complex tool that creates four tracks of arrangement, the description covers the compositional approach, musical style, key parameters, and expected return. Given that an output schema exists, it does not need to document return syntax in detail. Gaps include velocity, start_beat, and interaction with existing notes, but overall the description provides sufficient context for an AI 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?

  Schema description coverage is 0%, so the description is the only source of parameter meaning. It explains bpm, bars, root, octave, unit_index, and all four track indices with ranges and defaults, which is substantial. However, it omits velocity and start_beat entirely, leaving those 2 of 11 parameters unexplained.

  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: 'Create a full metal arrangement — double kick drums + palm-muted riffs + power chords + shred lead.' It clearly enumerates the four tracks, making the tool's function unmistakable and distinguishing it from the many other genre arrangement tools 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 strong usage context: BPM ranges map to subgenres (120=traditional metal, 160=thrash, 200+=extreme), and it emphasizes riff-based rather than chord-progression-based composition. It does not explicitly mention alternatives, but the tool's purpose is so clearly scoped that 'use for metal arrangements' is unambiguous.

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

• mcp_opendaw_create_noteA
  4.3/5.0
  Behavior4/5

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

  Given there are no annotations, the description carries the transparency burden. It discloses key behaviors: 'If no clip exists on the track yet, one is auto-created' and 'Notes are added to the first clip on the track.' It also explains unit_index=-1 search behavior and velocity range, providing valuable context beyond what the schema shows.

  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 compact bullet-style list of parameter explanations followed by two behavioral notes. Every line is necessary and adds value; there is no fluff or repetition. It is front-loaded with the primary action and well organized.

  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?

  With an output schema present, return value explanation is not required. The description covers all parameters and key behavioral traits (auto-creation, first-clip placement). Minor gaps include lack of error-handling info and bounds for pitch/start_beat, but for a single-note creation tool this 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%, so the description must fully compensate. It does: each of the six parameters is explained, including pitch reference (60=C4, 69=A4), beat position, duration in beats, velocity range, and unit_index semantics. This entirely fills the gap left by 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 opens with 'Create a MIDI note on a note track,' clearly stating the verb (create), resource (MIDI note), and destination (note track). This distinguishes it from sibling tools like create_notes_batch (batch creation) and create_drum_pattern (pattern generation).

  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 defining the operation and providing context about auto-creating clips and adding to the first clip, but it does not explicitly state when to use this tool over alternatives such as create_notes_batch or list_notes. No exclusions or alternative recommendations are given.

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

• mcp_opendaw_create_note_clipA
  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. It discloses useful behaviors such as unit_index=-1 searching all audio units, hue=-1 auto color, and the return of clip UUID and index. However, it does not mention potential side effects like overwriting an existing clip at the same slot, or error conditions if the track index is invalid. This is a moderate gap 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 well-structured: a leading one-line summary, a brief conceptual context paragraph, a clear parameter list, and a return statement. Every sentence serves a purpose and there is no redundant wording 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?

  The description explains the purpose, parameters, and return value, and places the tool in the session-view context. It is missing details about behavior when a clip already exists at clip_index or validation of track_index, but given the output schema is available and the critical parameter semantics are covered, it is reasonably 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 input schema has 0% description coverage, and the description fully compensates by explaining every parameter with domain-specific meaning: unit_index, track_index, clip_index, name, hue. It adds special value semantics (-1 defaults) that are not present in the schema at all.

  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 a clear, specific verb and resource: 'Create a note clip in the session view (clip launcher).' It distinguishes this from note regions by explaining that note clips are the session-view counterpart, which differentiates it from similar tools like create_note_region or create_audio_clip.

  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 context that this tool is for the session view/clip launcher, contrasting it with note regions in the timeline. While it does not explicitly name alternative tools or state 'use this when...', the contextual framing is strong enough to guide the agent away from region-based tools.

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

• mcp_opendaw_create_pan_sweepA
  4.3/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 the core behavior (creates automation events on the AU's panning parameter) and explains default curve choice, plus it states the return value. However, it does not mention whether existing automation is overwritten, if the operation is undoable, or any required permissions, leaving some important side effects undocumented.

  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: a one-sentence summary, a use-case paragraph, a clear parameter list, return type mention, and two concrete examples. Every sentence adds valuable information, and the front-loaded summary ensures the agent quickly understands the tool's purpose.

  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 the essential details needed to invoke the tool correctly: parameters, defaults, return value, and examples. It does not address edge cases like invalid unit_index or behavior when existing automation overlaps, but these are minor for a focused pan-sweep tool. The presence of an output schema also reduces the need to explain return details.

  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 fully compensates by defining every parameter: unit_index, start_beat, duration_beats, start_pan/end_pan ranges (-1.0 to 1.0), curve options, and steps. It also provides practical examples that demonstrate how to call the function, exceeding what the schema titles alone offer.

  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 begins with a clear, specific verb ('Create a panning automation sweep') and resource ('panning parameter'), explicitly stating the action's scope. It distinguishes itself from sibling tools like create_filter_sweep and create_volume_fade by focusing on panning movement, 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 Guidelines4/5

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

  The description provides clear context on when to use the tool, citing it as a classic technique for intros, guitar solos, EDM builds, and section transitions. It does not explicitly state exclusions or alternatives (e.g., when to use set_track_panning instead), but the context is strong enough to guide an agent toward appropriate usage.

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

• mcp_opendaw_create_pitch_stretched_regionA
  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 explains the core behavior (pitch stretch preserving timing via warp markers) and states the return value (position and duration in PPQN). However, it does not mention prerequisites beyond sample_id, potential side effects, or failure modes, leaving some ambiguity 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 well-structured and concise: a one-line purpose, a single use-case sentence, a parameter list with one-line definitions, and a return statement. No filler words, and all information is relevant 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?

  The description covers the essential information: what the tool does, when to use it, parameter semantics, and return format. The output schema exists, so return values are formally documented. Minor gaps include lack of error conditions and more explicit prerequisites (e.g., whether the track must exist), but overall it is sufficiently complete for effective tool 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 description provides a concise explanation for every parameter, including defaults for unit_index and track_index, and the purpose of bpm. Since the schema has 0% coverage, the description fully compensates by adding semantic meaning for all five parameters, making it easy for an agent to construct valid arguments.

  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 begins with a clear, specific statement: 'Place a pitch-stretched audio region on a track.' It then clarifies the key distinction from time-stretching by explaining that pitch-stretch preserves timing while allowing pitch manipulation. This differentiates it from sibling tools like create_time_stretched_region and place_audio_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 explicitly states when to use the tool: 'Use this when you want to tune audio to project key without changing its duration.' This provides clear usage context. It does not explicitly name alternatives, but the contrast with time-stretch is implied, which is sufficient for differentiation.

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

• mcp_opendaw_create_taiko_ensembleA
  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 full burden. It discloses that notes will be created and returns an instrument breakdown, but it does not state whether existing notes are preserved or overwritten, or whether it requires an existing track/unit. The description focuses on musical behavior rather than concrete side effects, leaving some operational ambiguity.

  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 well-organized into clear sections (instruments, strokes, styles, args). Each section adds necessary value for a complex genre-generation tool. Some historical background could be trimmed, but the overall structure front-loads the purpose and remains focused.

  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 10 parameters and zero annotations, the description provides comprehensive guidance: instrument roles, stroke vocabulary, style-specific rhythmic patterns, all parameter explanations with defaults, and the return value. An agent can confidently select styles and set parameters without needing additional external knowledge.

  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 provides zero parameter descriptions, but the 'Args' section compensates fully by explaining every parameter with musical context and defaults. Style parameter is exceptionally well-defined with detailed descriptions of each style's rhythmic patterns, and pitch parameters are given default MIDI 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 opening sentence clearly states 'Create a Japanese taiko ensemble' with further elaboration on kumi-daiko group drumming. It thoroughly distinguishes this tool from sibling percussion tools by providing genre-specific instrument names (odaiko, chu-daiko, shime-daiko, atarigane) and style names.

  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 extensive style descriptions (miyake, yatai, edo, hachijo, omega) give an agent clear musical context for when to choose each style, effectively guiding usage. However, it does not explicitly mention when not to use this tool or compare it to alternative percussion ensemble tools like create_djembe_ensemble or create_korean_percussion.

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

• mcp_opendaw_create_turnA
  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 full behavioral disclosure responsibility. It does describe the note sequence, parameter effects, and return values, but it omits important side-effect traits such as whether existing notes at the target beat are overwritten, whether a new region is created, or what happens if the specified unit/track index is invalid.

  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: a concise opening definition, a brief explanatory paragraph about the ornament's musical role, and a compact parameter list. Every sentence earns its place, with 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?

  Given the tool's 8 parameters and lack of annotations, the description is largely complete: it covers the ornament pattern, all parameter semantics, and return values ('Returns notes created, pitches used'). The presence of an output schema reduces the need for detailed return documentation. It lacks some environmental side-effect details, but overall it is sufficient for selecting and invoking the 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 coverage is 0%, but the description provides clear, human-readable definitions for all 8 parameters with defaults and ranges (e.g., interval: 'Semitones to neighbors (default 2 = whole step). 1 = half step (diatonic)' and duration_beats: '0.5-4, default 1.0"). 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.

  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: 'Create a turn — circular ornament: main → neighbor → main → other neighbor → main.' It immediately distinguishes the turn from sibling tools like create_trill and create_mordent by explaining the unique note sequence and character of the ornament.

  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 a turn is one of the four essential baroque ornaments and provides musical context ('Think Mozart piano concertos, Beethoven sonatas, Bach partitas'), which subtly indicates when to use it. It also clarifies upper vs. lower turn variants but does not explicitly state when not to use it compared to a trill or mordent, so it lacks explicit exclusions.

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

• mcp_opendaw_delete_regionA
  4.3/5.0
  Behavior4/5

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

  The destructiveHint annotation already flags this as destructive. The description adds valuable context by specifying exactly what is removed (notes, audio references, automation events) and by stating the return value. This goes beyond the binary annotation, though it does not discuss undo behavior or irreversibility.

  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 clear action sentence, a bullet-like explanation of the destructive effect, a parameter list, and a return value note. Every sentence provides useful information with no 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?

  The description covers the operation, destructive effects, parameters, and return value—enough for a delete tool. It lacks explicit mention of undo/redo or typical use cases, but the destructiveHint annotation and clear parameter docs make it 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?

  Schema description coverage is 0%, so the description carries the full burden of explaining the parameters. It does so effectively: track_index (within AU), region_index (0-based), unit_index (-1 for all AUs), and region_type ('note', 'audio', 'value'). 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.

  Purpose5/5

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

  The description opens with 'Delete a region from a track', a specific verb+resource statement. It further clarifies the scope by listing what gets removed for each region type. Although it doesn't explicitly differentiate from siblings like delete_note_region or delete_audio_region, the region_type parameter makes the generic behavior 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 through parameter explanations (e.g., region_type filtering) but does not explicitly state when to choose it over alternatives or mention any exclusions. Sibling tools like delete_note_region and delete_audio_region exist, but no guidance is provided on selecting between them.

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

• mcp_opendaw_export_midiA
  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 usefully mentions the underlying encoder, time division, and that a file is saved. However, it does not disclose edge-case behaviors such as whether an existing file is overwritten, what happens if the region is not found, or any error behavior. This is a moderate 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?

  The description is front-loaded with the purpose, followed by a concise technical note, then a compact parameter list, and a one-line return-value note. Every sentence adds value and there is no padding, making it both informative and 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 tool with 4 required parameters, no annotations, and an output schema present, the description covers the essential operational context: what it exports, how parameters map to identifiers, and the return value. It does not discuss potential failure modes or file placement, but these are not critical for invoking the tool correctly. The description is complete enough for an agent to perform the task safely.

  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 provides zero descriptions for its 4 parameters, but the description fully explains each one: filename (without extension), unit_index (-1 means search all AUs), track_index, and region_index (0-based). This directly compensates for the low schema coverage, giving the agent everything needed to provide valid 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 statement: "Export a note region's notes as a standard MIDI file (.mid)." This clearly distinguishes the tool from siblings like import_midi (which imports instead) and export_mix (which exports audio formats). 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?

  The description provides clear context for when to use this tool: when exporting a note region to a MIDI file. It also gives details about how to identify the region (unit_index, track_index, region_index). However, it does not explicitly state when not to use it or mention alternatives like import_midi or export_mix, which prevents a 5.

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

• mcp_opendaw_export_presetA
  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. It discloses that serialization includes all dependencies and that the output is base64-encoded, and mentions potential error return. However, it does not explicitly state whether this operation is non-destructive or if any permissions are needed. The term 'export' implies read-only, but the description could be more explicit about not modifying the project 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?

  The description is efficiently structured: a one-sentence purpose, a brief implementation note, then parameter explanations and return info. Every sentence contributes value; no filler or repetition. The first line is front-loaded with the core function, making it easy for an agent to quickly identify the tool's purpose.

  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 that an output schema exists, the description appropriately summarizes the return value without going into detail. It covers the tool's scope, parameters, and constraints. The only gap is the lack of explicit differentiation from related tools like import_preset or export_effect_chain, but this is a minor omission given other strengths.

  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 compensates fully by explaining both parameters. It states that unit_index is the AU index to export and must be an instrument, not Output, and that include_timeline controls whether tracks/regions/notes are included. This adds meaningful constraints and semantics beyond the bare schema fields.

  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 clear verb+resource: 'Export an audio unit as a preset (base64-encoded binary).' It specifies the output format, the serialization approach with dependencies, and even clarifies that the unit must be an instrument. This clearly distinguishes it from sibling tools like export_midi or export_stems.

  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 context for when to use the tool: exporting an audio unit preset with optional timeline inclusion. It also gives a concrete constraint ('must be an instrument, not Output'), which helps the agent avoid invalid calls. However, it does not explicitly mention alternatives or when not to use it, so it lacks the full exclusions that would earn a 5.

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

• mcp_opendaw_find_overlapping_notesA
  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 discloses the return format (list of overlapping notes or error) and scopes the operation to a note region, but does not explicitly state that it is read-only or describe any side effects. This is adequate but not rich; a read-only hint would have been helpful.

  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 one-sentence purpose, a use-case note, then a flat parameter definition list, and a return statement. Every sentence adds value; 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?

  The description fully explains the tool's inputs, purpose, and output, and the presence of an output schema covers return structure. It lacks explicit edge-case handling (e.g., empty results, invalid beat ranges), but overall it is complete enough for the tool's complexity.

  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. It defines all six parameters thoroughly, including types (MIDI note, beats) and examples (60 = C4), giving the agent complete understanding beyond the bare schema. This is exemplary compensation.

  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 (Find) and clearly defines the resource: notes overlapping a pitch and time range within a note region. It distinguishes itself from sibling tools by focusing on collision detection and chord/harmony finding, which is unique among the many note 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 explicitly states two use cases: checking if a note can be placed without collision and finding chords/harmonies at a pitch range. It does not mention when not to use it or name alternatives, but the provided context is clear enough for an agent to decide when to invoke it.

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

• mcp_opendaw_get_region_infoA
  4.3/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, and the description aligns with this by stating it 'gets' information. It adds value beyond the annotation by disclosing what the response includes: position, duration, loop, mute, content, and type-specific metadata such as notes count, audio file, and automation events. No contradiction with 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?

  The description is compact and front-loaded: a clear one-line summary, three short parameter definitions, and a one-line description of return content. Every sentence serves a purpose, with no redundant or filler 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?

  The description covers the tool's purpose, all three parameters, and the general shape of the return value. Since an output schema exists, it does not need to enumerate every field. It is sufficient for an agent to select and invoke this tool correctly, though it could mention error/edge-case behavior for extra completeness.

  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 no descriptions (0% coverage), but the description fully compensates by defining each parameter: unit_index as AU index, track_index as track within the AU, and region_index as region index. This clarifies the hierarchical addressing scheme, which the bare schema names do not 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+resource: 'Get detailed info about a single region' and enumerates the exact fields returned (position, duration, loop, mute, content). This clearly distinguishes it from sibling list operations (e.g., list_note_regions) and mutation tools (e.g., set_region_duration).

  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 appropriate use case—when you need detailed information about one specific region—but does not explicitly state when not to use it or mention alternatives like list_note_regions or get_region_play_mode. It provides no exclusions or comparative guidance, so it meets only the 'implied usage' level.

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

• mcp_opendaw_get_tempo_atA
  4.3/5.0
  Behavior4/5

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

  The readOnlyHint annotation is consistent with the description's 'Get' and 'Returns BPM at that position, or error.' The description adds useful behavioral context about accounting for tempo automation and its error return, going beyond what annotations already provide.

  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, front-loaded with the purpose, and contains only essential information: the param definition and return behavior. Every sentence earns its place with 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 simple read-only getter with one parameter and an output schema, the description is complete. It states the input, the return (BPM or error), and the automation consideration. No other aspects (like pagination or side effects) are relevant.

  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 must compensate. It does define the parameter as 'Position in beats (float)', but this largely restates the schema's type and title. No additional constraints (e.g., valid range, reference point) are provided, so it barely rises above the baseline.

  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 verb ('Get'), the resource ('BPM at a specific position'), and a key differentiator ('accounting for tempo automation'). It can be distinguished from siblings like set_bpm, add_tempo_change, and list_tempo_changes.

  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 it clear when to use the tool: to obtain BPM at a specific position, especially accounting for automation. However, it does not explicitly mention why it should be preferred over alternatives like list_tempo_changes, though the automation mention strongly implies the use case.

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

• mcp_opendaw_import_midiA
  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 key behaviors: it parses .mid files, creates note regions, supports formats 0/1, and converts ticks to PPQN. Yet it does not explain whether existing notes are overwritten or merged, what happens on errors, or any permission requirements. This is adequate but leaves important 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 description is well-structured and appropriately sized. It starts with a one-line summary, then details parsing, formats, and tick conversion, followed by a clean parameter list, and ends with return value. Every sentence contributes useful information with no redundancy 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?

  Given that the schema has zero param descriptions and no annotations, the description provides a solid foundation: it covers formats, resolution, all four parameters, and the return value. It does not mention potential multi-track MIDI handling or whether tempo/time signature events are imported, but for an import tool this is fairly complete. The output schema exists, so return details need not be over-specified.

  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 provides only parameter names and types with no descriptions (coverage 0%). The description compensates fully by explaining each parameter: file_path (absolute/relative), unit_index (-1 searches all AUs), track_index (within AU), and offset_beats (with an example). This adds significant 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: 'Import a MIDI file and create note events on a note track.' This clearly distinguishes it from siblings like 'export_midi' or 'import_dawproject'. It also specifies parsing behavior, formats, and tick conversion, leaving no ambiguity about its function.

  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: importing standard MIDI files into note tracks. It explains supported formats (0 and 1) and the meaning of unit_index -1 for searching all AUs. However, it does not explicitly mention alternatives or situations where this tool should not be used, 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.

• mcp_opendaw_list_midi_effectsA
  4.3/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, so the read-only nature is known. The description adds meaningful domain context (MIDI effects process note data before reaching the instrument, and are inserted on au.midiEffects chain), which helps the agent understand the entity being listed. No contradiction with 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?

  The description is three short sentences: the first front-loads the purpose, and the next two give essential domain context. Every sentence earns its place; no redundant or excessive wording.

  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 list tool with output schema and read-only annotation, the description covers what the tool does, what MIDI effects are, and where they live. This is complete for the tool's complexity. The return format is covered by the output schema.

  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 contains nothing to explain. The description correctly focuses on the purpose rather than parameter semantics. Baseline for 0 params is 4, and no further parameter info 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 uses a specific verb 'List' with a clear resource 'MIDI effect types' and states its scope ('all available'). It distinguishes from sibling tools like mcp_opendaw_list_effects (which likely lists audio effects) and mcp_opendaw_add_midi_effect (which adds rather than lists).

  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 what MIDI effects are and where they are inserted (au.midiEffects), implying when this listing would be useful, but it does not explicitly state when to use this over alternatives or provide exclusions. No sibling tool is named as a comparison.

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

• mcp_opendaw_list_midi_output_devicesA
  4.3/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=true, so the read-only nature is known. The description adds the scope (project-registered hardware outputs) and return fields, but does not disclose any further behavioral traits such as ordering, performance, or side effects. This aligns with the calibration sample where a read-only tool with additional context scores 3.

  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 compact two sentences: the first sentence states the purpose and scope, the second lists the return fields. Every word contributes value; no redundancy or 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, zero-parameter listing tool with readOnlyHint=true and an output schema present, the description fully captures the essential information: what is listed, the scope, and what is returned. There is no significant missing 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?

  With zero parameters, the schema coverage is 100% and there is nothing to add about parameter semantics. The description focuses on return fields, which is beyond the schema's empty properties, so it earns the baseline 4 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 the action ('List'), the resource ('MIDI output devices'), and the scope ('registered in the project', 'hardware MIDI outputs'). It also enumerates the return fields, fully distinguishing it from any sibling listing 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?

  It provides clear context by specifying it lists hardware MIDI outputs registered in the project, which implies when this tool should be used. However, it does not explicitly name alternatives or state when not to use it, so it misses the highest tier of guidance.

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

• mcp_opendaw_list_modular_modulesA
  4.3/5.0
  Behavior4/5

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

  The readOnlyHint annotation already signals a safe read operation. The description adds useful behavioral context by specifying the return content (type, label, x/y position, inputs, outputs, parameter values) and enumerating module types (gain, delay, multiplier, audio-input, audio-output). This goes beyond the annotation and helps the agent understand what to expect from 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 compact and front-loaded, starting with the core purpose in the first sentence. It then provides parameter details and return information without any redundant fluff. Every sentence earns its place, making it an example of efficient writing.

  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?

  An output schema exists, so the description does not need to detail every return field. It already covers the input parameters and return content. A minor gap is that it does not mention how to obtain au_index/effect_index (e.g., via list_modular_devices), but for a straightforward read-only listing tool, the description is reasonably 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 input schema has zero descriptions for its two parameters, but the description compensates fully by defining au_index as 'Audio unit index' and effect_index as 'Effect index within the AU.' This provides essential semantic meaning that the schema lacks, making the parameters self-explanatory.

  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 'List all modules in a Modular device,' which clearly states the action (list), the resource (modules), and the scope (in a Modular device). It distinguishes itself from sibling tools like list_modular_devices (lists devices) and list_modular_connections (lists connections) by specifically targeting modules within a device.

  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 the two parameters (au_index, effect_index) which implies when to use the tool, but it does not explicitly state when to use this over alternatives like list_modular_connections or provide exclusion criteria. The usage context is implied rather than explicit, so a score of 3 is appropriate.

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

• mcp_opendaw_list_notesA
  4.3/5.0
  Behavior4/5

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

  The readOnlyHint annotation already marks this as safe, and the description does not contradict that. Beyond the annotation, it adds valuable behavioral context: unit_index -1 searches all audio units, and results are sorted by position. It also discloses the exact return fields, which helps set expectations. This adds genuine value beyond the annotation.

  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, a brief return format section, and a parameter list. Every sentence adds necessary information, with no fluff. The line breaks separate logical components, making it easy to scan. This is a model of concise technical writing.

  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 read-only list tool, the description fully covers the purpose, all parameters, return value semantics (position, duration, pitch, velocity, cent, chance), and sorting behavior. An output schema exists, so the return format is further specified, but the description already provides the key fields. No significant gaps remain 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.

  Parameters4/5

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

  The schema has 0% description coverage, so the description carries the burden. It explains all three parameters: unit_index (-1 = search all AUs), track_index (note track within the AU), and region_index (0-based region). However, track_index is slightly ambiguous regarding whether it is 0-based or scoped within the AU; the -1 wildcard behavior is only explained for unit_index, not track_index. Still, the description provides substantive meaning beyond the bare schema titles.

  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: 'List all note events within a region.' It specifies the resource (note events within a region) and distinguishes itself from siblings like list_note_regions and list_automation_events. The verb 'list' is specific and 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?

  Usage is implied: the description indicates this tool lists note events within a region, so an agent can infer when to use it. However, it does not explicitly name alternatives (e.g., list_note_regions for regions) or provide when-not-to-use guidance. The context clues from siblings help, but the description itself offers no exclusions or alternative recommendations.

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

• mcp_opendaw_list_split_modesA
  4.3/5.0
  Behavior3/5

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

  The readOnlyHint annotation already indicates a safe read operation, so the description's burden is lighter. It adds value by noting the return includes SDR scores and use-case recommendations, but it does not disclose response size, ordering, or performance characteristics. This is acceptable given the annotation, 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?

  The description is two concise sentences that immediately state the action ('List'), the target resource, and the key return contents. Every sentence contributes meaningful information, with no repetition of the schema or annotations.

  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-argument informational tool with an output schema, the description covers the essential aspects: purpose, scope (all modes), and return value highlights. The explicit link to mcp_opendaw_split_stems gives it the necessary context for an agent to decide when to call 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 and the input schema is empty, so there is no parameter detail to add. The description correctly focuses on return value context (SDR scores and recommendations), which is more useful than parameter information 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?

  The description clearly identifies the tool as 'List available stem separation modes with descriptions' and explicitly ties it to mcp_opendaw_split_stems. This distinguishes it from related tools like split_stems or export_stems by framing it as the informational counterpart, with a specific verb and resource.

  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: this tool returns all modes supported by mcp_opendaw_split_stems, implying it should be used to discover available separation modes before invoking split_stems. However, it does not explicitly state when not to use it or mention alternative tools, so it falls 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.

• mcp_opendaw_move_region_to_trackA
  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 key side effects: the region keeps its position/duration/content and the source track loses the region. It also states the return behavior ('Returns success or error'). This goes beyond a bare mutation claim by specifying invariants and the fact that the source is affected, though it does not cover undo behavior or edge-case validation.

  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: an opening sentence stating the core action, a behavioral invariant sentence, a bullet-like parameter list, and a return-value note. Every sentence earns its place; 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?

  The description covers the essential semantics for a 5-parameter cross-unit move operation: parameter meanings, the preservation of region properties, and the source track losing the region. However, it omits guidance on when to use this over the closely related copy_region_to_track or transfer_region, and it does not mention possible failure modes (e.g., invalid indices) or whether the operation is undoable. Given the complexity, it is adequate but not exhaustive.

  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. It defines each parameter in plain language (src_unit_index, src_track_index, region_index, dst_unit_index, dst_track_index) with context ('Source track index within source unit'), adding meaning that the schema's bare titles lack. This fully explains the 5-parameter interface.

  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') and resource ('region from one track to another'), and clarifies that it can cross audio units. It distinguishes from the copy sibling by stating 'The source track loses the region,' making the tool's unique purpose 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 gives clear context for when to use the tool (when moving a region between tracks), but it does not explicitly mention alternatives or provide exclusions. The statement 'The source track loses the region' implies a contrast with copying, but it never explicitly says 'to keep the source, use copy_region_to_track' or otherwise compare against sibling tools.

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

• mcp_opendaw_query_loading_completeA
  4.3/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 burden. It discloses the return values and their semantic meaning ('loaded' and 'is_ready'), which effectively conveys the read-only, status-query nature. It does not discuss potential blocking behavior or error handling, but for a simple status check 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 extremely concise: one sentence for the purpose and a compact bulleted list of return fields. Every sentence contributes value, and the main purpose 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?

  For a parameterless status query with an output schema, the description fully explains the tool's function and both return fields. It is complete within its simple scope, and no additional context 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 and schema coverage is 100%, so no parameter descriptions are needed. The description adds no parameter semantics, but the baseline for 0-param tools is 4 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 clearly states the tool checks if all audio samples are loaded and ready for playback. It uses a specific verb ('Check') and resource, distinguishing it from sibling status tools like engine status or wait_for_condition.

  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 implied as a readiness check before playback, but the description does not explicitly mention when to use this tool versus alternatives like mcp_opendaw_get_engine_status or mcp_opendaw_wait_for_condition. No exclusions or alternative references are provided.

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

• mcp_opendaw_reset_playfield_paramsA
  4.3/5.0
  Behavior4/5

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

  The description adds value beyond the destructiveHint annotation by listing exactly which parameters are reset (mute, solo, exclude, polyphone, pitch, attack, release, sampleStart, sampleEnd, gate). It clearly communicates the destructive scope, though it does not mention undoability or side effects on other sample slots.

  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 clear purpose line, a list of affected parameters, and parameter definitions. Every sentence earns its place, 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?

  Given the tool's relative simplicity and the presence of an output schema, the description is sufficiently complete. It covers the operation, the affected parameters, the required inputs, and the return type ('Returns success or error'). No critical information 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 0% description coverage, so the description must explain the parameters. It provides one-line definitions for both: 'unit_index: AU index containing the Playfield' and 'sample_index: Sample slot index to reset.' This adds meaning beyond the bare property names, though it could be richer with range or indexing 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 clearly states the tool's function: 'Reset all parameters of a Playfield drum sample to defaults.' This uses a specific verb with a precise resource and scope, and it is distinct from sibling tools like 'set_playfield_sample_enabled' or 'create_playfield_sample'.

  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 (when you need to reset all Playfield sample parameters), but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or conditions. No sibling tools are referenced as alternatives.

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

• mcp_opendaw_screenshot_dawA
  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 disclose behavior. It mentions the base64 PNG return format, which is key. However, it does not explicitly state whether the operation is read-only or any potential limitations, leaving some ambiguity for a tool with no 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?

  The description is only two sentences and immediately front-loads the action and result. Every word serves a purpose with no 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?

  Given the tool's simplicity (no parameters, clear output format), the description covers what it does, what it returns, and when it's useful. It is sufficiently complete without needing to describe complex behaviors or return structures.

  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 fully defines the input. The description doesn't need to add parameter semantics, and the baseline for zero-parameter tools 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 explicitly states 'Take a screenshot of the openDAW UI' with a clear verb and object. It also specifies the output as a base64-encoded PNG, making the tool's function unambiguous. No other sibling tool appears to be a screenshot tool, so it stands 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 notes it is 'Useful for visual debugging and verifying project state,' indicating when to apply it. It does not explicitly mention alternatives or when not to use it, but the context is clear for a simple screenshot tool.

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

• mcp_opendaw_set_automation_interpolationA
  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. It discloses the main behavior (set interpolation, affects curve) and notes that curve_slope only applies to 'curve' interpolation. However, it doesn't discuss side effects, reversibility, or error conditions beyond 'Returns success, or error'.

  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 main purpose, followed by a single line on effect, then a structured parameter list, and a brief return note. No wasted words; every sentence adds 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?

  Given the tool has 6 parameters and no annotations, the description covers parameters comprehensively and the core behavior. The output schema likely handles return details. It could mention prerequisites (e.g., the event must exist) but that's an acceptable 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?

  Schema description coverage is 0%, but the description fully compensates by explaining every parameter's meaning, including allowed values for 'interpolation' and the range for 'curve_slope', plus the conditional use of curve_slope. This is exemplary compensation for the schema gap.

  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 verb 'Set' and the specific resource 'interpolation type of an existing automation event'. This distinguishes it from sibling tools like create/delete/update automation event, and the effect is clarified by 'Changes how the automation curve transitions from this event to the next'.

  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: it affects the transition from this event to the next, implying it's for modifying an existing event's interpolation. Does not explicitly name alternatives or exclusion cases, but the context is strong enough to infer when to use.

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

• mcp_opendaw_set_bus_enabledA
  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 explains the effect of the `enabled` parameter (true = enable, false = mute) and the source of `bus_index`, which is helpful. However, it does not disclose side effects (e.g., whether muting affects sends, persistence, or whether the operation is reversible) beyond the immediate parameter mapping. This is adequate 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 three lines, front-loaded with the core action, and each line serves a distinct purpose: describing the action, then defining parameters. There is no fluff or repetition. It is concise and 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 simple two-parameter setter with an output schema, the description is nearly complete. It covers the tool's behavior, parameter sourcing, and a key convention (0 = primary output). It doesn't mention error conditions like an invalid bus index, but given the existence of an output schema and the simple nature of the operation, this is a minor gap. A more careful description might note that the bus must already exist or be visible from list_audio_buses.

  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 excellently. It explains the exact meaning and provenance of `bus_index` ('from list_audio_buses, 0 = primary output') and the meaning of `enabled` (True to enable, False to mute). This fully clarifies both parameters 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 the tool's function: 'Enable or mute an audio bus' with a specific resource (audio bus) and action. The parenthetical '(FX bus A/B comparison)' adds a concrete use case, distinguishing it from other setter tools like set_track_mute. The verb and resource are specific and 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 implies the usage context by mentioning 'FX bus A/B comparison,' which tells the agent when this tool is useful. It does not explicitly exclude other tools or name alternatives, but the context is clear enough for selection among the large sibling set. Slight deduction for lack of explicit 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.

• mcp_opendaw_set_clip_playbackA
  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 skip behavior ('Pass None...'), the return value ('Returns updated playback values.'), and clarifies which fields are modified. It also notes the clip's ClipPlaybackFields object, acknowledging other fields (quantise, trigger) that are not affected. This goes beyond a bare mutation description, though it does not cover potential errors or 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.

  Conciseness3/5

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

  The description is front-loaded with a clear purpose and structured with bullet-point lists. However, loop/reverse/speed definitions are repeated in both the ClipPlaybackFields section and the parameter list, creating redundancy. It could be more concise without losing meaning.

  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 the essential aspects: purpose, all parameters, the None-skip behavior, and the return type. Since an output schema exists, the return values are likely documented elsewhere. Missing details like error handling or prerequisites beyond 'from list_clips' are not critical for a simple setter tool, making this 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 zero description coverage, so the description fully compensates. It explains every parameter (loop, reverse, speed, unit_index, track_index, clip_index) in plain language, including the meaning of speed ('1 = normal') and the None-skip semantics. This adds 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 clearly states the tool's purpose: 'Set clip playback parameters (loop, reverse, speed) on a clip.' This identifies the specific verb (set), resource (clip playback parameters), and scope (loop, reverse, speed), distinguishing it from sibling tools like set_clip_properties or set_clip_mute.

  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 use context by stating it sets playback parameters and includes a prerequisite hint: 'clip_index: Clip index (from list_clips)'. It also explains the skip behavior ('Pass None for any parameter to skip changing it'), which is useful operational guidance. However, no explicit alternatives or exclusions are mentioned, 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.

• mcp_opendaw_set_crusher_bitsA
  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 burden. It adds meaningful behavioral context beyond the schema: the bits parameter mapping (16=no crushing, 1=extreme) and the requirement that effect_index must reference a Crusher. This helps the agent understand the effect of the parameter and preconditions. It does not disclose error handling or side effects, but for a simple setter 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: one action sentence followed by three bullet-style parameter lines. It front-loads the core purpose, and every line adds necessary information without redundancy or fluff. Ideal structure for a parameter-focused 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 tool's low complexity, the description covers the essential aspects: what it does, all parameters with ranges, and a key prerequisite (must be a Crusher). The presence of an output schema likely documents return values, so that omission is acceptable. Still, it could benefit from mentioning behavior on invalid indices or non-Crusher effects, but this is not critical for a simple setter.

  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. It does so fully: each parameter is explained with a concise line — unit_index ('AU index'), effect_index ('Effect index in the audio effect chain (must be a Crusher)'), and bits ('Bit depth (1-16, where 16=no crushing, 1=extreme)'). This adds semantic meaning and range details that 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 clearly states the action: 'Set the bit depth on a Crusher (bitcrusher) effect.' This is a specific verb+resource combination that distinguishes it from siblings like set_crusher_crush (which presumably sets crush amount, not bit depth) and generic set_effect_parameter_int. The scope 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?

  The description implies usage (when you need to adjust bit depth on a Crusher effect) and provides a constraint ('effect_index must be a Crusher'), but it does not explicitly name alternative tools or state when not to use this tool. No when/when-not guidance beyond the inherent type restriction.

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

• mcp_opendaw_set_effect_parameter_boolA
  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 adds useful behavioral context by enumerating which boolean fields exist per device (e.g., Compressor lookahead, Gate inverse), including a caveat for Delay 'freeTimeSync (if available)'. However, it does not disclose side effects, error behavior, or reversibility of the mutation, leaving transparency partial.

  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 front-loaded. The opening sentence states the core purpose, followed by a compact bulleted list of device-specific fields. Every sentence adds value, and the formatting improves scannability.

  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 setter tool with a simple schema, the description provides all necessary context: device-specific valid parameter names, index semantics, and value type. An output schema exists, so return-value documentation is not required. The 'if available' caveat for Delay shows attention to edge cases, making the tool self-contained.

  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 schema only provides types/titles. The description compensates by explaining each parameter: unit_index as 'Audio unit index', effect_index as 'Effect position in the chain (0-based)', parameter_name with concrete examples, and value as 'true or false'. It adds significant 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+resource statement: 'Set a boolean parameter on an audio effect.' It clearly distinguishes this from sibling setters by specifying 'boolean parameter' and referencing the generic float setter. The device-specific field list further clarifies the exact 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 explains when to use this tool: for device-specific boolean fields not exposed through the generic float setter. It lists the applicable devices and fields, giving concrete usage context. It names the 'generic float setter' as an alternative but does not explicitly mention int/string setters or provide when-not-to-use exclusions.

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

• mcp_opendaw_set_fold_oversamplingA
  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 burden. It discloses the value mapping (0/1/2) and the requirement that the effect must be a Fold, which is useful. However, it does not mention side effects, index conventions, or error conditions beyond the Fold requirement. For a mutation tool, this is adequate 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 four short lines, front-loaded with the purpose, followed by concise parameter definitions. Every sentence adds value with no redundancy 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 three fully described parameters and an output schema present, the description is largely complete. It could optionally mention zero-based indexing or provide an example, but 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%, but the description fully defines each parameter: unit_index as AU index, effect_index as effect index in the audio effect chain, and oversampling with explicit value meanings. This goes well beyond the schema's bare integer 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 opens with a specific verb+resource: 'Set the oversampling level on a Fold (wavefolding) effect.' This clearly distinguishes it from generic effect setters among siblings, as it targets a specific effect type and parameter.

  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 context by indicating the tool is for Fold effects, and explicitly states that effect_index must be a Fold. It does not name alternative tools or exclusion scenarios, but the constraint is enough to guide appropriate use.

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

• mcp_opendaw_set_marker_repeatA
  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 behavioral disclosure burden. It adds useful semantics by explaining that repeat_count 0 means infinite repeat and 1-16 means N repeats, but it does not mention side effects, error behavior, or reversibility of the 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 extremely concise: one purpose line and two parameter lines, with no filler. Every sentence earns its place, 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 simple two-parameter setter with an output schema, the description covers the operation, parameter semantics, and the prerequisite of list_markers. It lacks mention of error conditions for invalid markers, but overall it is sufficiently complete for its complexity.

  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 both parameters: marker_index is the 0-based index from list_markers, and repeat_count has a clear value range and meaning. This goes well beyond the bare integer type definitions in 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 clearly states 'Set the repeat count on a timeline marker', using a specific verb and resource. It distinguishes itself from sibling marker tools like set_marker_position, set_marker_label, and delete_marker by focusing on the repeat count property.

  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 specifying that marker_index comes from list_markers and is 0-based, implying the prerequisite of listing markers first. It does not explicitly discuss alternatives or when not to use the tool, but the context is sufficient for a simple setter.

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

• mcp_opendaw_set_metronomeA
  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 behavioral disclosure. It specifies that None leaves parameters unchanged, gives valid ranges for gain and subdivision, and explains the mapping for beat_subdivision. This exceeds what the schema alone provides, though it does not discuss side effects or 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 concise and well-structured: a one-line summary followed by a bulleted list of parameters with clear explanations. Every sentence adds value, 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?

  Given that an output schema exists (though not shown) and this is a straightforward setter, the description provides sufficient context: what the tool does, parameter meanings, and defaults. It does not mention global vs. project scope or potential side effects, but these are not critical for this tool's typical use.

  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 provides types and null defaults, while the description adds essential semantics: gain range 0.0-1.0, default values, subdivision meanings, and the behavior of None for each parameter. This 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 'Configure' with a clear resource 'metronome settings', and the parameter details reinforce what the tool does. It is distinct from sibling tools like set_bpm or set_time_signature because it specifically targets metronome click settings.

  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 does not explicitly state when to use this tool versus alternatives or mention exclusions. The usage is implicitly clear from the purpose, but there is no explicit guidance on context or alternative tool selection, so it falls short of the higher bar.

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

• mcp_opendaw_set_piano_note_labelsA
  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 transparency burden. It discloses the mutation (setter/toggle) and the return values (old and new), which is useful. However, it doesn't mention scope (e.g., all tracks vs current) or 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 three concise sentences: purpose, parameter explanation, and return behavior. No fluff, front-loaded with the main action.

  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 setter with an output schema (not shown), the description covers the essentials: what, how, and return. It's mostly complete, though the lack of scope clarification (global vs track-specific) leaves a minor 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?

  Schema coverage is 0%, so the description fully compensates by explaining the boolean parameter's meaning: 'True to show note labels, false to hide.' This adds complete semantic clarity beyond the schema's bare 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 clearly states the specific action: toggling note labels in the piano roll, with examples of the label types. It's distinct from sibling tools by focusing on labels, not scale or other piano settings.

  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 when you want to show or hide note labels, but doesn't explicitly discuss when to use this versus alternatives (e.g., set_piano_note_scale). No exclusions or alternative conditions are provided.

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

• mcp_opendaw_set_piano_note_scaleA
  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 does disclose the return behavior ('Returns success with old and new values') and provides the valid range for the parameter. However, it does not mention whether the change is a view-only setting, whether it affects note data, or any prerequisites. This is adequate 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 compact and front-loaded. The first sentence states the purpose, the second explains the parameter, and the third notes the return value. Every sentence adds necessary information with no redundancy 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 tool with one parameter and an output schema, the description is nearly complete. It explains the parameter and return values, leaving little ambiguity. However, it does not explicitly state the scope (e.g., which piano roll editor is affected) or confirm that the change is non-destructive to note data. These are minor gaps for such a simple 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?

  The schema description coverage is 0%, so the description must compensate. It fully explains the sole parameter 'scale': its type (number), range (0.5 to 2.0), default (1.0), and behavior at extremes (maximum zoom in/out). This provides meaning well 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 opens with a specific verb+resource: 'Set the piano roll note scale (vertical zoom).' This clearly identifies what the tool does and distinguishes it from sibling piano-roll tools like set_piano_time_range (horizontal zoom) and set_piano_keyboard. The vertical zoom clarification removes 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?

  The description gives clear context about when to use the tool by explaining the scale factor semantics (0.5 to 2.0, 1.0 default, 2.0 zoom in, 0.5 zoom out). While it does not explicitly name alternative tools or state when not to use it, the context is sufficient for an agent to decide this is the correct tool for adjusting vertical zoom.

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

• mcp_opendaw_switch_phaseA
  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 disclose behavioral traits. It reveals the key behavior—switching phase changes which tools are registered—and conditional behavior on OPENDAW_MCP_MODE. However, it does not clarify what happens when the mode is not 'phase', whether the phase persists across sessions, or whether the tool is reversible (e.g., can you switch back). These are minor 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 description is well-organized: a clear opening statement, a concise context explanation, a bulleted phase list, and illustrative examples. All content is necessary and additive; 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 tool with one parameter and no annotations, the description covers the core functionality, valid values, and usage examples. It does not address non-phase-mode behavior or whether the change is persistent, but these are edge cases. The output schema exists, so return values are not the description's responsibility.

  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 for the required 'phase' parameter. The description fully compensates by listing the four valid values (inspect, compose, mix, render) and explaining what tools each includes, plus examples. This gives the agent all needed parameter 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 clearly states a specific verb and resource: 'Switch the active tool phase for phase-based tool loading.' It also explains the motivation (reducing schema payload by showing only relevant tools), which distinguishes it from all sibling tools as a meta-tool controlling tool availability.

  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 the context (when OPENDAW_MCP_MODE=phase) and maps each phase to its tool categories, giving clear usage context. It provides examples like switch_phase('compose') for composition tools. It does not explicitly state 'use this when you need tools from a different phase' as a directive, but the phase list makes this obvious.

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

• mcp_opendaw_wait_for_conditionA
  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 behavioral burden. It discloses that polling occurs at regular intervals, stops when condition returns true or timeout is reached, and provides default values for timeout and poll interval. However, it does not explain what happens on timeout (e.g., return value or exception), which would be 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 concise and front-loaded, with the primary purpose in the first sentence, followed by a brief behavioral explanation and parameter details. Every sentence adds value, and the parameter list is clear and compact.

  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 nature of the tool and the presence of an output schema (which likely covers return values), the description is reasonably complete. It covers the polling behavior, timeout, and interval. However, it doesn't mention any side effects or error conditions beyond timeout, though these may be omitted due to the output schema.

  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 fully compensates by explaining all three parameters: condition_js is a JavaScript expression returning a truthy value, timeout_ms has a default of 10000, and poll_interval_ms has a default of 500. This 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 clearly states the tool's purpose: 'Wait for a JavaScript condition to evaluate to true in the DAW context.' This uses a specific verb (wait) and resource (JavaScript condition), and it is distinct from sibling tools like mcp_opendaw_transport or mcp_opendaw_get_project_state.

  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 you need to wait for a condition) but does not explicitly state alternatives or exclusions. It says it polls until the condition is true or timeout, so an agent can infer usage context, but there is no explicit 'when-not' guidance.

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

• mcp_opendaw_add_signature_changeA
  4.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 full burden. It explains the underlying mechanism (creating a SignatureEventBox on the signature track) and clarifies that this is different from setting a global default. However, it doesn't disclose whether this operation mutates existing events, whether there are constraints (e.g., position must be positive, denominator limited to powers of 2), or potential side effects on adjacent measures. The description adds some behavioral context but leaves these 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 description is well-structured: a one-sentence summary, a paragraph contrasting with the sibling tool, and a compact bullet-style list of parameters. Every sentence earns its place, and the key info is front-loaded. No fluff or repetition of schema fields.

  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 tool has 3 required parameters, an output schema, and no annotations. The description covers the core purpose, the key distinction from the sibling tool, and all parameters. It also mentions the return value ('Returns the created signature event details'), and since an output schema exists, it doesn't need to detail the exact structure. Minor gaps exist (e.g., no mention of validation, edge cases, or interaction with existing signature events), but given the tool's moderate complexity and the output schema, the description is largely sufficient.

  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 compensate, and it does. It explains each parameter in plain language: position_beats is 'Position in beats where the change occurs,' numerator is 'Number of beats per bar (top number),' and denominator is 'Note value per beat (bottom number: 4=quarter, 8=eighth).' This adds musical meaning beyond the raw schema, though it could go further with acceptable ranges (e.g., numerator 1-32, denominator powers of 2).

  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's function: 'Add a time signature change at a specific position in the track.' It specifies the verb (add), the resource (signature change), and the location (position in the track). It also explicitly distinguishes itself from set_time_signature by noting that it creates a SignatureEventBox on the timeline's signature track rather than setting the global default, which differentiates it from its sibling tool.

  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 contrasts this tool with set_time_signature: 'Unlike set_time_signature (which sets the global default), this creates a SignatureEventBox on the timeline's signature track, allowing time signature changes mid-track.' This gives clear when-to-use vs. when-not-to-use guidance. It also provides a concrete example (4/4 → 3/4 → 4/4) illustrating the intended mid-track use case.

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

• mcp_opendaw_add_suspensionA
  4.4/5.0
  Behavior4/5

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

  No annotations are provided, but the description compensates with detailed behavior: it specifies that notes on strong beats are targeted, preparatory notes are placed a step above/below and snapped to scale tones, velocities are given with musical rationale, and cross_track behavior is explained. However, it does not explicitly state whether original notes are modified or preserved on the source track, which is a notable 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.

  Conciseness4/5

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

  The description starts with a concise purpose sentence, then builds context with the suspension definition, structure, and algorithm. The Args section is logically ordered. The cultural flourish about Bach chorales and film scores adds context but is not strictly necessary, making it slightly less concise than ideal.

  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 complex tool with 11 parameters and no schema descriptions, the description provides thorough documentation of the algorithm, parameter effects, and musical intent. It does not mention error cases or prerequisites such as needing metrical information to find strong beats, but overall it is highly complete for an AI 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?

  The input schema provides zero descriptions, but the Arg list covers all 11 parameters with types, defaults, ranges (e.g., preparation_beats 0.25-2.0), scale list, and musical context (e.g., 'down' = classic 4-3, 9-8 suspension). This fully compensates for the schema's lack of 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 opening line 'Add suspension-resolutions to existing notes' clearly states the action and resource. The subsequent explanation of the suspension structure (Preparation → Suspension → Resolution) and the algorithm makes it easy to distinguish from sibling ornament tools like add_passing_tones or create_appoggiatura.

  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 tool operates on existing notes, targets strong beats, and creates suspensions, giving clear context for when to use it. However, it never explicitly mentions alternatives or states 'use this instead of X,' so it lacks explicit exclusions.

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

• mcp_opendaw_analyze_harmonic_rhythmA
  4.4/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, and the description discloses several behavioral traits beyond that: it identifies chords using the same logic as identify_chords, returns specific analysis outputs (chord change positions, durations, rate, density, stable/active sections, total events), and notes the data source is MIDI notes. This adds substantial context about what the tool does with input and what it produces.

  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 appropriately structured with a clear summary, bullet-point output list, comparison to related tools, usage suggestions, parameter definitions, and a return value statement. Each section earns its place 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?

  The tool has an output schema (though its content is not shown in the provided context), so return values may already be documented there. The description covers usage context, input semantics, and output types at a level appropriate for the tool's complexity. It could be improved by explaining why region_index defaults to -1 meaning 'first' rather than all regions, but overall it is complete for selection and invocation.

  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%, but the description includes a brief parameter list with defaults and meanings (unit_index, track_index, region_index with -1 = first and -2 = all regions, group_tolerance as beats of tolerance, min_notes as minimum notes). Though concise, it provides essential semantics for all five 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 states the tool's purpose: analyze harmonic rhythm (how fast chords change and where), listing the specific outputs. It distinguishes itself from sibling identify_chords by explicitly focusing on the temporal pattern of harmony.

  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 vs alternatives, naming identify_chords as complementary and listing three specific sibling tools to use with it: analyze_song_structure, reharmonize_progression, and create_arrangement_variation.

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

• mcp_opendaw_analyze_song_structureA
  4.4/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, and the description consistently presents this as a read-only analysis operation, so no contradiction. It adds behavioral detail beyond the annotation: the algorithm (scans bar-by-bar, computes features, groups consecutive bars, classifies segments) and the output structure (per-segment classification with bar range, density, energy, feature summary). This is useful context, though it could also mention edge cases or data requirements.

  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 well-structured with a clear opening, algorithmic overview, use-case list, and parameter breakdown. It is somewhat long (multiple paragraphs), but each section adds value and the information is front-loaded. A tighter version could combine the algorithm and use cases, but the current format is readable and effective.

  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 moderate complexity and presence of an output schema, the description is complete: it explains what it does, the algorithm, the parameters, the output type, and typical use cases. It does not need to describe return values in detail because an output schema exists. The description fully equips an agent to decide when and how to call this 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?

  Schema description coverage is 0%, so the description must carry the burden. It does: 'unit_index: AU index (-1 = all AUs)' and 'bars_per_segment: Minimum bars per structural segment (default 4)...' This adds meaning beyond the plain integer types and defaults in the schema. It could be richer (e.g., valid ranges for unit_index) but is adequate.

  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+resource: 'Analyze song structure by segmenting MIDI content into structural parts.' It details the method (bar-by-bar feature extraction, grouping, classification into intro/verse/chorus/etc.), and distinguishes from siblings by focusing on analysis and structural segmentation, not creation or editing.

  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 use cases: 'Essential for: understanding existing arrangements, finding where sections change, verifying song form, and planning variations or extensions.' This gives clear context on when to use. However, it does not mention when NOT to use it or contrast with alternative analysis/creation tools, so it misses the 'when-not' part for a full 5.

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

• mcp_opendaw_augment_notesA
  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 full burden. It discloses factor effects, mode behavior on note positions (including potential overlaps/gaps), the possibility of skipped notes, and the return value. It omits explicit claims about reversibility or in-place modification, but covers core side effects adequately.

  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 well-structured with a clear summary, factor bullets, a musical example, parameter definitions, and return information. It is longer than minimal but justified by complexity; the Beethoven/Bach example, while illustrative, is not essential for an AI agent, making it slightly less concise than a 5.

  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?

  It covers core functionality, all parameters, return behavior, and provides real-world context for use. It lacks explicit edge-case handling (e.g., invalid factor range or no notes present) but the mention of skipped notes covers some. Given the output schema captures exact return structure, this is adequately 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 is the sole source of parameter meaning. It thoroughly explains every parameter: factor range and effect, unit_index as AU index, track_index as note track, region_index defaulting to -1 for all regions, and mode with two detailed behaviors. This far exceeds the schema's bare type 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 opens with a specific verb and resource ('Augment or diminish note durations') and immediately identifies it as the 'fourth classical transformation', clearly distinguishing it from transpose, reverse, and invert. This makes the tool's purpose unambiguous and differentiates it from 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?

  It provides clear guidance on when to use augmentation vs diminution through factor ranges, and explains the two modes ('scale' and 'stretch') with practical implications for note positions. However, it does not explicitly name alternative tools for other transformations or state when not to use this tool, though it implies complementarity with transpose/reverse/invert.

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

• mcp_opendaw_compare_to_referenceA
  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. It discloses what the tool measures (five dimensions), what it returns ('per-dimension comparison + actionable deltas'), and provides an example output. It also specifies WAV file types and path resolution ('exports dir or absolute path') for both parameters, adding behavioral context beyond the schema.

  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 well-structured with a clear purpose sentence, bullet list of dimensions, parameter notes, and a code example. The motivational phrase 'This is how you learn how pros mix your genre' is slightly redundant but does not harm comprehension. Overall, it is appropriately sized for the tool's complexity.

  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 moderate complexity and the presence of an output schema, the description sufficiently covers the tool's function, inputs, and example return. It could mention prerequisites like matching file lengths or sample rates, but the dimension list and path details give enough context for an agent to select and 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. It dedicates a line to each parameter: 'filename: Your mix WAV (exports dir or absolute path)' and 'reference: Reference track WAV (exports dir or absolute path).' This clarifies file type, path conventions, and roles, fully covering the two required parameters. The example further illustrates usage.

  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/B compare your mix against a reference track across all dimensions' with a specific verb and resource. It enumerates five concrete comparison dimensions (LUFS, spectral curve, stereo width, dynamic range, spectral centroid), which distinguishes it from sibling analysis tools like analyze_mix or measure_lufs.

  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 use: 'This is how you learn how pros mix your genre. Drop in a reference track you admire and see exactly what's different.' This implies when to use it, but it does not explicitly mention exclusions or contrast it with alternatives like compare_to_profile or match_to_reference, which are siblings with potentially overlapping purposes.

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

• mcp_opendaw_consolidate_regionA
  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. It explains the key behavior: if the region shares its collection, a new independent copy is created so edits don't affect other regions. It also mentions the return type (success or error). Missing details like reversibility or side effects on the original collection, but the core behavioral 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 efficient: a clear opening sentence, a conditional behavior explanation, a structured parameter list, and a return statement. No fluff, all sentences earn their 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?

  Given the tool's simplicity (3 integer parameters, no nested objects) and the presence of an output schema, the description covers the necessary aspects: operation, condition for use, parameter meanings, and return status. It could be improved by clarifying behavior when the region is not shared, but overall it is complete for the tool's complexity.

  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 compensate. It provides concise explanations for each parameter: unit_index, track_index, and region_index, giving domain context that the schema lacks. This adds real meaning beyond the raw integer 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 uses a specific verb-resource pair ('Consolidate a region's event collection') and clearly explains the outcome: making it unique (not shared/mirrored). This distinguishes it from sibling tools like consolidate_clip or duplicate_region by focusing on the mirrored-event-collection 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?

  It explicitly describes the scenario where this tool is appropriate: when a region's event collection is shared/mirrored with other regions and you want an independent copy. It does not list alternative tools or when-not-to-use cases, but the conditional context is clear.

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

• mcp_opendaw_copy_region_to_trackA
  4.4/5.0
  Behavior4/5

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

  No annotations exist, so the description carries the full burden. It discloses that copies include all content (notes, audio, automation events), works across region types, and returns new position and duration. It doesn't explicitly state that the source remains unchanged, but 'copy' strongly implies non-destructive 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 front-loaded, stating the action immediately. It includes a brief support scope, grouped parameter explanations, and a return note—all in a few sentences 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?

  Covers the core purpose, supported region types, all parameters, and return value—sufficient for an agent to invoke correctly. Missing explicit preconditions (e.g., destination track existence) and edge-case handling (e.g., copying to same position), but overall adequate for a copy operation with an output schema.

  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 explaining source/destination coordinates ('src_unit/src_track/src_region', 'dst_unit/dst_track') and position semantics in PPQN with 'omit to use source position'. This goes beyond the bare parameter titles, though it doesn't define 'unit' or validate required vs optional clearly.

  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 clearly states it 'Copy[s] a region to a different track (or same track at new position)', specifying the action, resource, and destination. It distinguishes from siblings like move_region_to_track and duplicate_region by the explicit copy semantics and by listing supported region types (note, audio, automation).

  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 on when to use: copying a region between tracks or repositioning on the same track. While it doesn't explicitly name alternatives or state when not to use, the implied differentiation from move/duplicate tools is sufficient for most agents to choose correctly.

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

• mcp_opendaw_create_automation_eventA
  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 transparently covers the create-or-update semantics, the interpolation options ('none', 'linear', 'curve'), the curve_slope dependency on interpolation, and the return behavior ('Returns the created/updated event info, or error'). It does not mention error conditions or permissions, but the key behavioral traits are well disclosed.

  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 organized with a brief introduction followed by a parameter list. It is slightly longer than necessary because it interleaves the parameter explanations into the description, but every sentence adds value (e.g., interpolation meanings, curve_slope usage). The structure is readable and front-loaded with the core purpose.

  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 tool has an output schema, so the description does not need to detail return values. It covers the primary behavior, parameter semantics, and the upsert condition. It lacks information about prerequisites (e.g., the track must be a value track) and failure scenarios, but overall it is sufficiently complete for an agent to invoke the tool correctly in most scenarios.

  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. Every parameter is explained: unit_index (AU index), track_index (Value track index), position_beats (Position in beats, float), value (Normalized 0.0-1.0), interpolation (allowed values and meaning), and curve_slope (range, default, and only used when interpolation='curve'). This exceeds the minimal requirement and provides actionable 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 clearly states the tool's function: 'Create a single automation event at a specific position on a value track.' It also specifies the upsert behavior ('If an event already exists at the same position, its value is updated'), which distinguishes it from sibling tools like update_automation_event, delete_automation_event, and move_automation_event.

  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 context by explaining the single-event creation/update behavior and detailing the interpolation types and value normalization. However, it does not explicitly mention when to prefer this over the dedicated update_automation_event tool, nor does it state any exclusions (e.g., for bulk automation operations). The context is clear but lacks explicit alternatives.

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

• mcp_opendaw_create_cadenzaA
  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 burden of behavioral disclosure. It explains the cadenza's irregular rhythm, virtuosic contour, segment-based construction, and tempo characteristics, and states that it returns notes created, segment breakdown, and cadenza statistics. It does not detail potential side effects like overwriting existing notes or requiring an existing track, but the core generative 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.

  Conciseness4/5

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

  The description is well-structured with clear sections for definition, styles, segment types, and argument descriptions. It is longer than average, but the architectural detail is relevant and helps the agent make informed choices. A few conceptual points are somewhat redundant, but overall the structure is efficient 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?

  Given the tool's complexity (11 parameters, no annotations, no schema descriptions), the description provides a comprehensive overview: what a cadenza is, how rhythm differs from other tools, available styles and segments, parameter meanings, and return values. It stops short of describing operational preconditions like track/unit validation or exact note-placement behavior, but it is sufficient for initial selection and 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's Args section fully compensates by documenting all 11 parameters with meaningful one-line explanations. It adds semantics beyond the bare schema, such as 'duration_beats: Approximate total duration in beats (4-64)' and 'breath_marks: Comma-separated beat positions for pauses/breaths,' which are essential 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 clearly defines the tool as 'Create a cadenza — an unmeasured virtuosic solo passage with rubato,' providing a specific verb and resource. It explicitly distinguishes itself from siblings by stating 'Unlike all other tools that use quantized beat grids, cadenzas use irregular, speech-like rhythm,' making its unique 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 gives strong contextual guidance by explaining that cadenzas use unmeasured, speech-like rhythm as opposed to the quantized beat grids of other tools, implying when this tool is appropriate. It also provides style and segment options to help shape usage, though it doesn't name specific alternative tools or state explicit prerequisites.

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

• mcp_opendaw_create_country_arrangementA
  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 full burden. It transparently describes the musical behavior of each track, including patterns, scales, and stylistic distinctions. It also mentions return value ('Returns notes created per track and total'). However, it does not disclose whether existing notes on target tracks are overwritten or if specific track prerequisites must exist.

  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 long but well-structured with a summary, per-track bullets, tempo guidance, parameter explanations, and examples. Every sentence adds value—musical rationale, constraints, or usage. It is appropriately sized for a complex 11-parameter tool and is front-loaded with the core purpose.

  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 complexity and lack of annotations, the description covers musical patterns, parameter constraints, examples, and return behavior. The output schema exists, so return values need not be detailed. The main gap is not stating whether the tool assumes existing tracks or creates them, and not clarifying behavior with pre-existing notes.

  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%, but the description compensates by explaining 9 of 11 parameters, including defaults and constraints (e.g., bars must be multiple of 8, octave meaning with a concrete example). It omits velocity and start_beat, which are two undocumented parameters in the schema. Overall, it adds significant value 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 clearly states it creates a full country arrangement with specific track roles (drums, bass, chords, lead). It distinguishes this from other genre tools by detailing the musical pattern (boom-chick, root-five bass, major pentatonic lead) and contrasting with blues ('not shuffled like blues'). It goes far beyond a generic 'create arrangement' statement.

  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 context for when to use the tool (classic country/Americana) and gives tempo guidance for different sub-styles (two-step, ballad, bluegrass). However, it does not explicitly name alternative tools or state when not to use it, though the sibling list and genre-specific detail imply the appropriate scenario.

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

• mcp_opendaw_create_dnb_arrangementA
  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. It discloses key behavioral traits: it creates three tracks, is tempo-aware (optimized for 170-180 BPM), locks bass and drums rhythmically, and returns 'notes created per track and total.' It lacks explicit warnings about overwriting existing notes or requiring specific track setups, but overall it gives a solid picture of what happens.

  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 appropriately sized. It opens with the main purpose, uses bullet points for track details, then lists parameters concisely, and ends with practical examples. Every section earns its place without excessive verbosity.

  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?

  This is a complex tool with 10 parameters and multiple musical elements. The description covers its purpose, behavior, parameter semantics, and examples. It mentions the return value and has an output schema, so detailed return structure isn't needed. The only minor gaps are the undocumented 'start_beat' parameter and some ambiguity about 'AU index', but overall it is sufficiently complete for an agent to 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?

  The schema has no parameter descriptions (0% coverage), so the description must compensate. It provides meaningful explanations for 9 of 10 parameters, including ranges and defaults (e.g., 'bpm: Tempo (160-185, default 174 = classic DnB)'). It omits 'start_beat', which is a small gap, but overall it adds significant context beyond the schema's titles.

  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 exactly what the tool does: 'Create a full drum & bass arrangement — drums + bass + pad across 3 tracks in one call.' It identifies the specific genre (DnB) and differentiates it from other genre arrangement tools by detailing the three-track structure (drums, bass, pad) and the musical content of each.

  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 when to use this tool: when you need a complete multi-track DnB section rather than individual patterns. It says 'Instead of creating individual patterns, it generates a complete DnB section.' However, it does not explicitly name alternative tools or provide exclusion criteria, so it falls short 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.

• mcp_opendaw_create_harmony_lineA
  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 largely delivers: it explains the diatonic shift, key guarantee, velocity scaling, and that it returns created notes. It does not explicitly warn about overwriting existing target content, but it clearly states the source is read (not modified) and describes the target creation behavior with -1.

  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 well-structured with front-loaded purpose, interval bullets, use-case list, and parameter explanations. It's longer than minimal, but each section serves a purpose; the musical style references add useful context without being rambling.

  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 11 parameters and no annotations, the description covers the algorithm, parameter meanings, use cases, and return value. It doesn't detail error cases or prerequisites (e.g., source must contain notes), but an existing output schema and the detailed parameter exposition make it reasonably 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%, and the description fully compensates. It explains interval values with musical meaning (third, sixth, fifth, fourth, octave), root_note+scale guarantee, direction, velocity_scale default, and the source/target unit/track/region semantics. This goes well 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 clear, specific verb+resource: 'Create a harmony line from an existing melody using diatonic intervals.' It distinguishes itself from siblings like create_harmony or create_chorale by emphasizing a parallel harmony line derived from an existing melody, which is a distinct function.

  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 use cases: 'Essential for: vocal harmonies, string pads behind melody, guitar harmonies, counter-melody foundation, thickening lead lines.' This tells the agent when to use the tool, though it doesn't explicitly name alternatives or exclusion criteria.

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

• mcp_opendaw_create_isorhythmA
  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 full behavioral burden. It thoroughly explains the independent cycling of talea and color, the least-common-multiple repetition, and the effect of parameters like repeats and start_beat. It also summarizes return values. A minor gap is not explicitly stating whether existing notes are replaced or appended.

  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 longer than typical, but well-structured with paragraphs and line breaks. It is front-loaded with the core definition, uses examples efficiently, and the historical context adds richness without excess verbiage.

  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 complexity of the isorhythm concept and the fully optional parameters, the description covers the algorithm, all parameters, and output summary. An output schema is present, reducing the need to detail return values. The description provides sufficient context for correct selection and 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 has 0% description coverage, so the description fully compensates by defining every parameter with examples and ranges. For instance, talea and color get comma-separated format examples, and unit_index gets special '-1 = find first AU with note tracks' 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 opens with 'Create an isorhythm — repeating rhythm (talea) × repeating pitch series (color),' clearly stating the verb and resource. It also distinguishes the tool from ostinato, which is a direct alternative, by explaining that ostinato repeats rhythm and pitch together.

  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 the musical concept and explicitly contrasts with ostinato: 'Distinct from ostinato, which repeats rhythm and pitch together as one unit.' This gives a clear alternative and exclusion, though it doesn't enumerate all sibling rhythm tools.

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

• mcp_opendaw_create_midi_echoA
  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 full responsibility for behavioral disclosure. It richly explains feedback modes with concrete examples (e.g., 'linear — each repeat is velocity_decay × previous (0.6 → 0.6, 0.36, 0.216)'), pitch shift semantics, and dest_track behavior. It notes that 'Each repeat copies ALL notes from the source' and mentions the return summary. However, it does not explicitly state whether the original notes are preserved or modified, or how region boundaries are handled, leaving minor gaps.

  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 well-structured with sections for feedback_mode, pitch_shift, dest_track, repeats/delay_beats, a parameter summary, and examples. It is slightly redundant because the parameter list repeats prior explanations, and the length is substantial (~350 words). However, every section adds useful detail, and the examples are illuminating. Slight trimming could make it more concise, but it is not bloated.

  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 complexity (9 parameters) and the 0% schema description coverage, the description covers all needed context: all parameters are explained, return value is mentioned ('Returns echo summary with per-repeat velocity and pitch info'), and two usage examples are provided. It lacks explicit prerequisites or error conditions (e.g., needing a note region, valid unit index), but these are largely implied by the parameter naming and the phrase 'Takes existing notes from a region.'

  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 no descriptions (0% coverage), but the description fully compensates by explaining every parameter. It provides detailed semantics for feedback_mode (with behavior of each value), pitch_shift (with musical examples like '+12 = octave up'), dest_track (same vs separate track), and delay_beats (with note-value equivalents). The narrative section and the parameter summary together give comprehensive meaning beyond the bare schema titles.

  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's purpose: 'Create MIDI echo — repeat notes with decaying velocity and optional pitch shift.' It specifies the resource (existing notes in a region), the action (creates echoing repeats), and the effect (delay, decay, pitch shift). This distinguishes it from sibling tools like repeat_notes or create_stutter by emphasizing the echo/delay character.

  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 creative context by saying 'This is a creative effect, not a simple copy — think guitar delay throws, synth echo fills, vocal repeat stutters.' This implies when to use it (for echo-like effects) and contrasts it with a simple copy, giving some differentiation from repeat tools. However, it does not explicitly name alternative tools or state when NOT to use it, 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.

• mcp_opendaw_create_mute_automationA
  4.4/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It explains the event format, includes examples, and notes return values (events created, mute schedule, track index). However, it does not disclose whether existing automation is overwritten, error behavior, or any destructive side effects—important for a write 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 well-organized: purpose statement, usage rationale, parameter explanations, return info, and two worked examples. Every sentence adds value, and it remains readable despite length. Front-loaded with the main purpose.

  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 moderate complexity (2 params, nested data as string) and presence of an output schema, the description provides sufficient context: input format, examples, expected outcomes, and return summary. It covers the tool's role without needing to detail output fields since an output schema is available.

  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 fully compensates. It explains unit_index as 'AU index to automate mute on' and provides a detailed interpretation of events with a JSON array format, beat semantics, muted meaning, and a concrete example. This goes far 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 clearly states 'Create timed mute/unmute automation events on an audio unit' with a specific verb and resource. It distinguishes from siblings by explicitly stating it 'Replaces multiple set_track_mute calls with one automation track,' setting it apart from other automation 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 provides clear usage context ('Essential for section dynamics: mute drums during breakdowns, unmute for drops, create structural silences') and mentions an alternative (set_track_mute). However, it does not explicitly exclude scenarios or compare with other automation-related siblings like create_automation_event or add_automation.

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

• mcp_opendaw_create_progression_from_keyA
  4.4/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It does explain that the tool generates diatonic progressions, takes a unit/track index, and returns notes/chords/voicings. However, it does not disclose whether existing notes are overwritten, if the tool is non-destructive, or any side effects of placing notes on a track. This is a notable 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 well-structured: summary, parameter breakdown, return values, and a pipeline example. Even though it's lengthy, each sentence earns its place—especially the style enum details, which are essential for correct usage. It is front-loaded with the core purpose and remains scannable via bullet-like lines.

  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 7 parameters and no annotations, the description is remarkably complete: it explains the origin of inputs (detect_key), all parameter semantics, expected return fields, and even a full usage pipeline. It also gives concrete style examples with roman numeral progressions. The only minor absence is error handling or edge cases, but the description covers the core usage thoroughly.

  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 (key, mode, style, unit_index, track_index, start_beat, chord_duration) is explained with ranges, defaults, and detailed examples. The style parameter is exceptionally well documented with degree patterns and genre labels, providing far more than the schema's bare titles.

  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 phrase: 'Auto-generate a diatonic chord progression from a detected key' — clearly stating what the tool does and its input. It distinguishes itself from siblings like create_chord_progression by explicitly linking to detect_key output and the 'no manual chord typing' value proposition.

  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 context: it says the tool takes key+mode from detect_key output, shows an explicit pipeline (detect_key → create_progression_from_key → create_harmonic_arrangement), and explains the style options. It does not explicitly name alternatives or state when-not-to-use, but the usage context is strong enough to guide an agent.

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

• mcp_opendaw_create_ratchetA
  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 transparency burden. It explains the generative behavior (repeated notes with changing subdivision), parameter effects (velocity decay, pitch drift), region handling ('-1 = auto-create/append'), and expected return fields. It lacks explicit disclosure about whether existing notes in the target region are preserved or replaced, but it goes beyond a basic create operation.

  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 well-structured: a one-line definition, then contextual background, then a parameter dictionary. It is relatively lengthy and includes some illustrative elaboration, but given the complexity (11 parameters, no schema descriptions), the length is justified and each section serves a purpose.

  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 complex tool with 11 parameters and no schema descriptions, the description provides comprehensive coverage: concept, use cases, parameter semantics, and return values. Minor details are omitted (e.g., exact exponential subdivision algorithm, interaction with existing region contents), but overall it is sufficiently complete for reliable 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 Args section must compensate, and it does thoroughly. Every one of the 11 parameters is given a meaningful definition with examples, ranges, and special values (e.g., max_subdivisions mapping 4=16th, region_index -1 semantics, subdivisions modes with arrows). 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.

  Purpose5/5

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

  The description begins with a specific verb-object pair: 'Create a ratchet — repeated notes with changing subdivision rate.' It further defines the term with examples (accelerando repeat, Bach ratchet) and scope (Baroque, electronic build-ups, drum fills), making it clearly distinct from other creation tools in the sibling set.

  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 musical context for when to use the tool ('Used extensively in Baroque music... electronic build-ups, and drum fills'), implying appropriate scenarios. However, it does not explicitly name alternative tools or state when not to use it, leaving the exclusion guidance implicit.

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

• mcp_opendaw_create_samba_patternA
  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 full burden. It discloses the tool's generative behavior in detail: it creates multi-instrument layered grooves, explains the role of each instrument, and describes style-specific pattern variations. It also states the return value ('Returns notes created, instrument breakdown, and pattern info'), which adds transparency. However, it does not mention potential side effects like overwriting existing notes or prerequisites such as requiring a valid note track.

  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 longer than average but well-structured into sections for instrument roles, styles, and parameter descriptions. The educational content about samba and the instruments is relevant and not filler, as it helps the agent understand the nuances of pattern generation. It could be slightly trimmed (e.g., the '300+ percussionists' note), but it remains focused and organized.

  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 complexity (11 parameters, 0% schema coverage, no annotations), the description is remarkably complete. It covers the tool's purpose, the musical context, instrument behaviors, style variants, all parameter meanings, and the return value. The presence of an output schema reduces the need to detail return structures, but the description still mentions what is returned, making it self-sufficient for an agent to select and invoke 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?

  Schema description coverage is 0%, but the description includes an 'Args' section that lists all 11 parameters with meaningful explanations, such as 'bars: Pattern length in bars (2-16, even)' and 'style: Samba style (batucada, samba_enredo, pagode, samba_funk)'. It also maps pitch parameters to MIDI note names, adding context beyond the raw schema. A couple of parameters like 'unit_index: AU index' are terse, but overall the description compensates well for the schema gap.

  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 'Create a Brazilian samba percussion ensemble pattern — multi-instrument layered groove', which is a specific verb + resource + qualifier. It further distinguishes itself from songo ('Unlike songo... samba is an ensemble'), clarifying that it creates multi-instrument patterns rather than a single drum-kit pattern, which differentiates it from sibling tools like create_songo_pattern.

  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 samba is an ensemble pattern and contrasts it with songo, implying this tool is for samba ensembles rather than single-drum patterns. It also enumerates four styles with detailed characteristics, guiding selection based on musical context. However, it does not explicitly name alternative tools or say 'use this when X instead of Y', 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.

• mcp_opendaw_create_soloA
  4.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 full burden of behavioral disclosure. It thoroughly explains what the tool generates (genre-specific solo line, techniques per style) and states the return value ('Returns notes created and solo characteristics'). However, it does not disclose potential side effects such as whether notes are appended to an existing region, whether existing notes are overwritten, or how track/unit selection affects placement. This is a moderate gap for a generation tool without annotations.

  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 extremely well-structured: it opens with a clear one-sentence purpose, uses a bulleted breakdown of genre techniques, lists parameters, and closes with examples. Every section earns its place for a complex music-generation tool. The length is justified, though slightly verbose for a single-tool description, hence not a perfect 5.

  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 10 parameters and no annotation support, the description is remarkably complete: it explains what the tool does, how it differs from siblings, defines all parameters, provides examples, and mentions the return type. However, it does not explicitly state prerequisites such as needing an existing chord progression or a selected track/unit, which are implied by the presence of track_index and unit_index. Given the schema and output schema exist, the description is strong but not fully exhaustive.

  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 itself has 0% description coverage, so the description is the sole source of parameter meaning. It compensates fully by defining each parameter inline (solo_type with its allowed values, key_root, scale_type, bars, octave, velocity, seed) and includes real usage examples. This adds significant semantic value beyond the raw schema fields.

  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: 'Create a genre-specific melodic solo over a chord progression.' It clearly distinguishes itself from siblings by explicitly naming generate_melody and create_random_walk and contrasting its genre-specific approach, making the tool's unique 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 Guidelines5/5

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

  The description provides explicit usage guidance: it states when to use this tool versus alternatives ('Unlike generate_melody... or create_random_walk... this tool uses genre-specific soloing techniques'). It also lists the five supported genres with detailed stylistic descriptions, giving the agent the necessary context to choose the right style and tool.

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

• mcp_opendaw_create_song_with_variationsA
  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 disclosure burden. It details what happens inside the tool: section variations, track exclusion, and that booleans trigger downstream calls (apply_genre_mix, apply_genre_humanization, add_mastering_chain). It does not explicitly state necessary project state or destructive behavior, but for a generative creation tool the stated behavior is largely 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 long but well-structured: purpose, differentiation, parameter format, default value, downstream flags, return value, and examples. The preset list earns its place because it is essential for correctly constructing the sections parameter. Information is front-loaded with the core purpose and alternative distinction.

  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 complex 12-parameter tool with no annotations, the description covers the central workflow, defaults, and expected returns. The presence of an output schema reduces the need to elaborate the return structure. Gaps remain for genre-specific required parameters and track/unit selections, but examples and detailed sections documentation make the tool usable for primary cases.

  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 must compensate. It thoroughly documents 'sections', including the spec format and all 14 presets, plus apply_mix/humanize/master. However, bpm, root, bass_track, drum_track, unit_index, melody_track, and harmony_track are left unexplained, leaving significant parameter semantics unresolved.

  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: 'Build a complete song with real musical variations between sections — one call.' It clearly distinguishes from sibling create_genre_sections by contrast ('Unlike create_genre_sections...') and states all 14 genres supported.

  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?

  Explicit guidance is provided: it tells when to use this tool over create_genre_sections, explains the sections format with preset options, includes defaults, and shows three practical examples for different genres. Pipeline order for apply_mix, apply_humanize, and apply_master is also specified.

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

• mcp_opendaw_create_soul_arrangementA
  4.4/5.0
  Behavior4/5

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

  Without annotations, the description takes on the burden of explaining effects. It details the exact musical output per track, the default BPM's effect, and the constraint that bars must be a multiple of 4. It also states the return value ('Returns notes created per track and total'). However, it does not specify whether notes are appended or overwrite existing notes on the target tracks, which is a notable omission.

  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: a one-sentence summary, followed by per-track breakdown, stylistic rationale, parameter list, return value, and usage examples. While lengthy, every section adds useful information and the structure aids scanning.

  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 complexity (4 tracks, 11 parameters), the description is largely complete: it covers most parameters, provides musical character, constraints, and examples. Gaps include the undocumented velocity and start_beat parameters and lack of detail on whether existing track content is preserved or replaced, preventing a perfect score.

  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?

  Despite the schema having zero parameter descriptions, the tool description compensates well: it explains bpm with a range and default, bars with a validity constraint, octave with MIDI note mapping, root with a suggested key, and the track parameters with their roles. It fails to mention the velocity and start_beat parameters, leaving those to defaults without explanation.

  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 'Create a full soul arrangement — gospel drums + melodic bass + Rhodes chords + horn stabs across 4 tracks,' which clearly identifies the tool's function and distinguishes it from genre siblings by specifying the genre and instrumentation. It further lists each track's role, leaving no ambiguity about what the 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 Guidelines4/5

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

  The description provides clear stylistic context by naming Motown/Stax/Atlantic soul and specific artists, and explicitly contrasts soul with funk and pop ('The I-IV-vi-V progression is the gospel quartet influence that separates soul from funk...'). It does not name alternative tools directly, but the genre distinction implicitly guides when to use this tool versus other arrangement creators.

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

• mcp_opendaw_create_stabA
  4.4/5.0
  Behavior4/5

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

  With no annotations, the description discloses key behaviors: how rhythm characters are interpreted ('x' triggers a stab, '.' is a ghost/light stab), how chords cycle, that velocity is halved for ghosts, and that it returns notes, voicings, and rhythm hits. It stops short of detailing edge cases or whether it overwrites existing notes, but covers the core behavior.

  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 one-sentence summary, followed by use cases and parameter detail. Each sentence adds value; the parameter explanations are thorough. It's longer than average but justified for 9 parameters, though the genre list could be trimmed.

  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 tool with no annotations and 0% schema description coverage, the description covers all parameters, provides examples, and notes the return value. It's practical and complete for agent invocation, though it doesn't address error handling or invalid input 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?

  Schema description coverage is 0%, yet the description explains every parameter with formats, examples, ranges, and defaults. For instance, chords includes root names and chord types, rhythm includes grid notation and examples, and octave/velocity/stab_duration have explicit ranges. This fully compensates for the sparse 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+resource: 'Create rhythmic stabs — short chord jabs' and elaborates with 'Generates short chord hits on a rhythmic grid.' This clearly distinguishes it from sibling creation tools (e.g., create_chop, create_chorale) by focusing on stabs and their musical 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?

  The 'Perfect for' list gives explicit musical contexts (house/disco off-beat stabs, funk syncopation, garage/shuffle, filling gaps between melody notes), signaling when to use this tool. It doesn't explicitly name alternative tools, but the contexts are 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.

• mcp_opendaw_delete_signature_changeA
  4.4/5.0
  Behavior4/5

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

  The destructiveHint annotation already indicates mutability. The description adds useful context by explaining that deletion matches the closest event to the given position and that it returns the updated signature event list. It does not disclose undo options but provides enough behavior beyond the annotation for an agent to understand the deletion semantics.

  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 concise and front-loaded with the primary purpose. It uses bullet-like line breaks for parameter details. There is slight redundancy between the opening lines and the parameter descriptions, but overall it is efficient and well-organized.

  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, the presence of an output schema, and the destructiveHint annotation, the description adequately covers the essential usage. It explains the two deletion modes, the return value, and special last-event handling. It does not specify behaviors like no-match handling, but those are secondary given the output schema.

  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 explaining both parameters: position_beats is the position to match with closest-event deletion, and index is the 0-based index in sorted order with -1 used for position matching. The special combination for deleting the last event is also clarified, leaving no ambiguity.

  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 'Delete a time signature change from the timeline' which is a specific verb+resource. It distinguishes from sibling tools like add_signature_change, list_signature_changes, and move_signature_event because the delete action is unambiguous and unique 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?

  The description provides clear guidance on how to invoke the tool: delete by position or index, and explains the special case of passing index=-1 and position_beats=-1 to delete the last event. However, it does not explicitly mention when to use this tool versus alternatives like move_signature_event, 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.

• mcp_opendaw_delete_trackA
  4.4/5.0
  Behavior4/5

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

  Beyond the destructiveHint annotation, the description discloses the concrete behavioral outcome: 'Removes all regions, clips, and notes on that track.' This adds valuable context about the destructive scope. It also mentions 'Returns success or error' which is basic but useful. It does not cover undo behavior or side effects on sends/routing, but given the annotation, the bar is lower and the provided information 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 three tightly written sentences: purpose, side effects, and parameter definitions. No redundant or irrelevant content. The parameter list is clearly formatted and every sentence earns its place. This is an appropriately sized and well-structured 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 simple two-parameter deletion tool, the description covers purpose, side effects, and parameter meanings. The destructiveHint annotation and output schema reduce the need to explain safety or return formats. It could additionally clarify that indices refer to current state or that deletion is permanent, but overall it is sufficient for effective 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?

  The description explicitly defines both parameters: 'unit_index: Audio unit index' and 'track_index: Track index within the unit.' Since the input schema has no descriptions (coverage 0%), this parameter guidance compensates well. It could have added detail about indexing conventions (e.g., zero-based) or how to resolve indices, but the basic semantics are clear.

  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 'Delete a track from an audio unit' with a specific verb and resource, and clarifies the scope by noting it 'Removes all regions, clips, and notes on that track.' This distinguishes it from sibling tools like delete_audio_unit (whole unit) and delete_region (individual content). The purpose is unambiguous and well-scoped.

  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 need to delete an entire track and all its contained data. It does not explicitly name alternatives or exclusion cases, but the context is clear enough that an agent can infer this is for track-level deletion rather than unit-level or region-level operations.

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

• mcp_opendaw_delete_warp_markerA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare destructiveHint=true. The description adds useful behavioral details beyond that: which markers are protected (anchor markers) and the return value ('Returns remaining marker count'). This gives the agent important expectations about side effects and results.

  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 one-line purpose, a crucial constraint sentence, a parameter list, and a return statement. Every sentence serves a purpose 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?

  The description covers all essential aspects for invocation: purpose, parameter semantics, a key limitation, and return value. It doesn't explain what a warp marker is in detail, but that is likely domain knowledge. The destructive hint is already annotated, and the description complements it with the anchor restriction. It is nearly complete for safe 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 description must explain the parameters. It does: 'unit_index: AU index. track_index: Track index within the AU. region_index: Audio region index. marker_index: Warp marker index (0-based, from list_warp_markers).' This adds clarity beyond the bare titles, including the 0-based index and provenance of marker_index.

  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 verb and resource: 'Delete a warp marker from a time-stretched or pitch-stretched audio region.' It distinguishes from the generic delete_marker tool by specifying 'warp marker' and the context of time/pitch-stretched regions.

  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 a key usage constraint: 'Cannot delete anchor markers (first and last) — they pin the audio mapping.' This tells the agent when not to use the tool. Also implies a workflow by noting the marker_index comes 'from list_warp_markers', suggesting listing first. However, no explicit alternative tools are named.

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

• mcp_opendaw_duplicate_notesA
  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 the exact shift calculation, notes that it creates copies, and states the return value. This is solid, though it could mention side effects on existing notes or whether the operation is reversible.

  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-line summary, then the algorithm, then parameter explanations, and finally the return note. No unnecessary 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 3-parameter tool with an output schema, the description adequately covers the operation, parameter meanings, and return values. It could include more detail about track_index base (e.g., whether it is 0-based), but overall it is sufficiently 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 description coverage is 0%, but the description compensates by explaining each parameter: unit_index supports -1 for searching all AUs, and region_index is 0-based. This adds meaning beyond the bare integer 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 the tool's action: 'Duplicate all notes within a region, shifting them after the last note.' It uses a specific verb (duplicate), identifies the resource (notes within a region), and explains the shift behavior. This differentiates it from siblings like duplicate_region and duplicate_note_event.

  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 context by stating it 'mirrors the DAW's native duplicate notes feature,' which implies when to use it. However, it does not explicitly mention alternatives or when not to use this tool, 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.

• mcp_opendaw_export_single_stemA
  4.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 full burden. It discloses that the effect chain is applied, requires unit_index > 0 and not the output AU, and notes it's faster than batch export. However, it does not mention whether the operation modifies the project, writes to disk, or requires the engine to be running, leaving some behavioral ambiguity for a safe deployment.

  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: purpose, comparison, then parameter list. Every sentence adds value, 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?

  Given the moderate complexity and absence of annotations, the description covers core functionality, usage context, and parameter constraints. It could mention prerequisites like engine state or file path, but the presence of an output schema and clear export semantics make it 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 has no descriptions, but the description explains all three parameters. unit_index gets a critical constraint (>0, not the output AU), while filename and sample_rate are clarified as output filename and export sample rate. This compensates for the 0% schema coverage, though the last two are somewhat terse.

  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 'Export a single audio unit as a stem WAV with its effect chain applied,' which gives a specific verb, resource, and output format. It also explicitly distinguishes from export_stems, making the purpose clear and unambiguous.

  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 provides explicit guidance: 'Unlike export_stems (which exports ALL stems in one pass), this exports just one AU — faster when you only need a specific stem.' This tells the agent exactly when to use this tool versus the alternative, satisfying the when and alternative requirements.

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

• mcp_opendaw_get_automation_valueA
  4.4/5.0
  Behavior4/5

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

  The readOnlyHint annotation already flags this as read-only. The description adds valuable behavioral context beyond this: it resolves the curve value accounting for interpolation and region loops, returns a normalized 0.0-1.0 value, and may return an error. This is meaningful supplemental transparency, though it could be slightly more specific about error conditions or edge cases (e.g., no automation at position).

  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 short behavioral note, a parameter list, and a return statement. Every sentence contributes useful information, and the most important content is front-loaded. No fluff or repetition that detracts.

  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 complexity (interpolation, loops, overlapping regions, normalized output), the description covers the core behavior and return contract. It lists all parameters and notes the possible error. It does not explain the meaning of 'AU' or elaborate on error specifics, but for a read-only getter with an output schema, this is adequately 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 has 0% description coverage, so the description must compensate. It does so by naming each parameter and providing a brief semantic role: 'unit_index: AU index', 'track_index: Value (automation) track index within the AU', 'position_beats: Position in beats (float).' This adds meaning beyond the raw schema, though it is brief and assumes domain knowledge of 'AU'.

  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 clear, specific statement: 'Get the automation value at a specific position on a value (automation) track.' It uses a distinct verb ('Get') and resource, and the elaboration about resolving curves with interpolation, loops, and overlapping regions distinguishes it clearly from siblings like list_automation_events or set_automation_interpolation.

  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 you need the resolved automation value at a point rather than event data. It provides context about how the resolution works (interpolation, loops, overlapping regions), but does not explicitly name alternatives or state when not to use it. This is a clear context with no exclusions, matching a 4.

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

• mcp_opendaw_get_effect_stateA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description reinforces this by using 'Get full state' and 'Returns complete effect state snapshot.' It adds behavioral context by listing exactly what is included (enabled/bypass, minimized, sidechain, parameters) and the semantics of the two indexes, going beyond the annotation's minimal safety hint.

  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 concise, with a clear lead sentence, a comparative note, parameter explanations, and a closing return statement. It is well-structured and avoids unnecessary elaboration, though the final 'Returns complete effect state snapshot' largely restates the opening sentence.

  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 read-only tool with two integer parameters and an output schema, the description covers all necessary context: purpose, tool differentiation, parameter semantics, and return content. Since an output schema exists, the description need not detail return values further, making this a complete package.

  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 compensate, and it does by explaining unit_index as 'Audio unit index' and effect_index as 'Effect position in the chain (0-based).' This adds meaningful clarification for both parameters, especially the 0-based positioning detail, which is not evident from the schema titles alone.

  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 retrieves the full state of an effect, enumerating the included fields (enabled, minimized, sidechain, parameters). It explicitly distinguishes itself from the sibling list_effect_parameters by being more detailed, 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 provides a clear comparison with list_effect_parameters, noting this tool is 'more detailed' and includes bypass state, minimized state, sidechain, and a full parameter dump. It implies when this tool is preferred over its lighter sibling, though it does not explicitly state a conditional when-not scenario.

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

• mcp_opendaw_get_region_play_modeA
  4.4/5.0
  Behavior4/5

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

  With readOnlyHint=true already present in annotations, the description adds meaningful behavioral context by disclosing the fallback behavior ('or info if no stretch mode (plain playback)') and enumerating the returned fields. This goes beyond the annotation's simple safety hint.

  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, a bullet-like list of parameter definitions, and a return-behavior sentence. Every sentence earns its place with no 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 simple read-only getter with three integer parameters and an output schema present, the description covers purpose, parameter semantics, and return behavior including the edge case of no stretch mode. No critical information 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.

  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 defining all three parameters (unit_index, track_index, region_index) with clear hierarchical context (AU, track within AU, audio region). This adds substantial meaning beyond the bare integer type in 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 uses a specific verb ('Get') and resource ('play mode of an audio region'), and explicitly lists the returned fields (stretch type, playback rate, cents, transient mode). This clearly distinguishes it from sibling getter tools like get_region_info or get_track_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 its usage by naming the resource and parameters, but provides no explicit guidance on when to prefer this tool over alternatives, nor any exclusions or prerequisite conditions. Usage context is inferred rather than stated.

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

• mcp_opendaw_import_presetA
  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 that the tool deserializes the preset into the current project and creates a new AU with instruments, effects, MIDI effects, tracks, and notes, which is a key side effect. It also mentions return value or error, providing transparency about outcomes.

  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 concise and front-loaded with the main purpose. Each sentence adds useful information, though 'Uses PresetDecoder.decode' is an implementation detail that could be omitted. Overall, it is well-structured and not overly verbose.

  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 complexity and lack of annotations, the description covers the main aspects: purpose, side effects, parameter source, and return value. It doesn't cover potential error scenarios in depth, but 'or error' is noted. An output schema exists, so return structure is handled separately.

  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 compensate. It fully describes the parameter: 'preset_b64: Base64-encoded preset bytes from export_preset.' This explains the format, content, and source, making the parameter meaning clear.

  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 a preset (base64-encoded binary) as a new audio unit.' It specifies the resource (preset) and the result (new audio unit), and distinguishes from siblings like 'replace_from_preset' by emphasizing 'new'.

  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 says the preset_b64 comes from export_preset and that it creates a new AU with dependencies. While it doesn't explicitly name alternatives or exclusions, the context is sufficient to infer when to use it (e.g., not for replacing existing units).

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

• mcp_opendaw_invert_chord_notesA
  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. It transparently describes the mechanics: finds notes at a beat position, groups them as a chord, and moves bottom/top notes by an octave. It also discloses the return format. However, it does not address edge cases (e.g., what happens if no chord is detected) or explicitly state that the operation modifies the region, though this is implied.

  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 well-structured with a summary, a theoretical explanation, an Args section, and a Returns section. It is somewhat verbose due to the music-theory paragraph, but each section serves a purpose and the content is not redundant. It earns its length without being bloated.

  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 the core transformation, all parameters, and the return JSON fields (notes_inverted, original/new pitches, chord root). It is reasonably complete for a tool of this complexity, though it lacks explicit edge-case behavior (e.g., handling no notes at the position, mono vs. polyphonic detection, or interaction with other regions). An output schema exists, so return details are partly redundant, but the description still adds value.

  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. The 'Args' section provides detailed meanings for all six parameters, including examples for inversion (1, 2, 3) and direction ('up'/'down'). This fully bridges the gap left by the schema, making parameter semantics exceptionally clear.

  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: 'Invert a chord at a specific position — move bottom N notes up an octave (or top N down).' This clearly states the verb, resource, and scope. It also distinguishes itself from sibling tools like invert_notes by specifying chord inversion (voicing change) versus melodic inversion.

  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 context for when the tool is used (to change chord voicing by moving notes up/down an octave) but does not explicitly mention alternatives or exclusions, such as using invert_notes for melodic inversion. The musical explanation implies the use case but stops short of contrasting with other tools.

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

• mcp_opendaw_invert_notesA
  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 provides the transformation formula, an example, and states that out-of-MIDI-range notes are skipped, plus what the return value contains (count of notes inverted and skipped). It implies the mutation of notes through 'each note's pitch is reflected' but does not explicitly state that notes are permanently modified in the project, though this is evident from the 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 well-structured: a one-line summary, the mathematical formula, a concrete example, parameter definitions, and return information. Every sentence earns its place; there is no filler or redundancy, and the example clarifies the transformation in an efficient way.

  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 complexity (4 parameters, transformation with edge cases) and the presence of an output schema, the description covers the essential aspects: what it does, how to specify targets, default behavior, and return info. It lacks explicit prerequisites (e.g., requiring a note track to exist) but that is a generic assumption in this DAW context. Overall, it is a complete and self-sufficient description for an agent to select and invoke 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?

  Schema description coverage is 0%, so the description must fully clarify parameters. It does so for all four: unit_index (AU index), track_index (Note track index), region_index (Region index, -1 = all regions), and axis (Pivot pitch, default 60, with usage tip). The term 'AU index' is terse/domain-specific, but overall the description adds significant meaning beyond the schema's bare property names.

  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: 'Invert melody around a pitch axis — mirror reflection.' It clearly distinguishes from sibling tools like transpose_notes (pitch shift by interval) and rotate_notes (circular rotation) by defining the exact mathematical operation (newPitch = 2*axis - oldPitch) with a concrete example. The scope 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?

  The description thoroughly explains the operation and parameter semantics, including defaults and the region_index=-1 special case for 'all regions on the track.' However, it does not explicitly contrast this tool with alternatives (e.g., transpose_notes) for when a user would want mirror inversion versus a simple transposition, so the guidance is clear but not explicitly exclusive.

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

• mcp_opendaw_list_audio_regionsA
  4.4/5.0
  Behavior3/5

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

  The readOnlyHint annotation already signals that this is a safe, non-mutating operation. The description aligns with this ('List') without adding additional behavioral context such as error conditions, sorting, or limits. Since annotations cover the safety profile, a middle score is appropriate, but the description doesn't enrich behavioral transparency beyond the annotation.

  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, followed by parameter definitions and a clear list of return fields. No filler words or redundant information. 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 read-only list operation, this description is complete. It covers the purpose, parameters (including the sentinel value), and return fields, giving the agent everything needed to invoke the tool and interpret the results. The low complexity and presence of an output schema further reduce the need for additional context. No significant 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 provides no descriptions for the parameters (0% coverage), so the description carries the full burden. It clearly explains both unit_index and track_index, and crucially documents the special value '-1' for track_index meaning 'all tracks'. This adds significant meaning beyond the bare schema names and 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 begins with a clear, specific verb and resource: 'List all audio regions with file name, position, and duration.' It distinguishes itself from sibling list tools (e.g., list_note_regions) by explicitly targeting audio regions and describing the relevant fields. 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?

  The description provides clear context for when to use this tool: when you need to list audio regions. It also clarifies parameter usage, especially the sentinel value '-1' for track_index to target all audio tracks. However, it doesn't explicitly mention alternatives or when-not-to-use conditions, so it falls slightly 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.

• mcp_opendaw_list_clipsA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true. The description adds behavioral detail: clip types (NoteClipBox, AudioClipBox, ValueClipBox), their fields, storage location (TrackBox.clips), and track_index=-1 semantics. This goes beyond the annotation's safety flag.

  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?

  Structured with a one-line purpose, bullet-pointed clip types, and short parameter/return lines. No filler; each section adds necessary context.

  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 read-only list tool with output schema, the description covers purpose, parameters, and return fields. It lacks error handling or ordering details, but these aren't critical for a listing 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?

  Schema has only titles with 0% coverage. Description explains unit_index as 'Audio unit index' and track_index as 'Track index (-1 = all tracks on the unit)', providing the special sentinel value. This is essential context 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?

  Description opens with 'List clips (session view / clip launcher) on tracks' — a specific verb+resource. It distinguishes from arrangement-region tools by explicitly scoping to session view/clip launcher. The three clip types further clarify what 'clip' means.

  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 context that clips live on TrackBox.clips and explains track_index=-1 means all tracks, but it doesn't explicitly state when to prefer this tool over list_tracks or list_audio_regions. The session-view scoping implicitly tells the agent when to use it.

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

• mcp_opendaw_list_midi_effect_paramsA
  4.4/5.0
  Behavior4/5

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

  Annotations include readOnlyHint: true, which already signals a safe read operation. The description adds behavioral detail by stating it returns 'parameter names, values, units, and constraints' and specifies that values are current. It does not contradict the annotations and provides useful output expectations beyond the structured data.

  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. It adds parameter explanations and a one-line return summary, all in four short lines. No unnecessary words 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 two-parameter read-only tool with an output schema, the description covers the essential usage and return semantics. It does not discuss error cases or prerequisites, but the simplicity of the operation and the existing readOnlyHint annotation make that 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?

  Schema coverage is 0% and the description compensates by explaining both parameters: 'unit_index: Audio unit index' and 'effect_index: MIDI effect position in the chain (0-based).' The effect_index explanation is especially clear, though unit_index could be slightly more precise about what 'audio unit' refers to.

  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 begins with a specific verb and resource: 'List all parameters of a MIDI effect with current values.' This clearly distinguishes the tool from siblings like list_midi_effects or list_effect_parameters by specifying it targets MIDI effect parameters, not the effects themselves.

  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 the tool: when you need parameter names, values, units, and constraints for a MIDI effect. It also explains the parameters needed to target the correct effect. However, it does not explicitly mention alternatives or provide exclusion criteria, 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.

• mcp_opendaw_modulate_progressionA
  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 that chord qualities are preserved, direction affects octave placement, and the return value includes a per-chord mapping. This goes beyond a basic definition, though it does not explicitly state side-effect behavior (e.g., whether the project is modified).

  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 well-structured with a lead sentence, explanatory paragraph, common modulation list, parameter docs, and examples. It is somewhat lengthy, but each section adds useful information; no wasted sentences.

  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 what the tool does, how to invoke it, common use cases, and what it returns. An output schema exists, so detailed return format is not required. It could mention edge cases or errors, but overall it is sufficient for selection and 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 has 0% description coverage, but the tool description fully documents all three parameters with examples (progression, target_key, direction) and notes the default for direction. This compensates entirely 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 opens with a specific verb+resource: 'Transpose a chord progression to a new key.' It clearly distinguishes this tool from siblings like reharmonize_progression or transpose_notes by emphasizing preservation of chord qualities and interval relationships. The scope 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?

  The description provides clear context with 'Common modulations' and musical scenarios (chorus, bridge, mood shifts), and example invocations. However, it does not explicitly mention when not to use this tool or name alternative tools, so it lacks explicit exclusions.

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

• mcp_opendaw_quantize_notesA
  4.4/5.0
  Behavior3/5

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

  The description discloses the core behavior—snapping start positions to the nearest grid line—and how strength affects the result. However, it does not mention potential destructiveness, undo behavior, or whether note durations are affected. Since no annotations are provided, the description carries the burden of behavioral disclosure; the missing details on side effects leave 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.

  Conciseness5/5

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

  The description is concise and well-structured: a one-line summary, a brief behavioral clarification, parameter definitions, and a return-value note. Each line adds distinct value with no redundancy or fluff. It is front-loaded with the primary purpose, making it easy to scan.

  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 moderate-complexity operation with four required parameters and an output schema, the description covers all necessary aspects: what it does, how parameters behave, and what is returned. The parameter ranges and defaults are explicit, and the output count is stated. No significant contextual 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?

  Schema description coverage is 0%, so the description is the only source of parameter meaning. It thoroughly explains all four parameters, including the allowed division values, the sentinel meanings for unit_index and track_index (-1 = all), and the strength value semantics. This fully compensates for the bare 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 opens with a specific verb and resource: 'Quantize note positions to a grid division.' It clearly states what the tool does and distinguishes it from related note-manipulation tools like humanize_notes or rotate_notes by specifying the grid-snapping action. The return value is also disclosed, completing the purpose.

  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 the use case clear: aligning note start positions to a grid with optional partial strength. It explains the meaning of each parameter and the range for strength, providing enough context for an agent to decide when this tool is appropriate. It does not explicitly discuss exclusions or alternatives, but the operation is well-defined.

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

• mcp_opendaw_quantize_velocitiesA
  4.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 full burden. It explains the modes and return stats, but it does not disclose whether the operation modifies notes in place, is reversible, or requires a specific state (e.g., undo support). It describes 'snap' behavior well but lacks broader side-effect 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 well-structured with a headline, explanatory paragraphs, an Args list, and a Returns section. It is longer due to the need to explain 7 parameters and 4 modes, but every sentence provides value and it is front-loaded with the core purpose. No fluff.

  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 complexity (7 params, no annotations), the description is complete: it covers purpose, use cases, all parameters with examples, and return value shape. It even references how to obtain unit_index ('from list_tracks'), aiding invocation. The presence of an output schema means return values are also formally defined, but the description adds meaningful 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 thoroughly. It explains every parameter in the Args section, including meaningful defaults and examples (e.g., 'levels: 2 = on/off, 4 = pp/p/mf/f, 8 = classical dynamics'), and clarifies how mode values behave. This goes far 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 clearly states the action ('Quantize note velocities to discrete stepped levels') and the resource ('note velocities'). It distinguishes itself from siblings by describing the specific mechanism (snapping to N evenly-spaced levels) and provides relevant musical context ('like MPC 16-level mode').

  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 use cases: 'Great for creating uniform, robotic feel (techno, industrial) or restoring clean velocity tiers from humanized performance data.' However, it does not mention alternative tools (e.g., scale_velocity, humanize_notes) or when not to use it, so it lacks direct exclusion or alternative guidance.

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

• mcp_opendaw_render_and_analyzeA
  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 and provides good insight: it renders to WAV via offline engine, runs full analysis (LUFS, spectrum, stereo, dynamics), and returns concrete numbers plus prioritized suggestions. It also explains the difference between 'full' and 'quick' analysis depth. However, it omits potential side effects like file overwrites or timing considerations.

  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 well-structured with a clear opening, numbered steps, and an example. It front-loads the purpose and remains focused. There is slight redundancy ('feedback loop' and 'After making mix changes, call this to verify' overlap), preventing a perfect score.

  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 combined render+analyze tool, the description covers what it does, when to use it, all parameters, and the return structure (analysis JSON with mix_suggestions, master_check, file path). It could mention where the WAV file is saved or whether it overwrites existing files, but it is largely complete for agent 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%, but the description fully explains all three parameters: filename (output filename without .wav extension), sample_rate (48000 recommended), and analysis_depth ('full' vs 'quick' with exact meanings). This far exceeds the bare schema and makes parameter choice unambiguous.

  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's verb+resource: 'Render the current project and run full audio analysis in one call.' It distinguishes itself by explicitly saying it combines export_audio + analyze_mix and positions itself as the 'ears' tool for iterative mixing, setting it apart from sibling analysis/rendering 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 provides clear when-to-use guidance: 'After making mix changes, call this to verify' and frames it as the feedback loop for iterative mixing. It does not explicitly state when not to use it or name alternative tools beyond mentioning it combines two others, so a 4 is appropriate.

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

• mcp_opendaw_render_full_songA
  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 disclosure burden and does explain the rendering algorithm (scans all note/audio regions, finds the latest ending point, renders from beat 0 plus a configurable tail) and the return payload (WAV path, duration, peak, has_audio). It stops short of disclosing operational traits like whether the output file overwrites existing files or whether the audio engine must be running.

  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 well-structured and front-loaded: lead purpose statement, algorithm detail, pipeline context, parameter list, return list, and two compact examples. There is slight redundancy between 'auto-detects song length from all regions' and the following sentence that re-describes the scanning, but nothing is wasted or off-topic.

  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 that all parameters are optional, an output schema exists, and this is a simple render operation, the description covers everything needed for correct invocation: purpose, algorithm, parameters, returns, and a pipeline example. Its main gap is not explicitly distinguishing the closely named siblings render_full and render_full_format, which could cause selection confusion among the large sibling set.

  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, so the inline parameter documentation is essential and fully compensates: filename (specified without .wav extension), sample_rate (export rate, default 48000), and tail_beats (extra beats for reverb/delay tails, default 4 = 1 bar). The two examples further demonstrate parameter usage, making all three parameters clear 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?

  The description opens with 'Render the entire project — auto-detects song length from all regions,' which states a specific verb (render), resource (entire project), and a distinguishing scope (auto-detection across all regions). This clearly differentiates it from nearby siblings like render_range and export_mix, which target specific ranges or export formats rather than full-project rendering.

  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?

  Usage context is explicit: 'after create_song_with_variations (or any arrangement tool), call render_full_song to get the final WAV,' and the phrase 'No manual beat counting needed' implies an advantage over range-based alternatives. However, it never names direct alternatives (render_range, render_full, export_stems) or states when NOT to use this tool, so exclusion conditions are absent.

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

• mcp_opendaw_rotate_notesA
  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 disclosure. It thoroughly explains the cyclic shift mechanics, wrap-around behavior, axis semantics, and preserve_pitch_contour effect. It falls short of mentioning whether other note properties (velocity, duration) are preserved or if the operation is reversible, which would be valuable context.

  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 well-structured with a clear opening sentence, a detailed shift explanation, a brief musical context paragraph, and an organized Args section. While moderately long, each section adds value and the content is front-loaded with the core purpose.

  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 complexity (6 parameters, no annotations), the description covers the core operation, parameters, and usage contexts comprehensively. It does not address edge cases like empty regions or prerequisites, but overall it provides enough for an agent to decide when and how to invoke the 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?

  The input schema has zero description coverage (only bare titles), so the description must—and does—compensate fully. Every parameter (unit_index, track_index, region_index, rotate_by, axis, preserve_pitch_contour) is explained with meaningful details, including defaults, direction semantics, and the three axis options.

  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, actionable statement: 'Rotate notes in a region by N positions (cyclic shift).' This clearly identifies the action, resource, and transformation type, distinguishing it from sibling tools like reverse_notes, invert_notes, or transpose_notes.

  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 by mentioning compositional techniques (serialism, jazz melodic variation, electronic music pattern transformation), implying when this tool is appropriate. However, it does not explicitly state when not to use it or offer comparisons to alternatives like reverse or invert.

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

• mcp_opendaw_set_audio_region_fadeA
  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 and does well by explaining the Fading object's parameter semantics, the -1 skip behavior to preserve current values, and that the tool returns updated fade values. It does not disclose error behavior for invalid indices or edge cases like setting a slope without a duration, but adds substantial context beyond the bare operation.

  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 well-structured: a one-line summary, conceptual explanation of fades and slopes, the skip rule, a per-parameter reference, and a return note. There is minor redundancy between the Fading object explanation and the parameter list, but every section serves a purpose and the length is justified by the 7-parameter complexity.

  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 unannotated, 7-parameter mutation tool, this description covers the purpose, all parameter meanings, the do-not-change sentinel (-1), and the return value. The main gaps are lack of error handling details and explicit interaction with related tools, but the core usage is fully and clearly explained.

  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 compensates excellently. It lists every parameter with units (seconds for fades), ranges (0-1 for slopes), and the -1 skip rule, and it maps the conceptual Fading fields (in, out, inSlope, outSlope) to the actual parameter names, adding meaning far beyond the schema's bare type 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 'Set fade in/out on an audio region,' a precise verb+resource statement that clearly identifies the tool's function. It then elaborates on the Fading object and its four parameters, distinguishing it from sibling tools like set_audio_region_gain and copy_region_fades.

  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 detailed explanation of fade durations, slopes, and the -1 skip mechanism provides clear context for when to use this tool: when adjusting an audio region's fades. However, it does not explicitly mention alternatives or exclusions, such as when to prefer copy_region_fades for copying existing fade settings.

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

• mcp_opendaw_set_crusher_crushA
  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 takes on the full burden. It discloses the inverted internal scaling (0.0=clean, 1.0=inaudible) and maps specific values to audible characteristics (AM radio, glitchy), which is genuinely useful behavioral context beyond merely saying 'set a parameter.' It stops short of describing error behavior for non-Crusher effects or out-of-range values, but the provided mapping 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 efficiently structured in two paragraphs: first the purpose, then the parameter details. Every sentence provides factual value—the frequency mapping is dense but necessary. No filler, and the formatting (bulleted parameter list) aids scanning.

  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 parameter setter, the description covers purpose, parameter semantics, and critical behavioral nuance (inversion). An output schema exists, so return-value details are not required. The description also flags the key prerequisite that the effect must be a Crusher. It is complete for this tool's complexity.

  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 compensate. It fully explains all three parameters: unit_index as AU index, effect_index as effect index in the chain (with the Crusher constraint), and crush with range and meaning (0-1, 0=clean, 1=max destruction). This adds significant value beyond the schema's bare titles.

  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+resource: 'Set the sample-rate reduction (crush) on a Crusher effect.' This clearly differentiates from siblings like set_crusher_bits, which targets bit depth rather than sample-rate reduction. The scope 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?

  Usage context is implied: the tool is for adjusting crush on a Crusher effect, and the description notes that effect_index 'must be a Crusher,' providing a prerequisite. However, it does not explicitly state when to prefer this over alternatives like set_crusher_bits or generic set_effect_parameter, 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.

• mcp_opendaw_set_midi_effect_paramA
  4.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 burden of behavioral disclosure. It communicates mutation through 'Set' and mentions that old and new values are returned, but it does not clarify precedence when both param_name and param_index are supplied or error behavior, leaving minor 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?

  The purpose is front-loaded in a single sentence, followed by one line per parameter and a final return-value note. There is no fluff or redundant restatement of schema types.

  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 five-parameter setter with an output schema, the description covers identification (unit_index, effect_index), selection (param_name or param_index), value type (number), and return values. It provides sufficient context to invoke the tool correctly without needing the output schema details.

  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 documents every one of the five parameters, including examples for param_name ('semiTones', 'rateIndex', 'gate') and the sentinel behavior of param_index (-1 = use name). 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.

  Purpose5/5

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

  The description immediately states a specific action ('Set a parameter on a MIDI effect'), and the parameter list clarifies that this targets MIDI effect chains. This distinguishes it from sibling tools like set_effect_parameter and set_instrument_param by resource type.

  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 opening line gives clear context: use this tool when you need to set a parameter on a MIDI effect, identified by unit_index and effect_index. It does not explicitly name alternatives or exclusion cases, but the MIDI-effect scoping is enough to guide tool selection among many similar setters.

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

• mcp_opendaw_set_note_advancedA
  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 full burden. It explains the skip sentinel values (-1 or -999), gives value ranges for each property, and states the return behavior ('Returns updated values, or error'). This is substantial behavioral disclosure, though it doesn't mention side effects like in-place mutation explicitly.

  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 well-structured with a clear definition followed by bullet-point property details and a concise note on skipping. It is not overly verbose, though the index parameter list adds a few lines that could be merged. Overall efficient and easy to scan.

  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 8 parameters but the description covers all of them to some degree, including required index paths and optional advanced properties with sentinel behavior. It also mentions the output ('updated values, or error'), and with an output schema present, that suffices. There are no major gaps 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?

  Schema description coverage is 0%, so the description must compensate. It does so by explaining the four main properties with ranges and meanings, and identifies the four index parameters (unit, track, region, note). The index explanations are terse ('AU index') but sufficient given the parameter names.

  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 ('Set') and resource ('advanced note properties'), explicitly enumerating the four properties (chance, cent, playCount, playCurve). It distinguishes itself from basic note property tools by stating these are 'beyond basic position/duration/pitch/velocity', making its purpose clear and unique among 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?

  The description implies usage for advanced note properties and clarifies that basic properties are handled elsewhere ('These properties are beyond basic...'). It does not explicitly name alternatives like set_note_properties, but the scope 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.

• mcp_opendaw_set_piano_time_rangeA
  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 clearly states that the tool returns 'success with old and new values' and explains the practical meaning of the parameter, providing helpful transparency 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?

  The description is compact and front-loaded, with three clear sentences: purpose, parameter semantics, and return behavior. Every sentence adds value and there is no redundancy with the schema.

  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 setter with an output schema, the description covers purpose, parameter meaning, valid range, and return behavior. It is complete enough for an agent to select and invoke the tool correctly without additional clarification.

  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 provides zero description coverage, but the description compensates fully by documenting the parameter's unit ('quarter notes'), valid range ('1.0 to 64.0'), and behavioral effect ('Smaller = more zoomed in'). This is excellent parameter-level guidance.

  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: 'Set the piano roll time range' with a clarifying parenthetical 'horizontal view width in quarter notes'. This precisely differentiates it from sibling piano tools like set_piano_keyboard or set_piano_note_scale.

  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 by explaining the parameter's effect ('Smaller = more zoomed in'), but it does not explicitly state when to use it versus alternatives or mention any exclusions. Usage context is present but implicit.

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

• mcp_opendaw_start_engineA
  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 of disclosure. It adds a key behavioral insight: 'The engine serializes the current project state into the AudioWorklet processor, so all boxes must exist first.' This explains why order matters and warns about prerequisites, though it doesn't cover idempotency 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.

  Conciseness5/5

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

  The description is two short paragraphs, front-loaded with the main action and key constraints. Every sentence adds value: the first states what it does, the second explains when and why. 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 tool, the description adequately covers the essential context: sequencing, prerequisites, and the serialization behavior. An output schema exists, so return-value explanation is not needed. Minor gaps like error handling or repeated calls are not critical given the 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 input schema has zero parameters, so there is nothing to document. The description correctly avoids adding parameter details, and the baseline for 0-param tools 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 clearly states 'Start the audio engine (AudioWorklet)' with a specific verb and resource. It distinguishes itself from sibling engine tools like engine_panic, engine_sleep, and engine_wake by focusing on the initial startup 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?

  Provides explicit sequencing: 'Call this AFTER loading audio, creating tracks, and placing regions — but BEFORE playback or effects.' This clearly tells the agent when to invoke the tool, though it doesn't explicitly name alternatives or when not to use it beyond the implied ordering.

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

• mcp_opendaw_swap_sectionsA
  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 full burden and does a good job: it discloses that all note/audio content is exchanged, explains behavior with unequal lengths ('preserves each section's content and shifts everything accordingly'), and covers adjacent vs. gap cases. It does not explicitly state that this is a destructive/mutating operation or mention undo, but the swap semantics are clearly described. Missing some edge-case details like interaction with automation/markers, so 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.

  Conciseness4/5

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

  The description is well-structured with a clear lead sentence, a usage paragraph, behavioral details, and an Args/Returns section. It is slightly redundant—repeating the swap concept in the first and second paragraphs—but each additional part adds value (length differences, gap handling, parameter meanings). Minor redundancy keeps it from a 5.

  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 complexity (5 params, no annotations, but an output schema exists), the description covers the core behavior, parameter constraints, edge cases, and return values. It does not mention potential side effects like whether markers/automation are affected, or any prerequisites beyond section order. These are notable gaps but not fatal, so a 4.

  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 properties have no descriptions (0% coverage), but the description includes an Args block that explains each parameter in plain language: 'Start beat of first section,' 'must be > section1_end,' and the default behavior of unit_indices ('' = all units). This fully compensates for the missing schema descriptions and provides essential semantic meaning 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 opens with a specific verb+resource: 'Swap two sections of the arrangement — exchange their positions on the timeline.' It clearly states what the tool does and distinguishes it from siblings like move_section or reorder_sections by emphasizing the two-way exchange. The restatement 'moving section A to where section B was and vice versa' reinforces the action 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?

  The description explicitly says this is 'useful for song structure experimentation' and gives concrete examples (chorus before verse, swap bridge with solo) and contrasts with 'manual cut/paste.' It does not name alternative tools or state when not to use it, but the context is clear enough that an agent can infer appropriate usage. Lacks explicit exclusions/alternatives, so not a 5.

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

• mcp_opendaw_transfer_audiounitA
  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 the deep-copy mechanism, dependencies, delete_source for move semantics, and the output unit limitation. It could elaborate on side effects like routing or use cases, but this is solid coverage.

  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 well-structured and front-loaded with purpose, followed by implementation details, parameter explanations, and return info. Some jargon like 'box-graph serialization' is not essential, but the description remains 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?

  The description covers purpose, behavior, parameters, and return values. It lacks explicit prerequisites (e.g., project loaded) and broader comparison to all sibling tools, but for a complex transfer operation, this 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?

  Schema description coverage is 0%, so the description must explain everything. It does so effectively: unit_index, delete_source (move semantics), insert_index (position, -1 auto-place). 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 clearly states the tool transfers/copies an audio unit with all dependencies, using a specific verb and resource. It explicitly distinguishes from duplicate_audiounit, 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 provides clear context (deep-copy with dependencies) and explicitly names duplicate_audiounit as an alternative, noting it is less complete. However, it does not discuss exclusions or when to use other sibling tools like transfer_region or move_audio_unit.

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

• mcp_opendaw_add_midi_effectA
  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 for behavioral context. It discloses the chain location, the processing role of MIDI effects, the allowed effect_type values, the instrument-AU requirement, and the return value. It does not cover failure modes, but for an additive operation this is a strong set of disclosures.

  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 front-loaded: first sentence states the action, then provides context, parameter details, and return value. Every sentence earns its place with no 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?

  The tool is relatively simple with two parameters, and the description covers both parameters, the conceptual distinction, and the return value. It is sufficiently complete for an agent to invoke the tool correctly, though it could optionally mention the effect's position in the chain or error handling.

  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 zero coverage, so the description fully compensates by explaining both parameters: effect_type lists the allowed values and unit_index clarifies it must be an instrument AU. It also adds semantic meaning by describing what MIDI effects do, which is absent 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?

  The description begins with 'Add a MIDI effect to an audio unit's MIDI effect chain,' which is a specific verb and resource. It distinguishes MIDI effects from audio effects by referencing au.midiEffects vs au.audioEffects, setting it apart from sibling tools like add_effect.

  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 MIDI effects process note data before the instrument and are chained separately from audio effects, providing clear context for when to use this tool. It also notes that unit_index must be an instrument AU, not an output, acting as a prerequisite. However, it does not explicitly name alternatives 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.

• mcp_opendaw_add_passing_tonesA
  4.5/5.0
  Behavior4/5

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

  Annotations are absent, so the description fully carries the burden of behavioral disclosure. It explains the placement on weak beats, the direction options, the cross_track behavior (placing on another track to preserve original melody), and the default velocity being quieter. It does not explicitly state whether notes are inserted or modified in place or if it's reversible, but the cross_track option implies a non-destructive path. The level of detail significantly exceeds minimal transparency.

  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 longer than average but well-structured: a lead sentence, an explanatory paragraph, a bulleted condition list, and a detailed Args section. Every part contributes to understanding. The musical examples (Bach, jazz, pop) add context but could be trimmed without losing core meaning. It is front-loaded with the essential purpose and maintains focus throughout.

  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 10 parameters, no annotations, and a schema lacking descriptions, this description is exceptionally complete. It covers the musical goal, the exact conditions for operation, every parameter with meaning and defaults, and a notable behavioral option (cross_track). The presence of an output schema is not critical here since this is a mutation tool; the description fully equips an agent to decide when and how to use 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?

  The input schema has 0% description coverage, but the description's Args section provides comprehensive semantics for all 10 parameters. It explains units, ranges, defaults, and even musical rationale (e.g., velocity default 0.6 'slightly quieter than melodic notes, as is traditional'). This goes far beyond the minimal schema types and titles, giving the agent everything needed to invoke 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?

  The description opens with a clear, specific statement: 'Add passing tones between existing notes for smoother melodic lines.' It names the exact resource (passing tones between existing notes) and verb (add), and distinguishes itself from sibling tools like add_anticipation or add_neighbor_tones by focusing on interval-filling with scale steps. The musical context and conditions further clarify its unique role.

  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 concrete conditions for when the tool is applicable (interval > 2 semitones, enough time gap, not exceeding max_interval) and gives musical examples (Bach, jazz, pop). It does not explicitly mention alternatives or when not to use it, but the conditions strongly imply the appropriate context. While not as explicit as naming alternative tools, it offers clear usage guidance beyond a vague 'use this for counterpoint.'

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

• mcp_opendaw_add_tempo_changeA
  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. It discloses that a ValueEventBox is created, explains the normalized value mapping and automatic conversion, and states the return value (created event and tempo map). This is informative, though it doesn't mention idempotency or effects on existing tempo changes.

  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 well-structured with a brief overview, internal details, and a parameter list. It is reasonably concise, though it could trim some redundancy (e.g., repeating 'BPM' multiple times). Overall, every sentence adds value.

  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 moderate-complexity tool, the description covers purpose, parameters, internal behavior, and return value. The output schema exists, so the return format is already structured. The description is complete for selection and 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 coverage is 0%, so the description fully compensates by explaining each parameter: position_beats (position in beats), bpm (target BPM, 60-240), and interpolation ('linear' vs 'hold'). This exceeds the raw schema and provides clear meaning and valid 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 clearly states the tool adds a tempo change at a specific position, using a specific verb ('Add') and resource ('tempo change'). It distinguishes itself from siblings like set_bpm and create_tempo_ramp by focusing on mid-track automation and explicitly mentions creating a ValueEventBox on the tempo track.

  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 for mid-track BPM automation with examples (120→90→140 BPM) and explains interpolation options. It lacks explicit 'when not to use' or alternative tool mentions, but the context is clear enough for an agent to infer appropriate use.

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

• mcp_opendaw_analyze_melodyA
  4.5/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, so the tool is known to be safe. The description adds meaningful behavioral detail beyond the annotation: it explains how phrases are grouped (by rests > 1 beat) and what the return object contains. This is useful context without contradicting the annotation.

  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 well-organized with sections and bullet points. Every sentence adds value, but the output feature list (10 items) and use-case list (5 items) could be tightened without losing meaning. Front-loaded core statement ensures quick comprehension.

  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 complexity (detailed musical analysis) and the presence of an output schema, the description is remarkably complete. It covers what the tool does, what it returns (even beyond the schema, e.g., phrase analysis details), when to use it, and parameter explanations. The inclusion of an example call reinforces 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 schema has 0% description coverage, but the description compensates with a clear param section: 'unit_index: AU index, track_index: Note track index, region_index: Region (-1 = first region).' It also provides a code example showing positional usage, making parameter semantics explicit and actionable.

  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: 'Analyze melodic content — contour, intervals, direction, climax.' It then enumerates a detailed list of outputs (contour profile, interval histogram, step/leap ratio, etc.), making the tool's function unmistakable. The specificity distinguishes it from broader sibling tools like mcp_opendaw_analyze_track or mcp_opendaw_note_stats.

  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?

  A dedicated 'Useful for:' section lists five concrete scenarios, such as 'understanding a melody before variation/reharmonization' and 'feeding analysis to create_motif_variations.' This provides clear context on when to use the tool, though it does not explicitly mention when not to use it or name alternative tools for comparison.

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

• mcp_opendaw_analyze_stereoA
  4.5/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=true, and the description adds behavioral context by explaining it reads a WAV file and computes stereo metrics. It also clarifies filename semantics (exports directory or absolute path) and gives detailed metric definitions, going beyond the minimal read-only annotation.

  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 well-structured with a summary header, detailed metric bullet points, mix decision guidance, and an Args section. The information density is high and each section serves a purpose, though it could be slightly trimmed without losing value.

  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 description covers input (filename), output (stereo descriptors, per-region width, mix suggestions), and interpretation (decision thresholds). Even though an output schema exists, the description goes beyond by explaining metric ranges and actionable guidance, making it complete for an agent to invoke 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 schema only provides the parameter title with no description (0% coverage), but the description's Args section fully explains the filename parameter: 'Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.' This fully compensates for the lack of schema 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 states 'Stereo analysis of audio' and lists specific outputs like stereo_width, lr_balance, and phase_correlation. It distinguishes itself from sibling tools such as analyze_mix or analyze_dynamics by focusing on stereo-specific metrics and per-region width.

  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 'Mix decision guidance' section provides explicit thresholds (e.g., stereo_width < 0.1 means narrow) that indicate when to act on results. However, it does not explicitly mention when not to use this tool or how it compares to other analysis tools, so it lacks explicit exclusions.

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

• mcp_opendaw_analyze_trackA
  4.5/5.0
  Behavior4/5

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

  The annotation declares readOnlyHint=true, and the description adds substantial behavioral context: it runs multiple analyses in a single call, returns a comprehensive set of audio metrics, and requires a filename. It does not describe failure modes, but given the read-only annotation, the description adds enough useful context beyond what annotations provide.

  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 it is well-structured: purpose, pipeline context, parameter explanation, return fields, and a usage example. Each section adds practical value, though the example repeats some return-field info. It is appropriately sized for the tool's composite nature.

  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 description covers all essential aspects: what it does, when to use it, how the parameter is specified, what it returns, and a concrete usage example. With an output schema present, the return-value listing is extra but helpful. There are no significant gaps 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?

  The input schema provides zero description for the filename parameter (schema description coverage is 0%). The description fully compensates by explaining both accepted forms: a filename relative to the exports directory or an absolute path to any WAV file, and includes an example. This is excellent parameter-level guidance.

  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 'Full audio analysis in one call — BPM + key + LUFS + duration + dynamic range' which explicitly states what the tool does. It further clarifies that it is a composite of detect_bpm + detect_key + measure_lufs, clearly distinguishing this integrated tool from its single-purpose 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?

  The description provides clear usage context: it is a composite tool that eliminates three separate calls and is essential for the Suno remix pipeline. It names the individual tools being combined, but does not explicitly state when one would prefer the single-purpose alternatives over this composite, though that is implied by the efficiency rationale.

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

• mcp_opendaw_apply_velocity_patternA
  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. It discloses the exact formula for final velocity, explains cycle vs stretch modes, and states the return payload (notes modified, pattern applied, velocity preview). It doesn't mention irreversibility, but the behavior is well-specified.

  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 well-organized with a clear opening, parameter list, formula, and examples. It's somewhat long but every sentence carries meaningful information; the examples add practical clarity without being redundant.

  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 6-parameter tool with no annotations, the description is remarkably thorough: it covers all parameters, modes, the underlying formula, return values, and practical examples. It also situates the tool against alternatives, making it easy for an agent to decide when to invoke 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 descriptions are 0% covered, so the description must and does explain every parameter: unit_index, track_index, pattern (with JSON example), region_index, mode (with definitions), and base_velocity (with default and formula). It even provides multiple examples showing parameter combinations.

  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: 'Apply a cyclic velocity pattern to existing notes in a region.' It clearly distinguishes from linear ramps/crescendos and positions itself as the accent/groove tool, differentiating it from siblings like apply_velocity_curve or apply_velocity_lfo.

  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 contrasts with linear ramps ('Instead of a linear ramp (crescendo)...') and provides concrete use cases (backbeat emphasis, syncopation, dynamic layers). It implies when to use this tool but doesn't explicitly name alternative tools or exclusions beyond the linear ramp contrast.

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

• mcp_opendaw_auto_gainA
  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 burden of behavioral disclosure. It reveals the iterative loop (render → measure LUFS → adjust Maximizer threshold → re-render), convergence tolerance (±1 LUFS), and return values (final LUFS, threshold, iterations, WAV path). It does not state side effects on the project (e.g., whether the original mix is modified), but it gives substantial insight into its 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 well-structured: a one-sentence purpose, a concise algorithm outline, a bullet-style parameter list, and a clear return statement. Every sentence adds meaningful information without repetition or unnecessary 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?

  The description covers the tool's purpose, algorithm, parameter semantics, and return values. Since an output schema exists, return details need not be exhaustive. The main missing piece is whether the tool operates on the entire project mix or a specific track, but the name and 'output volume' imply the master output. Overall, it is sufficiently complete 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 explains all four parameters thoroughly: target_lufs includes platform examples, filename notes that no .wav extension is appended, sample_rate and max_iterations both state defaults. This fully compensates for the missing schema descriptions and adds practical guidance.

  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 explicitly states the tool's function: 'Auto-adjust output volume to hit a target LUFS.' This uses a specific verb (auto-adjust), resource (output volume), and outcome (target LUFS), clearly distinguishing it from siblings like measure_lufs (measurement only) or export_mix (export only).

  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 context for when to use the tool by mentioning common streaming loudness targets (Spotify -14, YouTube -14, Apple -16) and describing the iterative process to achieve a target. It does not explicitly name alternative tools or exclusions, but the use case is strongly implied through these examples.

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

• mcp_opendaw_balance_track_velocitiesA
  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 takes on the full burden. It discloses the algorithm: reads current average velocities, computes scale factors, and applies them in multiply mode, preserving original relative dynamics. It also notes that per-track velocity stats are returned before/after. This provides solid behavioral insight, though it does not explicitly state reversibility or edge-case handling (e.g., out-of-range targets), which keeps it from a 5.

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

  Conciseness4/5

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

  The description is comprehensive but well-organized with clear sections: overview, preset list, parameter definitions, return value, and examples. It is longer than average, but every section adds necessary detail for the tool's complexity. The front-loaded overview immediately conveys the core purpose, and the structured preset list is easy to scan. The lack of a brief parameter list for unit_index slightly affects structural completeness.

  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 tool has 5 parameters and an output schema, and the description covers the key aspects: purpose, preset behavior, parameter formats, and return value (per-track stats). It includes practical examples for both preset and custom modes. The missing unit_index definition is the primary gap, and since the output schema exists, the description appropriately avoids re-explaining return structure. Overall, the description is complete enough for typical use, but the unit_index omission prevents a perfect score.

  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 thoroughly explains track_indices, preset (listing all preset options with target values), target_velocities (format and requirement to match count), and region_index (special values -1 and -2). The only gap is unit_index, which appears only in the example (as the first argument) without explicit explanation in the parameter list. This is a notable omission but the example infers its usage.

  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: 'Balance velocities across multiple tracks — MIDI mix leveling.' It clearly states the tool sets relative velocity levels across multiple note tracks. It also explicitly distinguishes itself from the sibling tool scale_velocity, which handles one track at a time, making 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 Guidelines5/5

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

  Usage context is explicit: the tool is for balancing velocities across multiple tracks, with a direct comparison to scale_velocity ('Unlike scale_velocity (one track at a time)'). It also provides presets for specific musical genres/mix intentions, giving clear 'when to use' guidance. Examples further illustrate the intended call patterns.

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

• mcp_opendaw_capture_realtimeA
  4.5/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 full burden. It discloses return behavior ('Returns file path and size'), error conditions ('or error if engine not running'), and a filename constraint ('without extension'). It could also mention side effects (e.g., whether a region is placed in the project), but the disclosed traits are meaningful.

  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: first line states the purpose, followed by usage context, then parameter details, then return/error behavior. Every sentence earns its place with 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?

  For a two-parameter capture tool, the description covers the what, when, prerequisite, parameter semantics, and return format. It omits explicit alternative tool comparisons and potential side effects like whether an audio region is added to the project, but given the output schema exists and the tool is simple, it is reasonably 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 descriptions are completely absent (0% coverage), and the description fully compensates by explaining each parameter with type and example: 'duration_seconds: How long to record (float, e.g. 10.0)' and 'filename: Output WAV filename (without extension).' This adds clear meaning beyond the bare schema names.

  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+resource+method: 'Capture realtime audio output from the DAW engine' and clarifies it records live playback with effects and automation. This clearly distinguishes it from offline render/export tools like render_range or export_mix.

  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 and a prerequisite: 'The engine must be running (call start_engine first).' Also states when it's useful (live playback, effects, automation). However, it does not explicitly name alternatives or exclusions (e.g., 'for offline rendering use render_range'), so not a 5.

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

• mcp_opendaw_convert_audioA
  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. It discloses that system ffmpeg is required (not browser WASM), that it falls back gracefully if missing, and that it returns the path and size info. It does not detail overwrite behavior or failure modes, but the key operational 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 compact and well-structured: a one-sentence summary, a tight parameter list, then dependency and return information. Every line adds value 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 moderate conversion tool, it covers the source location, target formats, parameter defaults, system requirement, fallback behavior, and return value. The fallback statement is a bit vague ('falls back gracefully' without specifying the actual behavior), and it doesn't mention output destination or filename conventions, but the presence of an output schema and the existing detail make it functionally complete for 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?

  The schema has zero descriptions for its 4 parameters, but the description documents each one thoroughly: filename (source, without .wav, in export dir), format (mp3/flac, default mp3), bitrate (MP3 CBR, default 320k, ignored for FLAC), and quality (VBR 0-9, -1 for CBR, default). This adds complete 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: 'Convert an exported WAV file to MP3 or FLAC using system ffmpeg.' This clearly distinguishes the tool from siblings like export_mix or download_audio by stating its exact purpose and target formats.

  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: source is an exported WAV file in the export dir, and it notes the requirement for system ffmpeg with graceful fallback. It does not explicitly name alternatives or exclusion cases, but the scope (WAV to MP3/FLAC) and prerequisites are clear enough for an agent to decide when to use it.

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

• mcp_opendaw_create_appoggiaturaA
  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 thoroughly explains the tool's behavior: plays a neighbor note first, resolves to the main note, defaults to a 2/3–1/3 duration split, accents the approach note, and supports above/below approaches. It also discloses the return value ('Returns notes created, pitches used'). Missing are edge-case behaviors like what happens if no AU with note tracks is found or whether existing notes are affected, but the core behavior is well documented.

  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 moderately long but well-structured: an opening definition, a comparative explanation, interval-direction examples, a duration-ratio explanation, and then a parameter list. Each sentence adds value, though the stylistic references ('Think Bach cello suites, Mozart operas, Chopin nocturnes') are somewhat tangential. The front-loaded purpose ensures the agent immediately knows what the tool does before diving into details.

  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 complexity (8 parameters, empty schema descriptions, no annotations, no output schema details), the description is remarkably complete. It covers the musical concept, the pitch relationship (above/below), the rhythmic behavior (ratio and defaults), velocity characteristics, and the target selection (unit_index/track_index). The output is mentioned, and the parameter semantics are fully explained. The only minor omission is explicit error behavior, but for a creation tool this is acceptable given the level of detail provided.

  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, comprehensively. Every parameter is explained: main_pitch and approach_pitch with defaults and pitch class (60=C4, 62=D4), duration_beats with a range (0.5-8), appoggiatura_ratio with a range and musical meaning (0.5-0.9, higher = more tension), velocity with accent behavior, unit_index and track_index with targeting semantics, and start_beat. This goes well beyond the bare schema and gives the agent actionable meaning for each 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 opens with a specific verb+resource: 'Create an appoggiatura — leaning grace note that resolves to the main note.' It clearly defines the tool's purpose and distinguishes it from the sibling tool mordent by contrasting the expressive, resolving appoggiatura with the quick-flick mordent. It also places it within the baroque ornament family (trill, mordent, turn, appoggiatura), making its scope 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 provides clear usage context by explaining when an appoggiatura is appropriate (expressive, tension-and-release) and explicitly contrasts it with the mordent ('Unlike a mordent (quick flick)...'). This gives the agent a decision rule for at least one alternative. However, it does not discuss when not to use the tool for other ornament types (trill, turn) or mention any preconditions such as needing an existing note track, so it falls short of fully comprehensive guidance.

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

• mcp_opendaw_create_balkan_meterA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description discloses key behavioral details: the tapan pattern, accent placements, and variation styles. It also states the return value ('notes created, meter grouping, accent positions, and pattern info'). It doesn't address side effects like clearing existing notes, but this is a creative tool where such behaviors are less critical.

  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 well-structured: introductory context, meter list, variations, and Args. The musical background, while verbose, adds value for an AI agent making stylistic choices. It is front-loaded with the purpose and avoids redundancy, though some paragraphs could be tightened.

  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 11 parameters, no annotations, and 0% schema coverage, the description is remarkably complete. It covers meter options, variations, parameter semantics, and return values. The presence of an output schema further reduces ambiguity. There are no major gaps that would prevent correct tool selection or 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 coverage is 0%, but the Args section comprehensively describes all 11 parameters with valid values, defaults, ranges (cycles 1-32, velocity 0-1), and MIDI pitch examples. This fully compensates for the lack of schema descriptions, enabling 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 clearly states 'Create a Balkan additive meter pattern' and elaborates with specific time signatures and cultural context. It distinguishes itself from sibling tools like create_tala or create_euclidean_rhythm by focusing on Balkan additive meters with unique grouping patterns.

  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 rich context on when Balkan meters are used (Macedonian, Bulgarian, Greek folk music) and explains the musical intent. However, it does not explicitly mention when not to use this tool or compare it with alternative rhythm-generation tools, lacking explicit exclusions.

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

• mcp_opendaw_create_bariolageA
  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 must carry the full behavioral burden. It discloses some behaviors (like pedal_pitch defaulting to root when -1, accent_pedal adding accent, and return values), but it does not state whether notes are added or appended, whether existing notes are overwritten, or any prerequisites like valid track/unit indices. This leaves the mutation semantics unclear.

  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 lengthy but well-structured: definition, historical context, contrast with alternatives, pattern/subdivision lists, args, and return value. It is front-loaded with the core definition and all content serves a purpose, though some historical background could be trimmed for an agent-focused description.

  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 13-parameter tool with no schema descriptions and no annotations, this description is remarkably complete: it explains the musical concept, all parameters, pattern options, subdivisions, and return value. It also names alternatives, making it easy for an agent to decide when to use 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?

  With 0% schema description coverage, the description fully compensates by listing all 13 parameters with meaningful explanations, including value ranges (bars 1-8, octave 2-6, velocity 0-1), pattern enums, and the special -1 behavior for pedal_pitch. This is the primary source of parameter understanding.

  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 'Create a bariolage — rapid alternation between a fixed pedal pitch and moving notes,' which clearly states the verb, resource, and core behavior. It also explicitly distinguishes bariolage from arpeggiator and montuno, making it easy to differentiate from 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 Guidelines5/5

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

  The description explicitly contrasts bariolage with arpeggiator and montuno, explaining that arpeggiator cycles chord tones and montuno does syncopated chord stabs, while bariolage creates a two-voice illusion. This gives the agent clear when-to-use vs. 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.

• mcp_opendaw_create_bass_dropA
  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 transparency burden. It discloses the internal two-phase behavior (sweep and hold), parameter meanings, defaults, and even the curve types ('linear', 'exp', 'log'). It also mentions the return value ('Returns notes created, sweep/hold details'). While it doesn't cover error cases or whether it modifies existing notes, it gives a robust picture of the tool's operation.

  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 relatively long but structured logically: it opens with a one-sentence summary, then explains the two phases, then lists each parameter with its meaning. The structure makes it easy to scan, and the length is justified given the lack of schema descriptions. Only minor redundancy exists (e.g., repeating the default values already in schema), but it remains efficient.

  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 9-parameter tool with no annotations and no schema descriptions, the description is remarkably complete. It covers the musical purpose, the two-phase algorithm, all parameter semantics, and the return value. Given the output schema exists, the brief return description is sufficient. There are no significant gaps that would hinder an agent's ability to use 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 schema has 0% description coverage, but the description fully compensates by explaining every parameter in plain language: start_pitch, end_pitch, sweep_beats, hold_beats, sweep_curve, unit_index, track_index, start_beat, and velocity, including defaults and value ranges. This exceeds the schema's bare titles and provides essential semantics 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 clearly states the tool's function: 'Create a bass drop — descending pitch sweep into sustained sub bass.' It uses a specific verb ('create') and resource ('bass drop'), and distinguishes from sibling tools by describing the 'wub' or 'fall' characteristics and musical genres (dubstep, EDM, trap), setting it apart from similar generative tools like create_riser or create_buildup.

  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 contextual guidance by stating it is 'The quintessential dubstep/bass music drop' and 'Also works for EDM build-and-drop, trap bass falls, and impact transitions.' This implies when to use it, though it does not explicitly name alternative tools or exclusions. It offers enough context for an agent to select this tool over related ones.

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

• mcp_opendaw_create_buildupA
  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. It discloses that notes are created for riser and snare roll, explains the velocity ramp and density increase, and details unit_index default behavior. It does not mention failure modes or whether existing notes are overwritten, but it is quite transparent for a creative generator.

  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 with a summary, component breakdown, style presets, parameter explanations, return value, and a practical example. Every sentence adds value; the style list is necessary detail rather than 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?

  The description covers purpose, usage, parameters, return value, and provides an example. It lacks explicit details on where the snare roll is placed relative to the riser track, and error conditions for missing note tracks, but overall it gives enough guidance for an AI 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 thoroughly. Every parameter is explained with additional context: style presets include exact note patterns, velocity has a 0-1 range and ramp behavior, unit_index explains the -1 behavior, and length_beats defaults to 8 = 2 bars.

  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 'Create a complete build-up — riser + snare roll in one call,' which clearly states the verb, resource, and scope. It explicitly distinguishes from the sibling create_riser by emphasizing the combination of two elements.

  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 says the tool is for 'a full build-up before a drop/chorus' and the example shows it used before create_impact, giving clear context. It does not explicitly state alternatives or when not to use it, but the genre-specific style options imply usage across different musical contexts.

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

• mcp_opendaw_create_canonA
  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 responsibility. It explains the core behavior (same melody copied into voices, time-delayed entries, optional transposition, velocity decay) and lists return values (notes created, voice count, total length, transpositions). It does not state whether the operation is additive or destructive to existing notes, or mention prerequisites for the target track, which would have made it fully 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 long but well-structured: a definition, musical context, and one-line parameter definitions. Every sentence adds value, especially given the lack of schema descriptions. It is slightly verbose in the conceptual opening but not wasteful.

  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 complexity of 10 parameters, no annotations, and 0% schema description coverage, the description is remarkably complete. It covers all parameters, returns, examples, and a sibling differentiation. The presence of an output schema means return values need not be fully enumerated, but the description still summarizes them.

  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. It does so thoroughly: all 10 parameters are explained with concrete examples, ranges, and defaults (e.g., transposition '0,7,12', voices 2-6, entry_delay_beats 1-16). This is exemplary compensation for 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 opens with a clear, specific verb and resource: 'Create a canon — strict melodic imitation with delayed voice entries.' It explicitly contrasts with the sibling create_counterpoint ('which generates a new line'), clearly distinguishing what this tool does and making 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?

  It provides strong usage context with musical examples (Pachelbel, Row Row Row Your Boat) and an explicit alternative comparison to create_counterpoint. However, it doesn't enumerate exclusions for other close siblings like create_fugue or create_chorale, so the 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.

• mcp_opendaw_create_counterpointA
  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 the algorithm (reads notes, offsets by interval, mirrors around midpoint), the effect of default parameters, and the return value. It also notes that velocity is quieter than melody. It lacks explicit statements about whether source notes are modified, but 'reads notes' implies non-destructive 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 well-structured and appropriately sized for a 7-parameter tool. It leads with a clear summary of the tool's function, follows with an algorithmic explanation, and then lists parameters with concise semantic annotations. No wasted words or redundant repetition of the schema.

  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 provides enough information for an agent to invoke the tool correctly, including all parameter semantics and the return value. It covers the main behavioral aspects (contrary motion, interval offset, target placement). It does not describe edge cases (e.g., empty region) or detailed output structure, but the presence of an output schema suggests those are handled elsewhere.

  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 explaining every parameter: unit_index, track_index, region_index, interval (with default and meaning as a fifth), new_unit_index (with -1 meaning new synth track), new_track_index, and velocity (with default and quieter-than-melody). This adds substantial semantic value 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 clearly states the tool generates a counter-melody in contrary motion to existing notes, using specific terminology like 'counter-melody', 'contrary motion', and 'mirrored'. It distinguishes from siblings such as create_counter_melody_from_progression or create_harmony by specifying the algorithm (opposite direction, fixed interval).

  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 context for use: to generate a counter-melody from an existing melody with contrary motion. It explains the source and target parameters, implying when to use it. However, it does not explicitly mention alternatives or 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.

• mcp_opendaw_create_crescendoA
  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 thoroughly explains that note velocities are gradually changed from start to end across all notes in the region, and it describes the curve options ('linear', 'exp', 'log'). It also discloses the return value (number of notes modified and velocity range), which is valuable beyond the schema.

  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 concise: a one-sentence purpose, a brief behavioral summary, a usage hint, a parameter list, and a return-value statement. Every sentence adds value with no redundancy or fluff, and the information is front-loaded with the main verb and resource.

  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 tool has 6 parameters, no annotations, and a description that covers all behaviors and return values. It does not mention error conditions or prerequisites (e.g., that the region must exist), but for a note-velocity editing tool this is a minor gap. Overall, the description is sufficiently complete 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%, but the description fully compensates by explaining every parameter: unit_index, track_index, region_index (with default -1 meaning first region), start_velocity, end_velocity, and curve (including detailed curve semantics). This goes beyond what the schema provides, making it easy for an agent to select correct 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 clearly states the tool applies a crescendo or decrescendo to existing notes in a region, using a specific verb and resource. It distinguishes itself from velocity-related sibling tools by focusing on gradual velocity transitions across a region. The scope is explicit and 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 provides clear context: 'Useful for building tension or fading out' indicates when to apply the tool. It does not explicitly name alternatives or exclusions, but the context is sufficient to understand its intended use. The mention of 'existing notes' implies it is not for creating new content.

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

• mcp_opendaw_create_flamenco_compasA
  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. It thoroughly explains the three rhythmic layers (palmas secas, palmas sordas, cajón/golpe), the palo-specific accent patterns, and the return payload ('notes created, instrument breakdown, accent positions, and palo info'). However, it does not disclose operational details such as whether the tool appends to existing notes, requires an existing note track, or has any side effects beyond creating notes.

  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 long but meticulously structured: purpose, conceptual background, layered instrument roles, palo encyclopedia, and an annotated parameter list. The opening sentence front-loads the purpose, and every subsequent section adds decision-relevant information. There is no redundancy 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 tool with 10 parameters, zero annotations, and a specialized cultural domain, the description is impressively complete: it explains the musical theory, enumerates palos with accents and moods, maps each pitch parameter to an instrument, and previews the return value. The only gap is operational prerequisites (e.g., whether track_index must point to an existing note track) and explicit guarantees about non-destructive 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 has 0% description coverage, but the description compensates completely: it explains each parameter's musical role, provides ranges (cycles 1-16, velocity 0-1), and translates MIDI pitch numbers into instrument names and notes (39 = D#1). The palo descriptions give meaningful guidance for selecting a palo based on tempo, mood, and accent structure.

  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 'Create a Flamenco compás' — a specific verb and resource. It further defines compás as the cyclical rhythmic foundation of Flamenco, making the tool's function unmistakable. It clearly distinguishes itself from sibling pattern-generation tools like create_clave or create_tala by focusing on Flamenco-specific palos.

  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 when to use this tool by contrasting Flamenco compás with Western meter and by explaining the distinct rhythmic feels of six palos. This helps the agent choose the right palo for the desired musical mood. However, it does not explicitly mention when not to use this tool or name alternative tools for non-Flamenco rhythms.

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

• mcp_opendaw_create_glissandoA
  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 responsibility. It discloses the note generation behavior (plays every intermediate note at a fixed rate), supports chromatic/diatonic/pentatonic modes, and mentions return values (notes created, pitch list, scale type). It does not explicitly state whether the operation appends to or replaces existing notes, nor does it cover error conditions or permissions.

  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: a one-sentence summary, a paragraph explaining the concept and differences, a bulleted parameter list, and a return value note. Every sentence adds value without redundancy, making it easy to parse quickly.

  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 10 parameters and no annotations, the description is quite complete: it covers all parameters, defaults, return values, and some behavioral context. However, it does not address potential edge cases (e.g., what happens if no AU with note tracks is found) and does not distinguish from the similar create_scale_run sibling, leaving a minor gap in completeness.

  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 defaults, ranges, and examples (e.g., 'start_pitch: Starting MIDI note (default 60 = C4)' and 'rate: Note rate — "32nd", "16th", "8th", "32t", "16t"'), providing enough detail for the agent to use 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?

  The description clearly states 'Create a glissando — smooth scale run between two pitches,' which specifies the action and object. It also distinguishes itself from riser/bass_drop by explaining the difference between pitch sweeps and scale runs, making its 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 explicitly contrasts with riser/bass_drop ('Unlike riser/bass_drop (which are pitch sweeps), glissando plays every intermediate note at a fixed rate'), providing clear guidance for those alternatives. However, it does not differentiate from the similarly named sibling tool create_scale_run, and it lacks a broader 'use this when' statement.

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

• mcp_opendaw_create_ground_bassA
  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. It discloses that the tool generates both bass and melody, placing melody on track_index+1, and that melody evolves across repetitions per style. It does not explicitly state whether existing notes are overwritten or appended, which is a minor gap 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.

  Conciseness4/5

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

  The description is long but effectively structured: a headline purpose, historical context, a comparative note, styled bullets, and an args list. It's front-loaded with the definition, and each paragraph earns its place, though the historical section could be trimmed without losing critical 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?

  The tool has 8 parameters, 5 style options, and an output schema; the description covers every parameter with semantics, explains the return value ('Returns bass notes created, melody notes, cycle info, and style'), and clarifies the two-track behavior. The only missing piece is edge-case handling for track_index+1, but overall the description is comprehensive.

  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?

  All 8 parameters are described with examples and format details beyond schema defaults. For instance, bass_pattern supports note names or MIDI numbers, bass_rhythm includes an example cycle calculation, repeats has a range, and melody_style offers five detailed style descriptions. Since schema_description_coverage is 0%, 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 opening sentence defines the tool with a specific verb and resource: 'Create a ground bass — a repeating ostinato bass line with optional melody.' It also distinguishes itself from a sibling: 'Unlike passacaglia (which generates variations above the bass), ground_bass creates the pure repeating bass ostinato + a melody line that develops over the repetitions.' This gives clear purpose and 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 provides context for when to use the tool historically ('Used in baroque... jazz modal vamps... film scoring') and explicitly contrasts with passacaglia, implying a choice between the two based on whether you want variations above the bass. However, it does not mention other similar siblings like create_ostinato or create_bassline, so exclusion is limited.

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

• mcp_opendaw_create_melodic_polyrhythmA
  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 explains key generative behaviors: notes ascend/descend through a scale, the pitches parameter overrides scale generation, and velocity patterns (constant, accent, fade, wave) alter output. However, it does not disclose whether the operation overwrites existing notes on the target track or is purely additive, a notable side-effect gap 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.

  Conciseness4/5

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

  The description is moderately long but well-organized: definition, musical rationale, then a clear Args list. Each sentence adds value—examples like '3:4 = triplet feel' aid understanding, and the Args block is systematic. It could be slightly tighter by trimming the trailing musical-context sentence, but it remains focused and non-redundant.

  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 complexity (12 parameters, many with domain-specific meaning) and a 0% schema coverage, the description fully covers every parameter, provides defaults and ranges, and supplies genre/usage context. An output schema exists, so not describing return values is acceptable. The agent can confidently select and invoke this tool based on this description alone.

  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 entirely—and it does. The Args section defines all 12 parameters, including ranges, defaults, and meaningful semantics: numerator as 'against' number, denominator as 'base' pulse, pitches as an override, and full enumerations for velocity_pattern and direction. This far exceeds minimal compensation and gives the agent everything needed to invoke 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+resource: 'Create a polyrhythm — N notes evenly spaced across M beats.' It further clarifies that this is a 'melodic polyrhythm rather than just rhythmic hits,' directly distinguishing it from sibling tools like create_polyrhythm or create_hemiola. The musical context and example ratios reinforce a clear, unique purpose.

  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 strong contextual guidance—explaining 3:4 as triplet feel, 5:4 as quintuplet, and mentioning jazz cross-rhythm, prog-rock metric modulation, African cross-pulse, and contemporary classical writing. However, it does not explicitly name alternatives or state when NOT to use this tool (e.g., 'for rhythmic-only polyrhythms use create_polyrhythm'), so exclusions are absent.

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

• mcp_opendaw_create_melody_from_progressionA
  4.5/5.0
  Behavior4/5

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

  The description discloses the musical generation behavior: chord tones on strong beats (1,3) and passing/neighbor tones on weak beats (2,4), plus detailed pattern definitions. However, it does not state whether the tool overwrites existing notes on track_index or adds to them, or whether a track must already exist, which would matter for a tool with no annotations.

  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 core purpose and then uses labeled sections for patterns, parameters, and examples. It is longer than necessary, but the bullet-style pattern list and three usage examples justify the length; minor redundancy exists in repeating beat/chord-tone rules.

  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 8-parameter tool with no annotations and an output schema, the description covers the main workflow, the chord-string format, pattern options, defaults, and examples. It fails to explain start_beat and unit_index, and says nothing about whether the operation is additive or destructive, but overall it gives an agent enough context to invoke the tool correctly for typical melody generation.

  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 description provides detailed semantics for pattern (five named patterns with rhythmic definitions), bars_per_chord, octave (with C5=72 reference), velocity, and track_index, and it demonstrates progression via examples. It omits start_beat and unit_index, which are not described in the schema either, leaving a gap for those two 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 'Create a lead melody from a chord progression string' with a clear verb and resource. It also distinguishes itself from siblings by naming the 'harmonic quartet' and placing 'THIS (lead melody)' alongside three specific alternative 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?

  It explicitly frames the tool as completing a harmonic quartet with create_chord_pads, create_arpeggiated_progression, and create_bass_from_progression, all sharing the same chord string format. This tells the agent when to use it: after building the other three parts. It also lists alternative pattern options with genre cues, providing practical selection guidance.

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

• mcp_opendaw_create_metric_modulationA
  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 full burden. It discloses the formula, supported note values, the ratio override, default old_bpm behavior, and that add_time_signature creates a time signature change event. It also lists what the function returns. It does not address potential side effects like overwriting existing tempo events, but the disclosed behavior 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.

  Conciseness4/5

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

  The description is longer than average but extremely well-structured with sections for formula, supported values, examples, args, and returns. The historical context in the second sentence is somewhat extraneous but not harmful. Each section earns its place given the complex concept.

  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?

  With no schema descriptions and no annotations, this description is remarkably complete. It covers all six parameters, provides formulas and examples, explains default behavior, and lists return values. It even describes the optional time signature side effect. This is close to a fully self-contained specification.

  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 properties have empty descriptions (0% coverage), so the description's 'Args' section is essential. It explains every parameter, including defaults and interaction rules (ratio overrides old_note/new_note; old_bpm=0 reads tempo track). This fully compensates for the schema gap.

  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 opening sentence 'Create a metric modulation — tempo change that preserves a note-value equivalence' clearly defines the tool with a specific verb and resource. It explicitly distinguishes from a simple tempo change, which differentiates it from siblings like set_bpm and add_tempo_change.

  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 contrasts metric modulation with 'a simple tempo change,' making it clear when this tool is appropriate. It also explains the ratio vs note-value alternatives and provides examples for both. However, it does not explicitly name sibling tools like set_bpm for simple tempo changes, so it's not a perfect 5.

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

• mcp_opendaw_create_ostinatoA
  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. It discloses pattern length (2-8 notes), repetition behavior, parameter ranges (scale types, root names, velocity 0-1, repeats 1-16), and the return value (total notes and pattern info). It does not explicitly mention placement side effects (track/unit), but as a creation tool this is largely inferable. The added detail goes beyond the schema.

  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 appropriately sized: a concise definition followed by a focused parameter list with examples. It is front-loaded with the verb and resource, and every sentence adds value. The example pattern strings clarify the format efficiently 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?

  The tool has 9 parameters and no annotations, but the description covers the essential music-theory parameters, defaults, and return value. Placement parameters (start_beat, unit_index, track_index) are left unexplained, relying on naming conventions. Given the presence of an output schema and strong coverage of core parameters, the description is mostly complete but could benefit from a brief placement note.

  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. It thoroughly documents scale, root, pattern (with syntax examples), repeats, octave, and velocity, including defaults and ranges. It does not describe start_beat, unit_index, or track_index, but these are placement parameters with self-explanatory names. The description 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 clearly states 'Create an ostinato — a repeating melodic/rhythmic pattern as a foundation layer.' This uses a specific verb and resource, and the definition distinguishes it from siblings like create_melody or create_riff by emphasizing repetition and foundational role. The purpose is unambiguous and well-scoped.

  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 context for when to use the tool: when a short repeated pattern is needed as a rhythmic/harmonic anchor. It explains the musical function and typical genres. However, it does not explicitly name alternatives or state when not to use it, which would elevate it to a 5.

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

• mcp_opendaw_create_section_transitionA
  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. It discloses what the tool does (filter sweeps, volume fades, mute automation, impacts) and details the exact behavior per preset (e.g., 'filter close on synths, drums muted, then filter open + unmute + impact'). It also states the return value ('Returns summary of all automation created across units'). Missing is whether existing automation is overwritten or if any prerequisites exist, but overall it paints a clear behavioral picture.

  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 with a high-level summary, a 'why use' statement, parameter details, and examples. No sentence is wasted; the formatting with arrows and line breaks makes the preset definitions scannable. It's longer than average, but every element adds 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?

  Given the tool's complexity (4 params, multiple automation behaviors) and lack of annotations, the description is quite complete. It covers all presets, timing parameters, unit index conventions, and provides examples. The output schema exists, so the description's note on the return value is sufficient. A minor gap is lack of info about how existing automation is handled, but this doesn't significantly detract.

  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. transition_type is enumerated with detailed meanings for each value. start_beat, duration_beats, and unit_indices all have clear definitions, defaults, and additional context (e.g., the unit index convention 'drums=0, bass=1, lead/synth=2, pads=3'). Examples demonstrate parameter usage concretely.

  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: 'Create a complete section transition in one call' and explicitly contrasts it with individual automation tools ('Replaces 3-5 individual calls'). It identifies the specific resource (section transitions) and the verb (create), and distinguishes itself from related tools like create_filter_sweep and create_volume_fade by framing itself as a composite.

  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 usage context: 'The most common arrangement technique: moving from one section to another' and implies when to use it over manual calls by saying it 'combines multiple automation tools' and 'Replaces 3-5 individual calls'. It doesn't state explicit when-not-to-use scenarios, but the guidance is strong and helps select this tool over alternatives.

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

• mcp_opendaw_create_sequenceA
  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 adds substantial context about how parameters affect behavior (e.g., velocity_decay meaning, unit_index fallback to first AU). However, it does not address side effects like whether notes are appended or replaced, or error conditions when no AU/track is found, leaving some behavioral 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 description is well-structured and every sentence earns its place. It front-loads the core purpose, follows with useful musical context, and then provides a clear, parameter-by-parameter breakdown. This is appropriately sized for a 10-parameter tool with an empty schema.

  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 complex tool with 10 parameters and no annotations, the description is mostly complete: it covers all parameters, provides return value information, and gives musical context. However, it lacks explicit statements about whether the tool creates new regions or appends to existing ones, and how errors are surfaced, leaving minor gaps in a complete mental model.

  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 by explaining every parameter with meaningful detail: patterns, ranges, defaults, and examples (e.g., transposition common values, direction options, velocity_decay semantics). This fully bridges the gap left by 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 opens with a specific verb and resource: 'Create a melodic sequence — repeat a pattern at transposed pitch levels.' This clearly distinguishes the tool from siblings like create_melody or create_ostinato by focusing on transposition as the core operation. The additional musical examples (baroque sequences, jazz ii-V-I chains) reinforce the unique purpose.

  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 context for when to use the tool ('the most fundamental compositional technique'), with genre examples that suggest appropriate scenarios. However, it does not explicitly mention alternatives or when not to use it, so it stops short of full usage guidance.

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

• mcp_opendaw_create_song_structureA
  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. It discloses the main behavior (creating labeled markers at section boundaries), the default bar length (8), and return values (markers with positions and total duration). It also candidly notes the unit_index is unused. It could further clarify whether markers are placed at song start or the playhead, and whether existing markers are affected, but the disclosed information is solid.

  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 efficiently organized: a concise purpose statement, a brief rationale, clearly separated parameter explanations, a return note, and a useful example. Every sentence adds value, and nothing is redundant.

  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 tool is moderately complex with two parameters, one of which requires a structured JSON format. The description covers purpose, parameter semantics, defaults, and return values, making it sufficient for an agent to invoke correctly. It could be more complete by specifying where markers are anchored (e.g., beginning of arrangement) and whether the tool overwrites or appends to existing markers, but overall it provides a strong operational 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 fully compensates. It explains the sections parameter with a precise JSON format, the default for omitted bars, and the meaning of names. It also clarifies that unit_index is ignored. A concrete example is provided, leaving no ambiguity about the expected format.

  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+resource: 'Create song structure markers for arrangement (intro/verse/chorus/bridge/outro)'. It explicitly mentions creating labeled markers at section boundaries, and the claim of reducing '5-10 marker calls to one structured call' differentiates it from the sibling add_marker tool.

  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 clear use case ('enabling agents to reason about song form') and explicitly positions itself as a batch alternative to individual marker calls. It also explains that unit_index is unused 'for API consistency', guiding the agent to ignore it. However, it doesn't explicitly say when not to use it or mention alternative tools for single-marker operations.

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

• mcp_opendaw_create_time_stretched_regionA
  4.5/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 reveals key behaviors: audio plays back at a different speed while syncing to tempo, warp markers are created, and it returns position/duration/playback rate. However, it does not mention prerequisites (beyond sample_id), potential side effects on existing regions, or error conditions, leaving some gaps for an agent to discover.

  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: a one-sentence summary, a contrast paragraph, a clear parameter list, and a return statement. Despite covering 7 parameters, it remains tight and readable. Each section earns its place, with 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?

  For a 7-parameter tool with no annotations, the description covers purpose, usage, parameter semantics, and return values. It even mentions that sample_id comes from mcp_opendaw_load_audio, providing a prerequisite. The presence of an output schema is noted, but since the output schema itself is not shown, the description's explicit mention of return fields is valuable. Minor gaps remain in edge-case behavior, but overall it is quite 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 description must fully compensate. It does: every parameter is explained with types, defaults, and examples (e.g., playback_rate: '1.0 = original, 0.5 = half-speed, 2.0 = double'; transient_mode: '"once", "repeat", or "pingpong"'). This adds substantial semantic meaning beyond the schema's bare titles and 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 opens with a clear, specific action: 'Place a time-stretched audio region on a track.' It explicitly contrasts with the sibling place_audio_region (which uses TimeBase.Seconds), distinguishing its unique behavior of musically-timed regions with warp markers. This gives the agent a precise understanding of what the tool does and how it differs.

  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 states when to use this tool: when a time-stretched region should be musically timed with warp markers and stay in sync with project tempo. It names the alternative place_audio_region and explains the difference ('unlike place_audio_region...'), providing clear selection guidance.

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

• mcp_opendaw_detect_bpmA
  4.5/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=true, and the description adds substantial behavioral detail: the algorithm steps (WAV parse, mono mixdown, energy envelope, onset detection, autocorrelation), the 'Pure Python implementation (no external dependencies)' trait, filename resolution rules (exports directory or absolute path), and the return contract (bpm, confidence, onset_count, duration_seconds). No contradiction with annotations.

  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 longer than average but well-structured: purpose sentence, numbered algorithm list, use-case rationale, parameter definition, return values, and a worked example. Each section adds value, though the 4-step algorithm listing is arguably more detail than strictly needed.

  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 analysis tool with readOnlyHint and an output schema, the description is remarkably complete: it covers purpose, input semantics, return values, an end-to-end example, and the motivating scenario. Missing only minor edge-case details like behavior on missing files or low confidence.

  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% — the schema only states 'filename' is a required string. The description fully compensates: 'filename: Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.' It also shows usage in the example (detect_bpm("suno_track.wav")), removing all ambiguity.

  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 states a specific verb+resource: 'Detect BPM (tempo) of an exported WAV file using onset detection + autocorrelation.' This clearly distinguishes it from siblings like set_bpm (which sets tempo) and get_tempo_at (which queries project tempo).

  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 use case: 'Essential for Suno integration: Suno generates at its own BPM, but the openDAW project needs matching tempo. Detect → set_bpm for correct beat alignment when placing stems.' It names a downstream workflow but does not explicitly state when NOT to use this tool or name alternative detection tools.

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

• mcp_opendaw_detect_frequency_maskingA
  4.5/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description explains the internal behavior: it compares spectral content of exported stems pairwise, computes specific outputs (overlap_score, conflict_bands, severity, recommendation), and returns a prioritized list. It also notes the prerequisite that the stems must already be exported, adding useful operational context.

  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 bit long but well-structured: a clear purpose statement, contextual examples, a detailed parameter explanation, and a usage example. Every section earns its place, with no redundant filler aside from the mildly rhetorical 'The #1 mix problem' line.

  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 complexity and the existence of an output schema, the description is complete: it explains the purpose, the required parameter format, the prerequisite (export stems), the outputs, and an end-to-end example. It leaves no major gaps 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?

  The schema only specifies filenames as a string with no description, but the description thoroughly explains the accepted formats (JSON array or comma-separated list), provides concrete examples, and clarifies that the files must be in the exports dir. 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 the tool's function: 'Detect frequency masking between stems — where instruments compete for the same frequency range.' It is specific about the resource ('stems') and distinguishes this pairwise analysis tool from siblings like analyze_spectrum or detect_problems by focusing on inter-stem conflicts.

  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 context for when to use it ('The #1 mix problem') and gives an example workflow (export stems first, then call this). It does not explicitly name alternatives or state when not to use it, but the context is sufficient for an AI agent to infer appropriate usage.

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

• mcp_opendaw_detect_keyA
  4.5/5.0
  Behavior4/5

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

  The annotation readOnlyHint=true is consistent with the description. The description adds significant behavioral context: pure Python implementation, no external dependencies, and a step-by-step algorithm (FFT, chroma, correlation). It also details the return fields, going beyond the annotation's safety profile.

  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 lengthy but well-structured, starting with the core purpose, then algorithm, use case, parameter, and return format. The numbered algorithm steps could be trimmed but add transparency. Examples at the end are useful.

  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 description covers input, output, use case, and algorithm. It even includes an example result. With a single parameter and an output schema, this is complete for an agent to select and 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?

  The schema has only one parameter 'filename' with no description, so the description carries full burden. It fully explains: 'Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.' This provides clear semantics 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 clearly states the tool's function: 'Detect musical key and mode of a WAV file using chroma features + Krumhansl-Schmuckler key profiles.' This is a specific verb+resource+method, distinguishing it from sibling tools like detect_bpm and analyze_track.

  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 use case: 'Essential for Suno integration: detect key → build matching chord progression → create_harmonic_arrangement that fits the imported audio.' It also places it in a remix pipeline. However, it does not explicitly name alternatives or when-not-to-use, stopping 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.

• mcp_opendaw_duplicate_audiounitA
  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 discloses that audio regions reference the same audio files (shared resources), and explicitly lists what gets copied (instrument, effects, tracks, regions, notes, automation). It also states it 'Creates a new audio unit', implying the original remains. However, it does not mention whether sends, bus assignments, or track ordering are included, nor any side effects like undo behavior, leaving some 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?

  The description is well-structured with a front-loaded summary followed by a detailed bullet list of copied components. Every bullet adds distinct, useful information, and the parameter explanation is included inline. There is no filler or redundant content, making it appropriately sized for the complexity of the operation.

  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 complexity of duplicating an audio unit, the description is quite thorough, covering most major components and explicitly noting that audio files are shared references. However, it omits certain aspects that might be relevant (e.g., sends, bus routing, track order), making it not fully exhaustive. The presence of an output schema (though not shown) and the return statement help complete the picture.

  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 only one parameter, unit_index, with no description. The tool description compensates completely by stating 'unit_index: Source audio unit index to duplicate.', giving clear semantic meaning. This fully covers the parameter despite 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 the tool 'Duplicate an audio unit with all its content' and enumerates the exact components (instrument, effects, tracks, regions, notes, automation). This specific verb+resource combination distinguishes it from sibling tools like duplicate_region or duplicate_notes, which target only subsets of content.

  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 implicitly conveys when to use this tool: when you need a full audio unit duplication rather than a selective copy. It clearly scopes the operation to 'all its content' and lists what is copied, providing clear context. However, it does not explicitly mention alternatives or exclusion cases (e.g., 'use duplicate_region for single regions'), so it falls short of a perfect 5.

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

• mcp_opendaw_duplicate_automation_eventA
  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 full burden. It discloses key behavior: copies event's position, value, and interpolation, can offset position and override value, and returns the new event's position and value. It does not mention error conditions or edge cases, but for a duplication operation, 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 concise and well-structured: a clear summary followed by a compact parameter breakdown. Every sentence provides valuable information without redundancy. It is appropriately sized for the tool's complexity.

  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 the operation's purpose, parameter semantics, and return value, making it quite complete for a duplication tool. It does not explicitly discuss prerequisites (e.g., existing event) or failure modes, but given the simplicity of the operation, this is a minor gap. The presence of an output schema is not seen, but the description mentions the return.

  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. It explains all 6 parameters explicitly: coordinate indices, event_index, position_offset in PPQN, and value_override with valid range and semantics. This is thorough and adds significant meaning beyond the bare schema titles.

  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 operation ('Duplicate an automation event within the same region') with a specific verb and resource. It details what is copied (position, value, interpolation) and distinguishes it from related tools like move, update, or delete operations on automation events.

  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 context for when to use this tool: duplicating an automation event in the same region, with optional offsetting and value overriding. It does not explicitly name alternatives or exclusions, but the operation is self-explanatory given the sibling tool names and its own behavior description.

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

• mcp_opendaw_duplicate_note_regionA
  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 and handles it well: it states that the operation copies the region and all its notes, implying non-destructive behavior, and explains the return value (new region index). It does not cover error cases or permissions, but for a duplicate action 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 well-organized: a one-line summary, followed by behavioral detail, use case, parameter list, and return value. Every sentence is informative, and it is neither too short nor too verbose.

  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 four-parameter tool with an output schema, the description covers purpose, behavior, parameters, and return value, meeting the minimum for correct invocation. It could explicitly note differences from similar tools (e.g., duplicate_region) and potential side effects, but the current content is 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?

  The description offers detailed explanations for all four parameters, including special values (unit_index=-1) and an example for offset_beats. Since the schema coverage is 0%, this fully compensates and provides beyond-schema meaning.

  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's function with a specific verb ('Duplicate'), a resource ('note region'), and a behavior (copies region and notes to offset_beats). It differentiates from sibling tools like duplicate_region by emphasizing note region and new position, and the repeating-pattern example reinforces the purpose.

  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 'Useful for repeating patterns' line provides a clear use case and example, giving contextual guidance. However, it does not explicitly exclude alternatives or mention when not to use it, though the note-region specificity implicitly narrows its scope.

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

• mcp_opendaw_engine_panicA
  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 burden of behavioral disclosure. It transparently states the effect: stops all notes immediately, and equates it to a MIDI panic button. It doesn't mention potential side effects on transport or engine state, but the core behavior is well 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 concise and well-structured: three short sentences that front-load the purpose, then add context and equivalence. 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.

  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 the presence of an output schema (which likely covers return values), the description is complete. It explains the action, when to use it, and the immediate effect, making it fully self-contained for a simple no-arg 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 an empty schema, so the baseline for parameter semantics is 4. The description adds no parameter-specific info because none 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 clearly states the action: 'Send a panic signal to the engine — stops all notes immediately.' This uses a specific verb (send panic) and resource (engine), and distinguishes it from sibling tools like engine_sleep or transport, which have different purposes.

  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 explicit guidance on when to use: 'Useful when audio gets stuck (hanging notes, frozen synthesis).' While it doesn't name alternatives, the context is clear enough for this niche panic-button tool.

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

• mcp_opendaw_engine_wakeA
  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 disclosure burden. It clearly indicates the state transition ('wake from sleep') and the consequence ('resumes audio processing'). It does not cover edge cases like behavior when already awake, but for a zero-parameter wake operation 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 two sentences with the primary action in the first sentence and the usage tip in the second. 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 zero-parameter state-transition tool, the description covers the action, the result, and the usage trigger. An output schema exists, so return values do not need to be explained. The sibling context further confirms the pairing with engine_sleep.

  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 and schema description coverage is 100%, so the baseline is 4. The description correctly does not invent parameter details since there are none.

  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 ('wake') and resource ('audio engine'), and further clarifies the result ('resumes audio processing'). This clearly distinguishes it from sibling engine tools like engine_sleep and start_engine.

  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 when to use the tool: 'Use after sleep() when audio playback is needed again.' This is clear contextual guidance, though it does not mention when not to use it or name alternatives beyond the implicit sleep() pairing.

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

• mcp_opendaw_extract_motifsA
  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 full burden. It explains key behavioral details: motifs are key-transposed equivalently identified by interval contour, results sorted by significance, and the return list contents. It implies a non-destructive analysis operation through 'Extract' and 'Returns list'.

  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 main purpose, followed by a useful conceptual explanation, a concise use-case list, and a clear parameter listing. Every section adds value and the formatting makes it easy to scan.

  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 7-parameter tool with no annotations, the description covers the essential aspects: purpose, algorithm, parameter semantics, and return values. It does not discuss edge cases or error conditions, but the presence of an output schema and the straightforward nature of the extraction keep this from being a serious 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?

  Schema description coverage is 0%, but the description lists all 7 parameters with clear meanings and defaults. It explains the -1 sentinel values for unit/track/region indices and specifies min/max motif length ranges. 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.

  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: 'Extract repeating melodic motifs from a MIDI region.' It clearly defines what a motif is (short melodic phrase identified by interval contour) and distinguishes itself from sibling tools like extract_rhythm or create_motif_variations by focusing on analysis and pattern discovery.

  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 use-case guidance with 'Essential for: understanding melodic structure...', 'finding repetitive patterns for variation', etc. It does not explicitly mention when not to use or name alternative tools, but gives enough context to select it appropriately among the many sibling tools.

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

• mcp_opendaw_get_bar_intervalA
  4.5/5.0
  Behavior4/5

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

  The readOnlyHint annotation already signals that this is a safe read operation. The description adds valuable behavioral context by specifying the return values (bar_start, bar_end, bar_length, time signature) and clarifying the PPQN unit. No contradiction with annotations 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 exactly four short, focused sentences: purpose, use case, parameter, and output. It is front-loaded with the most critical information and contains zero redundant 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 simple getter tool with one parameter and an output schema, this description covers all necessary aspects: what it does, when to use it, what input it expects, and what it returns. The readOnly annotation and output schema complete the picture, making it sufficient for an agent to select and invoke 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?

  Schema description coverage is 0%, so the description compensates by defining 'position_ppqn: Position in PPQN.' This adds the crucial unit and clarifies the parameter's role, though it could go further with range details or examples. The single parameter is adequately explained.

  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 ('Get') and resource ('start and end PPQN of the bar containing the given position'), clearly distinguishing it from siblings like ppqn_to_seconds or get_tempo_at. The purpose is unambiguous and names the exact output.

  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 second sentence provides a clear use case: 'Useful for snapping regions, clips, and events to bar boundaries.' This gives the agent context for when to invoke this tool, though it does not explicitly mention alternatives or exclusions, so it falls one point 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.

• mcp_opendaw_get_sample_infoA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description adds value by explaining what metadata is returned (sample rate, channels, frames, loading state) and that an error is returned if the sample is not found. This gives useful behavioral context beyond the annotation.

  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 concise sentences, front-loaded with the core purpose, and every sentence contributes necessary information 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 simple read-only getter with one parameter and an existing output schema, the description fully covers the purpose, parameter source, return fields, and error behavior. No important information 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 provides no description for sample_uuid (0% coverage), but the description compensates by explaining it is the UUID of the audio sample and references list_samples as the source. This is critical guidance for correctly supplying the 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 specific verb 'Get' with a clear resource 'audio sample' and specifies metadata retrieval by UUID. It distinguishes itself from sibling tools like get_audio_file_info by focusing on sample metadata and naming sample-specific return fields.

  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 user where to obtain sample_uuid ('from list_samples'), giving clear context on when to use this tool. It does not explicitly name alternative tools or exclusions, but the workflow is clearly implied.

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

• mcp_opendaw_humanize_notesA
  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 full burden. It discloses that the tool applies random deviations, affects notes in scope, uses a seed for reproducibility, and returns per-track note counts. It does not explicitly state whether modifications are in-place or whether undo is available, but it covers the core behavior and parameter effects well.

  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 given the number of parameters. It begins with a clear one-sentence summary, then organized parameter explanations, and a practical example. Each section earns its place, though it could be slightly tightened without losing clarity.

  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?

  With 7 parameters, no annotations, and an output schema present, the description covers behavior, parameter semantics, scope selection, reproducibility, return values, and gives a real-world example. It is essentially complete for an agent to select and invoke the tool correctly, leaving minimal ambiguity.

  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 manually explains every parameter with ranges, examples, and musical meaning (e.g., timing_amount: '0.05 = tight, 0.15 = natural groove, 0.30 = sloppy'). This fully compensates for the lack of schema descriptions and adds significant 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+resource: 'Add human-like variation to existing notes — velocity, timing, duration, and swing.' It clearly distinguishes from siblings by enumerating the exact dimensions modified and explicitly stating scope (all notes in specified track(s)/unit(s) or globally).

  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?

  Clear context is provided: the tool humanizes existing MIDI notes, works on specified tracks/units or globally, and each parameter is explained with example values. However, it does not explicitly mention when to use this tool over alternatives like humanize_pitch or apply_swing, so usage guidance is strong but not fully comparative.

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

• mcp_opendaw_humanize_pitchA
  4.5/5.0
  Behavior3/5

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

  Without annotations, the description carries the burden of behavioral disclosure. It explains that the tool adds random cent offsets based on a seed (reproducible), and it states the return format. However, it does not disclose whether the operation is destructive or how it interacts with the original pitch data (e.g., whether it replaces or offsets), and there is no mention of undo or 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 front-loaded with the core action, followed by a brief context, then parameter docs and examples. The four-bullet 'Useful for' list is concise and practical, and the parameter explanations are dense without padding. It avoids redundancy despite its length.

  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 6-parameter tool with no annotations and no schema descriptions, the description documents all parameters, provides defaults, ranges, return types, and examples. The main gap is the lack of a destructive/undo warning, which would be important for a pitch-modifying operation. The output schema likely covers the return object, so the return description is supplementary.

  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 define the parameters. It does so thoroughly: unit_index/track_index/region_index scoping, cents_depth with levels (3=subtle warmth, 5=natural, etc.), bias with direction, and seed reproducibility. This goes far beyond the schema's bare names and defaults.

  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 micro-detune (cents) to notes — intonation humanization,' using a specific verb and resource, and immediately distinguishes itself from the sibling humanize_notes by noting that 'humanize_notes handles velocity/timing/duration, but pitch stays quantized.' This clearly sets it apart from 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?

  It explicitly names the alternative for velocity/timing/duration (humanize_notes) and provides a 'Useful for' list of concrete scenarios (string sections, vocal MIDI, brass, sterile MIDI). This gives a clear context for when to apply the tool and what it does not do.

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

• mcp_opendaw_list_automation_eventsA
  4.5/5.0
  Behavior4/5

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

  Beyond the readOnlyHint annotation, the description discloses that the tool filters Value-type tracks, returns automation points with specific attributes, and interprets track_index=-1 as 'all tracks'. This adds meaningful behavioral context without contradicting the read-only annotation.

  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 a one-sentence summary, followed by concise explanatory details. It avoids redundancy and every sentence contributes meaningful information. The structure is clean and appropriately sized for the tool's complexity.

  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 what the tool does, parameter semantics, and return value shape. Given an output schema exists and the tool is a simple read-only listing operation, the description provides sufficient context. Minor gaps like error behavior for invalid indices are not critical 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%, but the description fully explains both parameters: unit_index is the audio unit index, and track_index specifies a specific automation track or -1 for all. This compensates entirely 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 clearly states the tool lists automation events (ValueEventBox) on a unit's automation tracks, with specific details about returning position, value, and interpolation type. This distinguishes it from sibling tools like list_automation_events_detail (which likely provides more detail) and get_automation_value (which fetches a single value).

  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 context on how to use the tool: it requires unit_index and track_index, and explains that track_index=-1 selects all automation tracks. Though it does not explicitly mention alternatives or when not to use this tool, the parameter semantics give sufficient usage guidance.

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

• mcp_opendaw_list_genre_profilesA
  4.5/5.0
  Behavior3/5

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

  readOnlyHint=true is already declared, so the read-only behavior is covered. The description adds context about profile contents (LUFS, spectral balance, stereo width, dynamic range), which sets expectations for returned data. It does not contradict annotations, but it doesn't go beyond that to discuss prerequisites or 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 three short sentences with no redundancy. It leads with the purpose, then explains what profiles contain, and finishes with a workflow pointer. 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 simple zero-parameter list tool with an output schema present, the description is complete. It explains the tool's role, the profile definition, and the typical follow-up action. The output schema handles return-value details, so no further description 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 the input schema is fully documented (coverage 100%). Baseline 4 applies, and no additional parameter semantics are necessary or 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 uses a specific verb ('List') and resource ('genre reference profiles'), and clarifies the purpose ('for mix analysis'). It clearly distinguishes itself from sibling tools like compare_to_profile and analyze_mix by indicating this is the listing operation.

  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 directs the agent to 'Use compare_to_profile() to check your mix against any of these,' providing clear guidance on when to use which tool. This is an explicit alternative/next-step reference, matching the high-scoring pattern from the calibration example.

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

• mcp_opendaw_list_markersA
  4.5/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint=true, and the description reinforces this by using 'List'. It adds that the output includes positions and labels, which is useful behavioral context about the result contents. No additional limitations or side effects are disclosed, but for a read-only operation this 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 a single sentence, starting with the action verb, and includes only necessary information about scope and output. No 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?

  Given the tool's minimal complexity (no parameters), existing readOnly annotation, and presence of an output schema, the description fully covers what the agent needs to know: it lists all timeline markers with their positions and labels. No additional context 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?

  With zero parameters, the description is not required to add parameter semantics. The schema is empty, and the description correctly mentions no inputs 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 specifies the verb 'List', the resource 'timeline markers', and the scope 'all', with the output content 'positions and labels'. This clearly distinguishes it from sibling marker tools like add_marker, delete_marker, and list_warp_markers.

  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 a read-only usage context but does not explicitly state when to choose this over alternatives such as list_warp_markers or list_automation_events. No exclusion criteria are provided, but the simplicity of the tool 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.

• mcp_opendaw_list_modular_devicesA
  4.5/5.0
  Behavior4/5

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

  The annotation readOnlyHint=true already signals safety. The description adds useful behavioral context by explaining the return payload (AU index, label, module/connection counts) and defining what a Modular device is. This goes beyond annotation coverage without contradicting it.

  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 concise sentences with the primary action front-loaded. The first sentence states the function, the second summarizes the return, and the third provides necessary domain context. 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?

  The tool is simple (no params, read-only, has output schema). The description covers the purpose, return data, and domain definition sufficiently for an agent to select and invoke it. No gaps remain for this low-complexity 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 0 parameters, so schema coverage is trivially 100% and the baseline is 4. The description adds scope details ('all', 'in the project') that clarify the implicit result set, which is valuable since there are no parameters to constrain the query.

  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 'List all Modular audio effect devices in the project' – a specific verb ('List') and resource ('Modular audio effect devices') with explicit scope. It distinguishes this from sibling tools like list_modular_modules and list_modular_connections by focusing on devices as higher-level units.

  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 clear context: use this to enumerate all Modular devices in the project. It doesn't explicitly mention alternatives or exclusions, but the scope is unambiguous and no competing tool serves this exact purpose among the siblings.

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

• mcp_opendaw_list_sendsA
  4.5/5.0
  Behavior4/5

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

  With readOnlyHint=true in annotations, the safety profile is already disclosed. The description adds value by specifying the return shape (send_index, target_bus_name, send_level_db, routing) and confirms the read-only nature by saying 'List all'. No contradictions found.

  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 main action, followed by parameter explanation and return format. Each sentence serves a purpose with no unnecessary 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?

  Given the tool's simplicity (one parameter, one action) and the presence of an output schema, the description fully covers the purpose, parameter meaning, and return content. It is complete and self-contained.

  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 the type and name for unit_index, with 0% description coverage. The description compensates by stating 'Audio unit index to inspect', providing the necessary semantic context for 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 clearly states 'List all aux sends on an audio unit' — a specific verb, resource, and scope (the audio unit). It distinguishes itself from sibling tools like create_send or set_send_level by focusing on listing, and from list_audio_buses by referencing sends rather than buses.

  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: it lists sends on a given audio unit. It does not explicitly name alternatives or exclusion conditions, but the operation is self-evident and complements the related send-management tools.

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

• mcp_opendaw_list_tempo_changesA
  4.5/5.0
  Behavior4/5

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

  The readOnlyHint annotation already declares the safe read-only nature, and the description adds useful behavioral context beyond that: it explains the return fields (position, BPM, interpolation type) and the normalized value mapping (minBpm..maxBpm, default 60..240). This goes beyond a bare 'list' statement and aids interpretation.

  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, front-loaded with the action, and contains no fluff. Every sentence adds meaningful information: the first states what it does, the second details the return values and a critical normalization caveat.

  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, the presence of an output schema, and readOnlyHint annotation, the description is complete. It covers the essential semantics: what is returned, the units (beats, BPM), and the normalization mapping which is crucial for correctly interpreting the BPM values. No gaps are apparent.

  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 trivially 100%. Per the rubric, 0 params establishes a baseline of 4. The description adds no parameter-specific information because none 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 clearly states the tool lists all tempo (BPM) changes on the timeline's tempo track, using the specific verb 'List' and naming the resource. This distinguishes it from siblings like get_tempo_at (which retrieves a single tempo) and list_signature_changes (which handles a different track type).

  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 context that this tool is for enumerating tempo changes on the timeline, making its usage obvious. It doesn't explicitly mention when not to use it or name alternatives, but the purpose is unambiguous given the sibling tool names (e.g., get_tempo_at vs. list_tempo_changes).

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

• mcp_opendaw_map_velocity_by_pitchA
  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. It reveals the transformation formula, mode differences, intensity effect, clamping behavior, and return summary. It lacks explicit caution about in-place modification or undo behavior, but the algorithm is thoroughly disclosed.

  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 well-structured with sections for modes, formula, use cases, and parameters. It is somewhat verbose and repeats mode and intensity details in the parameter list, but the front-loaded summary and logical organization make it easy to scan.

  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 real complexity (8 parameters, 4 modes, a formula, and multiple use cases), the description is remarkably complete. It covers all parameters, examples, the algorithm, and return value. The presence of an output schema further reduces the need for explanatory detail.

  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 compensates by explaining every parameter including unit_index, track_index, region_index, mode, intensity, min/max_velocity, and pitch_ref. It even includes the formula showing how parameters interact, exceeding what 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 clearly states the tool maps velocity based on pitch with a specific verb and resource ('Map velocity based on pitch'). It distinguishes itself from sibling velocity tools like scale_velocity or apply_velocity_curve by emphasizing the pitch-velocity relationship and natural acoustics.

  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 use cases such as piano/orchestral mockups, drum kits, lead synth, and vocal range emphasis. However, it does not name alternative tools or state when not to use this tool, so it falls short of explicit exclusions.

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

• mcp_opendaw_match_to_referenceA
  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 transparency burden. It discloses the algorithmic steps, the fact that it outputs a new WAV file, and labels stereo matching as 'experimental.' It doesn't mention whether the original mix is preserved or if any DAW-specific prerequisites exist, but the core behavior (gain, EQ, stereo adjustments) is transparently explained.

  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 one-sentence summary, numbered algorithmic steps, a parameter list, return description, and an example. Each section earns its place without redundancy. The formatting with line breaks and code-style example enhances readability.

  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 the essential: purpose, process, parameters, output, and return value, even including an example return object. It lacks explicit mention of prerequisites (e.g., DAW engine running, supported file formats) and edge-case behavior, but given the presence of an output schema and the tool's focused scope, it is sufficiently complete for an agent to select and 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?

  The schema has 0% description coverage, but the description compensates admirably by explaining each parameter: filename, reference, output_filename (with default), and the three boolean toggles with their effects (e.g., 'Match per-band spectral energy (7-band EQ correction)'). It also provides a concrete example call with expected return shape, fully clarifying parameter 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 opens with a specific verb-resource statement: 'Automatically match your mix to a reference track — spectral + loudness alignment.' It then details three concrete processing steps (LUFS gain, EQ correction, optional stereo adjustment) and states the output is a matched WAV. This clearly distinguishes it from sibling tools like compare_to_reference, which likely only analyzes without modifying.

  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 usage for automated A/B matching without re-mixing, and explicitly mentions optional stereo matching. It also references 'Like Phantom's match_to_reference' as a conceptual precedent. However, it does not explicitly name alternative tools (e.g., compare_to_reference for analysis-only) or state when NOT to use it, leaving a small gap in exclusions.

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

• mcp_opendaw_move_effectA
  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. It discloses key behavioral traits: the reordering nature, 0-based indexing, and the fact that effects between from and to shift accordingly. It doesn't mention error handling or idempotency, but the core behavior is well-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 and front-loaded with the main purpose. The chain-order example earns its place, and the parameter list is integrated cleanly. 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?

  Given the tool's simplicity and the presence of an output schema, the description is quite complete. It covers parameters and behavior well. Minor omissions like out-of-bounds handling or what happens when from_index equals to_index prevent a perfect score, but these are 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 compensates fully by explaining each parameter: unit_index, from_index, and to_index, including their 0-based nature. This adds crucial meaning beyond the bare integer titles in 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 clearly states the tool's function with a specific verb and resource: 'Reorder an effect within an audio unit's effect chain.' It also distinguishes from siblings like add_effect or remove_effect by focusing on reordering, and provides a concrete example of chain-order importance.

  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 when to use the tool ('Use this to move effects to the desired position') and explains why ordering matters. It doesn't explicitly mention alternatives or when not to use it, but the context is sufficient for most agents to select it over siblings.

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

• mcp_opendaw_note_statsA
  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 bears full responsibility for behavioral disclosure. It goes beyond a simple statement by enumerating the exact statistics returned (note count, pitch range, velocity stats, density, pitch class histogram, etc.) and showing an example output shape. It implies read-only behavior via 'Get statistics' but doesn't explicitly state that no modifications occur. It also doesn't mention edge cases like empty regions or invalid indices, but for a stats tool this level of detail is strong.

  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 structured with a clear introductory sentence, a bullet list of statistics, a compact 'Useful for' list, parameter definitions, and a short example. It conveys substantial information without being bloated. The bullet lists are easy to scan and every sentence carries meaning. It is slightly longer than necessary but well organized.

  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 moderate complexity, the description is complete. It covers purpose, output contents, use cases, and all parameters. The output schema (statistics object) is supplemented by the detailed field list in the description, making return values clear. No critical information about when or how to use this tool 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 has 0% parameter description coverage, leaving the description to explain all parameters. The description explicitly covers each parameter: 'unit_index: AU index. track_index: Note track index. region_index: Region (-1 = first region).' This fully compensates for the schema gap and adds clarity beyond the bare integer types. The example call also helps clarify usage.

  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: 'Get comprehensive statistics for notes in a region.' It clearly identifies the tool's function as a read-only analysis operation on MIDI note content. The scope is precise and distinguishes it from sibling tools like analyze_melody or analyze_track, which target different aspects.

  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 'Useful for' list that gives clear context for when to use the tool (analyzing imported MIDI, comparing regions, identifying register, detecting programming issues). It doesn't explicitly state when not to use it or mention alternative tools, but the use cases strongly imply appropriate scenarios. It lacks exclusionary guidance like 'use X instead for Y', but the guidance is sufficient for a selectable tool.

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

• mcp_opendaw_ppqn_to_secondsA
  4.5/5.0
  Behavior4/5

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

  With no annotations, the description must carry the burden. It does so by revealing that conversion integrates over tempo change events and defining the PPQN unit (960 pulses per beat). It also notes the return type and potential error. It could mention edge cases or lack of side effects, but the key behavioral nuance 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?

  Three short, focused paragraphs: the action, the tempo-automation context, and the parameter/return specification. No fluff, and each sentence adds value. The example and unit definition are compact.

  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 conversion tool with an output schema, the description explains the conversion logic, the tempo-map behavior, parameter semantics, and return type. It could explicitly mention the inverse tool or edge cases (e.g., negative positions), but the available information is sufficient for an agent to invoke it correctly in most scenarios.

  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 provides merely 'position_beats' as a number. The description adds that it is a float in beats, gives an example (4.0 = beat 4), and clarifies its semantic position. With 0% schema coverage, this fully compensates and exceeds the baseline.

  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 opening sentence 'Convert a position in beats (PPQN units) to seconds using the project's tempo map' uses a specific verb and resource, clearly distinguishing it from the sibling inverse tool `mcp_opendaw_seconds_to_beats`. The scope is defined precisely.

  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 conversion accounts for tempo automation and integrates over tempo changes, giving clear context for when this tool is necessary (accurate conversion in a non-constant tempo timeline). However, it does not explicitly name alternatives or state when not to use it, so it falls short of full usage guidance.

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

• mcp_opendaw_randomize_note_durationsA
  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 full burden. It explains distribution modes, variation interpretation, preserve_total scaling, and seed reproducibility. However, it does not explicitly state that the operation modifies note data in place, whether it is reversible, or what happens to notes outside the region/selection — gaps for a mutating tool with no 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?

  The description opens with a one-sentence summary, adds a distinguishing comparison paragraph, and then a well-structured Args list where each parameter gets one concise line. 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?

  The tool has 9 parameters and a complex domain (distribution modes, beat bounds, total preservation), and the description covers all of them with examples and semantics. It omits explicit mutability/undo warnings, and return values are covered by the output schema, so the remaining gap is 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%, and the description fully compensates by explaining every parameter: unit_index, track_index, region_index with default interpretation, variation with examples, all 5 distribution modes with one-line definitions, min/max duration with beat examples, preserve_total semantics, and seed 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 first sentence 'Randomize note durations with controllable distribution' provides a specific verb and object, and the description explicitly contrasts with 'humanize_notes (which adjusts timing+velocity)' and enumerates 5 distribution modes, clearly differentiating it from 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 Guidelines5/5

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

  It explicitly names 'humanize_notes' as the alternative and contrasts the focus ('purely on duration' vs timing+velocity), telling the agent when to choose this tool for duration-based variation. It also gives context for generative variation, making the usage clear.

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

• mcp_opendaw_remix_trackA
  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 and does well by disclosing the exact ordered steps (analyze_track, set_bpm, import_audio_to_tracks, etc.), conditional stem separation, and return contents. It lacks explicit error behavior, idempotency, or whether existing project state is cleared, so it is not perfect.

  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 well-structured with an overview, numbered step list, parameter definitions, returns, and an example. There is minor redundancy between the opening pipeline phrase and 'One call replaces 8-10 individual tool calls,' but the length is justified for an 8-parameter complex tool.

  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 description covers all essential dimensions: when to use, what the pipeline does step-by-step, all parameter semantics, return values, and a concrete usage example. Given the tool's complexity and lack of annotations, this is 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%, but the description compensates fully with a dedicated parameter list defining every parameter with concrete examples and defaults: genre examples, stem_mode choices ('bs2', 'bs4', 'bs6'), master_lufs targets (-14 Spotify, -10 loud), and boolean semantics. This is excellent compensation.

  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 'Full Suno remix pipeline in one call — analyze → import → harmony → mix → master', clearly identifying a specific composite verb+resource. It distinguishes itself from granular siblings by stating 'One call replaces 8-10 individual tool calls,' making its unique pipeline role 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 states input context ('Takes any audio file (from download_audio or local)') and provides a clear follow-up workflow ('call render_full to export'). It implicitly guides usage via 'One call replaces 8-10 individual tool calls', but does not explicitly name alternatives or 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.

• mcp_opendaw_rename_unitA
  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 behavioral disclosure burden. It transparently states that the tool 'sets both' label and icon, that empty name/icon values cause a skip, and that it 'Returns old and new name/icon'—revealing the mutation and feedback behavior. It doesn't discuss error handling for invalid indices or permissions, but the core behavior is well 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: a one-sentence summary, followed by necessary context about InstrumentBox, then a concise parameter list with constraints, and a note about return values. Every sentence earns its place; no redundancy 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 tool, the description is quite complete: it covers the operation, constraints, parameter semantics, and return values. An output schema exists, and the description also mentions the return. It doesn't specify behavior for non-existent unit indices, but the 'must be >= 1' constraint implies the expected usage. Minor gap, but overall very thorough.

  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 for parameters, but the description fully compensates. It explains each parameter precisely: unit_index must be >= 1 and cannot be the output AU, name is a display name with empty=skip, and icon is a symbol with empty=skip and examples ('piano', 'guitar', 'drums'). This adds meaning far 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 clear, specific verb+resource: 'Rename an audio unit's instrument and optionally set its icon.' It further clarifies the scope by explaining that Instrument AUs have a label and icon on their InstrumentBox, and that both are set. This distinguishes it from sibling tools like set_device_label or replace_instrument by focusing on the instrument's display name and icon.

  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 context for when to use the tool: renaming an instrument AU's label/icon. It explicitly states a when-not condition: 'The output AU (index 0) has no instrument and cannot be renamed,' and adds the constraint that unit_index must be >= 1. However, it does not name alternative tools for other scenarios, 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.

• mcp_opendaw_render_fullA
  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 transparency burden. It discloses the internal rendering mechanism (OfflineEngineRenderer with Option.None), the exact time range rendered, and the return payload (path and audio metadata). It does not mention potential side effects like file overwriting, but for a render operation this is solid 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?

  The description is tightly structured: a one-sentence purpose, a brief parameter list, and two implementation/behavior details. Every sentence adds value, 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.

  Completeness5/5

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

  The description covers the purpose, both parameters with usage semantics, the exact render range, the rendering engine used, and the return format. With an output schema available for the return value, this is a complete and self-contained description for a two-parameter 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 schema provides defaults for both parameters, but the description adds value by clarifying that filename should be given without the .wav extension and restating the default sample rate. This helps the agent avoid common errors, going 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 opens with a specific verb+resource+scope: 'Render the entire project as a single stereo WAV file (full mixdown).' This clearly distinguishes it from range renders, stem exports, and other audio export tools by emphasizing the full mixdown scope and single-file output.

  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 renders the full project from beat 0 to the last region, and is intended for a full mixdown. However, it does not explicitly name alternative tools (e.g., export_mix, render_range) or state when not to use it, so it stops short of a full usage guide.

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

• mcp_opendaw_save_projectA
  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. It discloses the serialization process (boxGraph to ArrayBuffer), the output format (.odaw), the save location (exports directory), and return values (file path, size, box count). It does not mention potential overwrites or errors, but the provided details go well beyond a minimal description.

  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 main action sentence, a short technical explanation, a cross-reference to load_project, and explicit parameter/return notes. 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 tool with one parameter and no nested objects, the description is complete. It covers what the tool does, what data it serializes, where it saves, what the filename parameter means, and what it returns. The existence of an output schema further reduces the need to explain return structure in prose.

  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 lists 'filename' with type string and no description. The description adds crucial meaning: 'Name for the saved project (without extension).' This clarifies that the extension is added automatically, which is essential for correct usage. For a single-parameter tool, 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 the action ('Save the current project state to a binary file'), specifies the resource (boxGraph with all tracks, regions, effects, notes, settings), and differentiates from siblings by mentioning the .odaw format and exports directory. It also explicitly references load_project, distinguishing it as the saving counterpart.

  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: use this to persist the entire project for later restoration, and explicitly mentions 'Use load_project to restore later.' It does not enumerate exclusions or compare with other export tools, but the context is specific enough for an agent to choose it over alternatives like export_midi or export_mix.

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

• mcp_opendaw_set_effect_parameter_intA
  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 full behavioral disclosure burden. It adds useful context by listing the covered fields, flagging the Delay 'version' field as internal, and clarifying its fallback status. However, as a mutating tool it does not disclose error behavior when parameter_name is invalid, whether changes are reversible/undoable, or range validation on the integer value — gaps that matter without annotation support.

  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: a one-sentence purpose, a compact bulleted list of covered fields, an explicit usage note, and a short parameter legend. Every sentence adds distinct value — the coverage list, the sibling-precedence note, and the 0-based clarification are all non-redundant.

  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 annotations and an output schema, the description covers purpose, scope, alternatives, and all parameter meanings — quite thorough. The main missing piece is error/edge-case behavior (e.g., what happens with an unknown parameter_name or out-of-range value), which keeps it from being 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 description must fully compensate. It does so by explaining all four parameters, including the crucial clarification that effect_index is 0-based, concrete examples for parameter_name ('bandCount', 'bits', 'overSampling'), and the basic meaning of value and unit_index. This substantially exceeds the bare schema titles.

  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 statement ('Set an integer parameter on an audio effect') and goes further by enumerating exactly which device-specific integer fields it covers (bandCount, panningMixing, overSampling, bits, version). It also distinguishes itself from the generic float setter and the dedicated device-specific setters among its siblings, so an agent can unambiguously identify its role.

  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 explicit guidance: device-specific tools (set_vocoder_band_count, set_fold_oversampling, etc.) are preferred when available, and this tool is a generic fallback for any Int32Field. It also explains what it covers versus the generic float setter, clearly stating when to use this tool and when to choose an alternative.

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

• mcp_opendaw_set_time_stretch_centsA
  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 and does well: it discloses clamping ('Range: -1200 to +1200 cents (clamped)'), the need for prior time-stretch creation, and the return value ('Returns new playback rate and cents, or error'). It doesn't mention reversibility or side effects beyond the set operation, 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?

  The description is tightly organized: a one-sentence purpose, a units/range sentence, a prerequisite line, a labeled parameter list, and a return-value line. No wasted words; every sentence adds value and key details 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 4-parameter mutating tool with no annotations, the description covers purpose, prerequisite, parameter semantics, range, and return value. It could go deeper on error scenarios (e.g., what exactly fails) or whether prior values are overwritten, but these are minor gaps. The presence of an output schema (not shown) likely covers return formatting details.

  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 provides no description coverage, so the description fully compensates by explaining each parameter: 'unit_index: AU index', 'track_index: Track index within the AU', 'region_index: Audio region index', and 'cents: Pitch shift in cents (-1200 to +1200)'. This adds critical meaning well 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 states a specific action ('Set the pitch shift') and identifies the target resource ('time-stretched audio region'), distinguishing it from siblings like set_note_cents or create_pitch_stretched_region. The phrase 'pitch shift (in cents)' is precise and semantically 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 explicitly states a prerequisite ('Only works on time-stretched regions') and references the creating tool ('created with create_time_stretched_region'), which indirectly warns against using it on other region types. It also gives the valid range and clamping behavior. However, it does not name specific alternative tools for non-time-stretched regions, so it stops short of full comparative guidance.

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

• mcp_opendaw_set_unit_minimizedA
  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 full burden. It adds the behavior that returns include old and new minimized state, and explains the effect of the boolean parameter. It omits edge cases and side effects, but the tool's scope is narrow and the behavior is adequately disclosed for a UI toggle.

  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 a purpose statement. Each additional sentence adds value: rationale for the feature, parameter semantics, and return behavior. 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?

  For a simple setter with a narrow scope, the description covers what it does, when it's useful, what each parameter means, and what it returns. The presence of an output schema (even if not visible) reduces the need to describe the return structure. Minor details like error handling are omitted but are not critical for this UI toggle.

  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 types/titles; the description adds the missing semantic for both parameters: unit_index as 'AU index' and minimized as 'True to minimize, False to expand.' This 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 opens with a specific verb phrase 'Minimize or expand an audio unit in the mixer view,' clearly identifying the action and resource. It also distinguishes itself from sibling mixer/setter tools by focusing on the audio unit's minimized state rather than volume, effects, or track parameters.

  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 clear use case ('useful for decluttering when working with many tracks') but does not explicitly state when to avoid using it or mention alternative tools. This is contextual guidance without exclusions, so it earns a 4 rather than a 5.

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

• mcp_opendaw_transcribe_melodyA
  4.5/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 full burden and largely succeeds: it details the complete 6-step pipeline (WAV parsing, pitch detection, frequency-to-MIDI conversion, note grouping, velocity estimation, and note creation), mentions BPM auto-detection, and discloses the return summary. It does not state whether existing notes on the target track are overwritten or appended, which is a notable omission 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.

  Conciseness4/5

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

  The description is well-structured with sections for overview, pipeline, use cases, parameters, returns, and examples. It is somewhat long but each section serves a purpose; no filler. It could be tightened, but the structure helps the agent parse it quickly.

  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 complexity (audio processing pipeline), no annotations, and a schema with zero parameter descriptions, the description is remarkably complete. It covers the entire workflow, parameter meanings, return values, and includes usage examples. The only minor gap is the effect on existing track data, but overall it fully supports agent 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 schema has 0% description coverage (only titles like 'Filename'), so the description must explain each parameter. It does so thoroughly: 'filename: WAV file name (in exports dir) or absolute path', 'bpm: Tempo for beat conversion (0 = auto-detect via detect_bpm)', and clearly explains unit_index and track_index as targets. This fully compensates for the sparse 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 opening line clearly states the tool's purpose: 'Transcribe monophonic melody from an audio file into MIDI notes on a DAW track.' It specifies the resource (audio file), action (transcribe to MIDI notes), and destination (DAW track), and the use cases (bass line, vocal, horn) further distinguish it from siblings like transcribe_drums.

  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 this is for monophonic melody transcription and provides concrete use cases (e.g., 'Extract a bass line from a Suno track'). It implies not for polyphonic audio or drums but does not explicitly name alternative tools or state exclusions, which is a minor gap.

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

• mcp_opendaw_unfreeze_audiounitA
  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 full burden. It discloses key behavior: removes cached audio, resumes live processing of instruments/effects/sends, and returns success or error. This provides meaningful transparency beyond what the name alone implies.

  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 sentences, front-loaded with the main action, then a concise behavioral breakdown, a parameter explanation, and return value. Every sentence adds value with no 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?

  The tool has a simple single-parameter interface. The description covers purpose, behavioral effects, parameter semantics, and return value. Since an output schema exists, the return value explanation is a bonus. The description is complete for this tool's complexity.

  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 explain the parameter. It does so with 'unit_index: AU index to unfreeze,' which clearly describes the parameter's meaning. For a single integer parameter, this is sufficient, though it could have added context on how to obtain the index.

  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 'Unfreeze a frozen audio unit — resume real-time processing,' which identifies the specific action (unfreeze) and resource (audio unit). It distinguishes from sibling tools like freeze_audiounit and get_unit_freeze_status by describing the exact opposite 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 gives clear context: use this tool when you want to unfreeze an audio unit and resume live processing. It does not explicitly mention alternatives or exclusions, but the 'Unfreeze a frozen audio unit' phrasing clarifies the intended usage scenario.

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

• mcp_opendaw_add_drum_chainA
  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 a good job by detailing the exact signal chain created ('Gate → Revamp EQ → Compressor (→ Reverb)'), the return value ('Returns effect indices and parameter values set'), and the optional reverb behavior. It does not disclose edge cases like invalid unit_index or whether existing effects are preserved, but the level of disclosure is substantially above average.

  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. It uses clear sections for parameters, chain construction, and examples. Every sentence contributes value—no filler—and the code examples at the end effectively illustrate usage patterns.

  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 an output schema and moderate complexity, the description is exceptionally complete: it covers the signal chain, all parameters, presets, return behavior, and provides three usage examples. The only minor gap is lack of error handling details, but that does not detract from overall completeness given the rich 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?

  The schema has 0% description coverage, so the description fully compensates by documenting all three parameters: unit_index as 'Target audio unit', style with five named presets and musical character, and reverb_amount with range and suggested values. It adds semantic richness beyond bare type information, including genre examples for each style.

  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's function with a specific verb and resource: 'Add a ready-made drum processing chain to an audio unit — Gate → EQ → Compressor (+ optional Reverb).' It also distinguishes itself from sibling tools by explicitly mentioning that one call replaces 3-4 individual add_effect + set_effect_parameter calls, making it unique among effect-related 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 provides clear when-to-use context: designed for drum tracks but works on any rhythmic content, and an explicit efficiency advantage over manual effect chaining. However, it does not mention exclusions or alternatives like add_vocal_chain or add_mastering_chain, so usage guidance is strong but not exhaustive.

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

• mcp_opendaw_add_neighbor_tonesA
  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 transparency. It clearly explains the three-part note splitting structure, parameter effects (e.g., neighbor_offset position, min_duration_beats skipping short notes), and cross_track behavior that preserves original notes. However, it does not explicitly state the destructive/reversible nature of the default operation on the source track.

  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: a one-sentence summary, definition, structural breakdown, context, and then a thorough Args list. Every sentence serves a purpose—the music theory context and usage examples help the agent select the tool, while the Args section adds essential semantics not found in the schema. No redundancy or 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?

  This is a complex 11-parameter tool with no annotations or schema descriptions. The description covers the algorithm, all parameter semantics, behavioral nuances (skipping short notes, cross-track placement), and musical context. Since an output schema exists, the lack of return-value explanation is acceptable. The description is complete enough for correct selection and 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 schema provides no parameter descriptions (0% coverage), but the description's 'Args' section compensates exceptionally well. Every parameter is explained with ranges, defaults, and musical reasoning (e.g., neighbor_velocity: 'default 0.6 — softer than the main note, as is traditional for ornaments'). This is more than sufficient for an agent to understand each parameter's meaning.

  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: 'Add upper/lower neighbor tones to embellish existing notes.' It further distinguishes itself from similar tools by explaining the difference from passing tones and positioning it as the third of four non-chord tone techniques, making it clear which sibling tool this is.

  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 contrasts with passing tones ('Unlike passing tones which connect two different notes, neighbor tones ornament a single sustained note'), giving the agent a clear decision point among ornamentation tools. It also mentions musical styles (Bach, jazz, country) but does not explicitly state when not to use this tool or provide a direct comparison to say add_suspension.

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

• mcp_opendaw_analyze_dynamicsA
  4.6/5.0
  Behavior4/5

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

  The readOnlyHint annotation already declares the tool safe, and the description adds substantial context about the metrics, the 10-segment RMS contour, and compression suggestions. It also clarifies the input format (WAV file in exports directory or absolute path). No contradictions with annotations. A 5 would require even richer operational detail, but this is solid.

  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 structured logically: a one-line summary, a bulleted metric breakdown, compression guidance, argument explanation, and return summary. Every sentence carries useful information—no fluff. Despite length, it is efficiently organized and scannable for an agent.

  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 multi-metric analysis tool, the description covers everything: what the tool does, the meaning of each metric, interpretation thresholds, input specification, and return content. The output schema further enriches context, so the description need not restate structured return types. This is complete for informed selection and 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 has no description for 'filename', but the description fully compensates: 'Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.' It resolves ambiguity about path resolution and file type, adding meaning beyond the schema's bare 'Filename' 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 clearly states the tool performs 'Dynamics analysis' with specific metrics (crest factor, loudness range, transient density, segment RMS) and 'Measures the dynamic character of a track.' This specific verb+resource combination distinguishes it from siblings like analyze_spectrum, analyze_stereo, and measure_lufs.

  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 detailed compression decision guidance with quantitative thresholds (e.g., 'crest_factor < 6 dB → heavily compressed'), which implies when to use the tool for dynamic evaluation. However, it does not explicitly name alternative tools for other analysis types, so it stops short of the 'explicit alternatives' bar for a 5.

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

• mcp_opendaw_analyze_mixA
  4.6/5.0
  Behavior4/5

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

  Annotations provide readOnlyHint=true, and the description adds substantial context: it runs four analysis modules, produces 'prioritized mix_suggestions' and a 'master_check' with platform-specific LUFS targets. This goes beyond the annotation's safety signal, though it doesn't discuss error handling or performance characteristics.

  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: a one-sentence summary, followed by a numbered list of modules, output details, and an Args section. Every sentence provides value, and the formatting makes it easy to scan quickly. 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 complex tool combining four analyses with one parameter and an output schema, the description is thorough. It covers the purpose, the constituent modules, the output (suggestions, master_check, LUFS targets), and the filename parameter. Since an output schema exists, the description doesn't need to detail return fields, and it provides enough context for correct usage.

  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 one parameter (filename) with no description (0% coverage), but the description fully compensates: 'Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.' This clearly explains the format and accepted alternatives, leaving no ambiguity.

  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 it provides 'complete mix diagnosis in one call' by combining track, spectrum, stereo, and dynamics analysis. It distinguishes itself from the individual analyze_* siblings by explicitly listing the four modules it aggregates, making the tool's purpose specific and 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 offers clear guidance: 'The agent can call this single tool instead of 4 separate calls, getting a complete picture for mix decisions.' This implies using it when a holistic analysis is needed and names the individual alternatives, though it doesn't explicitly state when to use the separate tools (e.g., when only one analysis is needed).

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

• mcp_opendaw_apply_genre_humanizationA
  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 transparency burden. It discloses detailed genre-specific behavior (timing/velocity/swing values), track-level effects (drums get most, bass stays tight), and that it returns the applied parameters. It does not explicitly state whether it mutates the actual MIDI notes or how it interacts with prior humanization, but the coverage 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 a clear purpose statement, followed by structured sections: context, genre recipe bullets, parameter list, return value, and a concrete example. It is long, but every sentence contributes necessary behavioral or semantic detail for a complex tool with 7 parameters and 14 genres. Nothing feels redundant.

  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 complexity and the existence of an output schema, the description is remarkably complete. It covers the workflow context (post-arrangement), all parameter semantics, genre-specific recipes, track roles, and provides a usage example. The only minor omission is an explicit prerequisite statement, but the examples and opening context imply it clearly.

  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 compensate — and it does. It explains the genre parameter with an explicit list of allowed values, defines unit_index as 'AU index with the arrangement tracks', interprets the track indices, and clarifies has_4th_track in the context of 3- vs 4-track genres. This adds essential meaning beyond the bare parameter names.

  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: 'Apply genre-aware humanization to arrangement tracks — makes programmed MIDI feel alive.' It clearly distinguishes itself from generic humanization tools (e.g., humanize_notes, apply_swing) by emphasizing genre-awareness and the arrangement-track 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?

  The description provides clear contextual guidance: use it after creating an arrangement because notes are quantized/robotic. Examples explicitly show calls after create_jazz_arrangement and create_dnb_arrangement. However, it does not explicitly name alternative tools to use instead (e.g., humanize_notes) or exclusion cases, so it stops short of perfect guidance.

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

• mcp_opendaw_apply_rhythm_patternA
  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 full responsibility for behavioral disclosure. It describes the note distribution algorithm in detail ('If fewer onsets than notes: extra notes are placed at the nearest onset'), the effects of velocity/duration modes, and notes that it returns 'a modification summary with repositioned note count.' It implies in-place modification by saying 'repositions existing notes.' It does not discuss undo or reversibility, but the level of detail is strong given the lack 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?

  The description is long but every section is purposeful: a summary sentence, numbered algorithm steps, a parameter glossary, and a usage example. It is structured and front-loaded with the one-line purpose, making it easy to scan.

  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 8 parameters and no schema descriptions, the description covers all parameters, behavior, precedence, and an example workflow. It also mentions the return value ('modification summary'), and since an output schema exists, we don't need exact return fields. The only minor gaps are edge cases like empty note regions, which aren't critical for typical use.

  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% coverage, but the description defines every parameter, including default values and precedence (e.g., 'onset_grid: ... Takes priority over rhythm_string'). It explains valid values for velocity_mode and duration_mode with examples, providing far more semantics than the schema alone.

  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 states a specific action: 'Apply a rhythmic pattern to existing notes — reposition onsets to match a target grid.' It also explicitly distinguishes itself from extract_rhythm ('This is the inverse of extract_rhythm'), establishing a clear purpose unique among 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 explains when to use this tool by framing it as the inverse of extract_rhythm, saying it 'lets you stamp a groove onto any note content,' and provides a concrete example workflow ('Extract groove from drums, apply to bass'). It does not, however, list exclusions or alternatives beyond extract_rhythm, so it's 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.

• mcp_opendaw_clone_clipA
  4.6/5.0
  Behavior4/5

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

  The description explains the core behavior: cloning a clip and the optional consolidation that makes the event collection independent (not shared). It also mentions the return value (success or error). While it doesn't cover reversibility or side effects on the original clip, it goes beyond the schema and offers meaningful behavioral insights.

  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 front-loaded: it opens with the main action and then provides a clean, structured parameter list. Every sentence adds value, with no repetition of schema details or unnecessary fluff.

  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 moderate complexity, the description covers the operation, parameters, and return behavior. An output schema is present, so detailed return values need not be described. The description is complete for an agent to select and 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?

  The description provides explicit, meaningful explanations for all parameters: unit_index is an AU index, track_index is within the AU, clip_index is the clip to clone, and consolidate controls whether the clone gets its own independent event collection. This is far more informative than the minimal type/title info in the schema, which has 0% 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 the tool's purpose: cloning a clip (note or value) on the same track. It uses a specific verb (clone) and resource (clip), and distinguishes it from other clip operations like delete, list, or set 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 provides clear context that this tool is used for cloning a clip onto the same track, with optional consolidation. It explains each parameter, giving the agent enough context to determine when to use it. However, it does not explicitly mention alternatives or 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.

• mcp_opendaw_clone_effect_chainA
  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 burden of behavioral disclosure. It reveals that parameter values are included, effects are appended to the existing chain, and the return is a list of cloned effects with new indices. It does not explicitly state that the source is unchanged, but "copy" implies non-destructive behavior; a bit more explicitness would merit a 5.

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

  Conciseness5/5

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

  Four sentences, front-loaded with purpose, followed by a use case, parameter explanations, and return value. 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 two-parameter tool with an output schema, the description adequately covers the purpose, when to use it, parameter semantics, and the return value. No critical missing 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.

  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 compensate. It explains both parameters: "src_unit: Source audio unit index" and "dst_unit: Destination audio unit index (effects appended to existing chain)." This adds meaningful context beyond the bare integer types in 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 clearly states a specific action: "Copy all effects from one audio unit to another, including parameter values." This distinguishes it from siblings like move_effect or duplicate_effect by focusing on the entire effect chain rather than a single effect.

  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 a concrete use case: "Useful for applying the same vocal chain (EQ → compressor → reverb) to doubled vocal tracks." Also notes the append behavior for the destination unit. Does not explicitly mention when not to use it or name alternative tools, 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.

• mcp_opendaw_connect_sidechainA
  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 burden. It discloses a key behavioral requirement: the target effect must have a sideChain field and be of specific types. Does not warn about potential overwriting of existing sidechain connections or errors, but is fairly transparent for a connection 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 a bulleted parameter list and a constraint note. Every sentence adds value; no fluff.

  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 output schema exists and the operation is moderately simple, the description covers the necessary context: what it does, how parameters work, and which effects are supported. It is complete enough for an agent to select and 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 has zero description coverage, but the description explains all three parameters with examples: source_unit_index (drums), target_unit_index (bass), and effect_index (position on target). This fully compensates for the schema gap.

  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: 'Connect one audio unit's output as sidechain source to a Compressor/Gate on another unit.' This clearly distinguishes the tool from siblings like apply_sidechain by emphasizing the connection action and target effect types.

  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 by naming example units (drums, bass) and constraining the target effect to Compressor, Gate, Vocoder, or any effect with Pointers.SideChain. Lacks an explicit when-not-to-use or alternative recommendation, so not a 5.

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

• mcp_opendaw_create_additive_rhythmA
  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. It explains the accent pattern behavior (e.g., 'accents on notes 1, 4, 6'), what parameters affect the output, and states the return value ('Returns notes created, grouping structure, accent pattern, and bar layout'). It doesn't disclose whether existing notes at start_beat are overwritten or merged, which would be useful, but overall it 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 long but well-structured: a concise definition, multiple illustrative examples, then a comprehensive Args list. Each section earns its place, and the front-loaded concept plus examples quickly orient the user. The formatting with line breaks and code-style examples improves readability.

  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 complexity (14 parameters, musical concept), the description covers all necessary facets: what it does, how to use it, parameter details, and return values. The presence of an output schema reduces the need to detail returns, but the description still provides an overview. Combined with excellent parameter documentation, it is 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 description fully compensates. Every parameter is documented with allowed values, defaults, and examples (e.g., grouping, unit, accent_mode, decay). The examples show how parameters combine to generate specific rhythmic patterns, which goes far 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 'Create an additive rhythm — unequal groupings within a bar,' which clearly states the verb, resource, and core concept. It further distinguishes the tool from other rhythm generators by explaining the specific technique (3+2+2, 5+3) with musical context and examples.

  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 rich context on when this tool is appropriate (Messiaen, Stravinsky, math rock, Balkan rhythms) and provides multiple examples showing varying parameters. However, it does not explicitly mention alternatives like create_polyrhythm or create_hemiola, nor does it state exclusion criteria, 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.

• mcp_opendaw_create_arrangement_variationA
  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 does well: it details drum density ranges, bass octave shifts, melody transforms, and track inclusion flags. It also states the return value ('notes per track and transformations applied'). However, it does not disclose side effects like whether existing regions are overwritten or new ones created.

  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?

  Long but well-structured: lead statement, contrast, parameter list, return note, and two examples. Each section earns its place, and the formatting makes it 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?

  Given the tool's complexity (19 parameters, no annotations), the description is thorough: covers musical behavior, parameter semantics, and examples. The missing track parameter explanations are a notable gap, but the overall context is sufficient for an agent to use 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?

  Schema description coverage is 0%, so the description must compensate. It explains most parameters with values and examples (drum_density, bass_octave_shift, melody_transform, include_*). Yet it omits five parameters (bass_track, drum_track, melody_track, harmony_track, unit_index), leaving them unexplained.

  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 a specific verb and resource: 'Create a musically varied section — not a repeat, a real variation.' It explicitly contrasts with create_genre_sections and enumerates track transformations, making the purpose unmistakable and differentiating it from 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?

  Provides an explicit alternative: 'Unlike create_genre_sections (which repeats the same loop at different velocities), this tool applies actual musical transformations.' Concrete scenarios (drop, breakdown, bridge) and two examples illustrate when to use it, effectively guiding the agent.

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

• mcp_opendaw_create_breakA
  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 full burden. It discloses generative behavior ('Generates...'), explains 1-bar repetition, variation modes (fill, humanize, drop), and swing effect. However, it doesn't address whether existing notes are overwritten or how missing AUs are handled, leaving some ambiguity about DAW state changes.

  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 with an introductory sentence followed by a clean parameter list. Each line serves a purpose—no filler. The length is justified by the need to document 7 parameters and multiple preset options without omitting essential details.

  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?

  Covers all parameters with rich detail, states return values ('notes created, break type, and bars'), and benefits from an existing output schema. No critical information is missing for an agent to invoke the tool correctly, even with 0% schema descriptions and no annotations.

  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 has 0% description coverage, so the description compensates fully. Every parameter is documented: break_type lists all presets with musical details, bars includes range and default, variation enumerates modes, unit_index/track_index explain targeting, start_beat and swing give units and ranges. This far exceeds 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 clearly states the action ('Create a classic drum break') and specifies the resource and context ('foundation of jungle, DnB, hip-hop, breakbeat'). It distinguishes from siblings by emphasizing 'presets' and listing iconic breaks (Amen, Think, etc.), setting it apart from generic pattern tools like create_drum_pattern or create_breakbeat.

  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 (classic drum break genres, presets) and explains variation options, but does not explicitly name alternative tools or state when not to use this tool. The genre focus and preset list imply usage scenarios, but exclusionary guidance is missing.

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

• mcp_opendaw_create_chaconneA
  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 full burden for behavioral disclosure. It reveals concrete side effects: 'Creates bass on track_index, chord pads on track_index+1, variation on track_index+2.' It also documents variation style behavior. However, it does not state whether existing notes are overwritten or if tracks must pre-exist, leaving some side-effect 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?

  The description is efficiently structured and front-loaded with the core definition. Each subsequent section (bass pattern, bass rhythm, chord pattern, variation styles, track placement) adds necessary usage detail without fluff. It is longer than average but earns its length given the tool's complexity.

  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 complexity (9 optional parameters, compositional form, multiple styles) and zero schema descriptions, the description is fairly complete: it covers form definition, differentiation, parameter formats, style meanings, and output track placement. It falls short only on a few parameter semantics (repeats, velocity, start_beat, unit_index) and does not mention prerequisites about existing tracks, but overall it provides enough for an agent to use 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?

  Schema description coverage is 0%, so the description must compensate. It explains bass_pattern format ('space-separated note names'), bass_rhythm ('space-separated durations in beats'), chord_pattern ('comma-separated chord names', supported chord types), variation_style options with brief descriptors, and track_index placement behavior. However, repeats, velocity, start_beat, and unit_index are not described, leaving gaps for 4 of 9 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 opens with a specific verb and resource: 'Create a chaconne — repeating bass + chord progression + developing variations.' It clearly defines what a chaconne is and explicitly differentiates it from ground bass and passacaglia, which are sibling tools. This resolves ambiguity among similarly named compositional generators.

  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 contrasts chaconne with ground bass ('bass only') and passacaglia ('bass + variations'), stating that chaconne repeats both bass AND chord progression. This gives direct when-to-use guidance relative to named alternatives, satisfying the 5-level criterion of explicit when/when-not/alternatives.

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

• mcp_opendaw_create_choraleA
  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 explains generation mechanics: common tones preserved, smooth voice movement, no parallel fifths/octaves, range limits for each voice, and soprano receives the melody. It also lists returned data. This goes well beyond a basic summary, though it doesn't address potential side effects like overwriting existing notes.

  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 efficiently structured: opening summary, behavioral detail, then a clear parameter list and returns line. Each sentence serves a purpose—voice ranges, chord types, defaults, and output behavior are all packed in without fluff. It is long out of necessity given the 14 parameters, but nothing feels redundant.

  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 complex tool with 14 parameters and no schema descriptions, yet the description covers every parameter, explains voice-leading logic, gives range constraints, and notes the output structure. The presence of an output schema reduces the need to detail return values, but the description still mentions them. For a generation tool with this complexity, the description is remarkably 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 input schema has no descriptions for any parameter (0% coverage). The tool description compensates by documenting all 14 parameters, including defaults, ranges, and examples (e.g., 'chord_pattern: Comma-separated chord names (e.g. "C,Am,F,G")'). This fully resolves the schema gap and provides actionable meaning beyond the stamped types and defaults.

  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: 'Create a 4-voice SATB chorale with voice-leading rules.' It clearly distinguishes this tool from sibling tools like create_harmony or create_voice_led_progression by specifying SATB voicing, voice-leading constraints, and Bach chorale style. This is a concrete verb+resource pairing with immediate 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 provides clear context for when to use this tool: 'Classic Bach chorale style — foundational for vocal harmonies, string arrangements, synth pad layering.' It implies suitability for traditional SATB writing but does not name alternative tools or explicitly state when not to use it, so it stays at 4 rather than 5.

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

• mcp_opendaw_create_chord_progressionA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description must disclose behavior. It clearly states the tool creates a chord progression, explains how parameters affect placement (unit_index, track_index, start_beat, chord_duration), and notes the return value. It doesn't specify side effects on existing notes or permissions, but the provided context is substantially 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 moderately sized but every sentence adds value: purpose, chord spec format, root names, chord types, example, parameter meanings, and return value. It is well-structured and avoids 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?

  The description covers all five parameters, provides an example, and explains the return value. No annotations exist, but the tool's complexity is fully addressed given the parameter explanations and output description.

  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 every parameter in plain language. It gives allowed root names, chord types, a JSON example, and explains each parameter's meaning, including defaults (start_beat=0, chord_duration=4) with musical context.

  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 ('Create a chord progression from chord names') and contrasts it with creating 15-50 individual notes, making the tool's purpose unmistakable. It also lists the exact chord root names and types, which differentiates it from other progression tools that may work from keys or styles.

  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 says 'one call instead of 15-50 note creations,' which tells the agent to prefer this tool when the user wants to place chord progressions efficiently rather than building them note-by-note. However, it does not explicitly differentiate from sibling tools like create_progression_from_key or reharmonize_progression, so it lacks explicit exclusions.

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

• mcp_opendaw_create_filter_sweepA
  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. It discloses smart defaults, direction-specific cutoff values, resonance boost behavior ('from current to +0.3 at sweep midpoint, then back down'), and return values ('events created, sweep config, and a preview of the curve'). It does not mention error cases or undo behavior, but covers the key behavioral aspects.

  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 logically structured: purpose, context, parameter list, return value, and two examples. Every sentence adds useful information, and the parameter list is formatted for easy scanning. 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?

  Given the 10-parameter complexity and lack of annotations, the description is remarkably complete. It covers all parameters, defaults, behavior, return values, and provides concrete examples. The presence of an output schema is noted, but the description already covers the expected return without needing to rely on 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 coverage is 0%, yet the description explains every parameter in detail, including ranges, defaults, direction-dependent defaults (e.g., start_cutoff default 0.05 for open, 0.85 for close), and curve options. This exceeds mere schema titles and is essential 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?

  Description opens with a specific verb+resource: 'Create a filter sweep on a Vaporisateur instrument's cutoff parameter with smart defaults.' It further clarifies the sweeping direction ('closed to open (build-up) or open to closed (breakdown)'), making it distinct from sibling tools like generic automation_sweep or create_riser.

  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?

  Strong usage context is provided: 'The most common transition technique in EDM/techno/house' and clear direction semantics. However, it does not explicitly name alternative tools or state when not to use this tool versus a generic automation sweep.

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

• mcp_opendaw_create_full_genre_pipelineA
  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 does well: it lists the 8-step pipeline, explains skipped layers (pads/bass) when a progression is provided, mentions sidechain for electronic genres, and notes the mastering LUFS target. It does not disclose whether the tool resets/overwrites the existing project or what happens if the project already has tracks, leaving some ambiguity about destructive 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 long but every section earns its place. It is front-loaded with the core purpose, followed by a numbered step list, parameter definitions, and examples. The structure is scannable and the verbosity is appropriate for a complex 8-parameter orchestration tool.

  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 high complexity (8 params, multi-step pipeline), no annotations, and 0% schema description coverage, the description is remarkably complete. It covers the pipeline steps, parameter semantics, valid genre values, and expected outcome ('ready for export_audio / render'). It also states it returns 'complete pipeline status', and since an output schema exists, detailed return-value documentation is not required.

  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 explain parameters, and it does. It explains every parameter: genre lists all 15 supported values, bpm is an override, bars has a genre-specific minimum, master_lufs gives concrete targets (-14 Spotify, -10 loud, -16 Apple), progression shows a string format with an example, and add_counter_melody/add_track_chains are clearly conditioned on other parameters. Examples at the end further clarify usage.

  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's function: 'Create a complete genre track from zero to render-ready in one call.' It uses a specific verb ('create') and a specific resource ('genre track'), while explicitly distinguishing itself from individual tools by noting 'One call replaces 5-10 individual tool calls.'

  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 it (when you want a full track from scratch, ready for export/render) and contrasts with the multi-call alternative. However, it doesn't explicitly name sibling tools like create_genre_track or arrangement-specific tools as alternatives, nor does it state when NOT to use this tool (e.g., if you only need an arrangement or want to modify an existing project).

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

• mcp_opendaw_create_ghost_notesA
  4.6/5.0
  Behavior4/5

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

  It discloses key behaviors: inserts low-velocity notes at off-beat positions where no notes exist, works on the first note track, and returns count and positions. It also details parameter effects on density and velocity, though it doesn't mention reversibility 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.

  Conciseness5/5

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

  The description is well-structured with a clear lead sentence, parameter list, return value, and example. Every section adds value without unnecessary 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?

  It covers purpose, behavior, parameters, and return value. It even includes an example call. The output schema is true but the description already tells what it returns, making it complete for a tool of this complexity.

  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 explains every parameter beyond the schema: unit_index, track_index, region_index, density, velocity, and seed, with ranges and examples. This 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 explicitly states 'Add ghost notes (quiet grace notes) to existing drum/MIDI patterns', which is a specific verb+resource. It distinguishes from sibling tools like create_drum_pattern by focusing on adding quiet grace notes to existing patterns.

  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 context for when to use it: 'Essential for funk, R&B, neo-soul, and hip-hop drumming.' It also explains it inserts notes at off-beat positions and works on the first note track, but does not explicitly compare to alternatives.

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

• mcp_opendaw_create_impactA
  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 for behavioral disclosure. It explicitly describes the output as 'single sustained note with type-specific pitch, duration, and velocity,' details each impact_type's sonic character, and notes that pitch is overridden by type. It also clarifies the return value. However, it does not discuss potential side effects like whether it modifies existing data or requires a pre-existing track.

  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 with a concise opening, bulleted parameter list, return note, and two examples. No fluff; each section adds 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 7-parameter tool with no schema descriptions or annotations, the description covers all parameters, provides examples, and describes return values. The only minor omission is an explicit note on whether existing notes are affected, but the create intent is clear.

  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's detailed parameter documentation is essential. It explains every parameter, including the impact_type enum values with pitch/character, unit_index behavior, defaults, and the meaning of velocity. 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.

  Purpose5/5

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

  The description opens with 'Create an impact — single hit transition element for drops and section changes', giving a specific verb, resource, and purpose. It further distinguishes the tool from siblings like create_riser/build-up by clarifying the 'hit' after a build-up.

  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 'Essential for EDM transitions: the "hit" that lands after a riser/build-up,' providing clear context for when to use this tool. However, it does not explicitly name alternative tools or when not to use it, so it stops short of a full 5.

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

• mcp_opendaw_create_motif_variationsA
  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 full burden and does well: it details where the variation is written, the meaning of -1 for auto-creation, and the exact transform behaviors for all six variation types with musical examples. It does not explicitly warn that writes to an existing target region may overwrite notes, a minor 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 long but densely informative with clear Markdown structure: opening summary, variation type list with examples, and parameter breakdown. Each sentence serves a purpose—examples like 'C→E→G (+4, +3) becomes C→A→F (-3, -2)' concretely illustrate inversion without fluff.

  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 complex tool with six transformation types and 12 parameters, the description covers variation semantics, parameter details, and location handling. An output schema exists, so the return value note is sufficient. Minor omission of error conditions (e.g., note_count out of range) is outweighed by the thorough treatment of functionality.

  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 explaining every parameter: start_note indexing, note_count range (3-16), source/target locations, variation_type values, sequence_shift as semitones, augmentation_factor as duration multiplier, and fragment_count as notes from the start. This far exceeds minimal compensation.

  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 clear specific action: 'Extract a motif from existing notes and create a variation in a new region.' It explicitly identifies the resource (motif, notes, region) and contrasts with the sibling extract_motifs, making its unique role in the analysis→creation loop obvious.

  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 extract_motifs as the complementary tool and explains that this tool 'takes a specific motif and transforms it,' providing solid context for when to reach for it. It also lists 'Essential for' use cases. However, it does not explicitly mention when not to use it or alternative variation-creating tools like create_variations.

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

• mcp_opendaw_create_phase_shiftA
  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. It discloses that the tool copies the source phrase, places it on a parallel or cross-track, and how shift_per_bar, bars, direction, and velocity_scale affect the result. It does not cover edge cases like pre-existing content on the destination track, but it is otherwise quite 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 well-structured: a one-line summary, an explanatory paragraph, a sibling comparison, and a detailed Args section. While the historical/genre references add length, they serve to clarify the intended musical use, so no part is wasted.

  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 tool is complex (8 parameters) with no annotations, but the description thoroughly covers the operation, parameter effects, and placement behavior. An output schema exists, so return-value details are handled separately; the description could mention prerequisites or error behavior, but it's largely 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?

  All 8 parameters are described in detail despite the schema having 0% description coverage. Each parameter gets a meaning, and shift_per_bar, bars, direction, cross_track, and velocity_scale include ranges, defaults, or recommendations.

  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 'Create a phase-shifted copy of a region' – a specific verb and resource. It clearly explains the accumulating time offset and explicitly contrasts with displace_rhythm, distinguishing the tool from its sibling.

  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 displace_rhythm as an alternative and explains that phase_shift creates a second copy that drifts further each bar, unlike the single fixed offset of displace_rhythm. It also provides musical context (Steve Reich, techno) and recommends using cross_track for explicit control.

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

• mcp_opendaw_create_riserA
  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. It discloses that the tool generates a sequence of notes, ramps velocity proportionally, and returns the created notes and pitch range. However, it does not specify whether existing notes are preserved or overwritten, leaving a minor ambiguity about 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 front-loaded with a clear one-sentence purpose, followed by concise mechanism and use-case bullets, then a parameter list. No 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?

  Despite lacking annotations and having 9 parameters, the description covers all parameter semantics, usage context, and return value, making it self-sufficient for an agent to select and 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?

  All 9 parameters are individually documented with meanings, defaults, ranges, and examples (e.g., start_pitch default 36 = C2, steps 32 = sixteenths over 4 beats), fully compensating 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 clearly defines the tool as creating a riser with an ascending pitch sweep, explicitly differentiating it from sibling tools like create_buildup by specifying the velocity ramp and pitch progression. It also provides concrete use cases.

  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 lists specific use cases (build-ups, transitions, tension creation) but does not mention when not to use it or name alternative tools, so it lacks explicit exclusion/alternatives.

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

• mcp_opendaw_create_scale_runA
  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 full burden. It discloses that the tool 'generates a sequence of scale notes moving up or down across one or more octaves' and returns total notes and scale info, with parameter-driven placement. It does not detail whether existing notes are overwritten or how tracks are managed, but the core creation behavior and note-count scaling are clearly communicated.

  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 with a one-line summary, a parameter list, return-value note, and an example. Despite being long, every sentence adds value—no redundant filler. The front-loaded summary immediately identifies the tool's purpose.

  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 10-parameter tool, the description covers every parameter with meaningful guidance, provides an example, and states the return format. It is self-contained and complete enough for an agent to invoke correctly without external context, even though the output schema is not shown here.

  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 compensates thoroughly by listing all 10 parameters with types, defaults, and examples. It explains meaning beyond schema, such as '1 = 7-8 notes, 2 = 14-15 notes' for octaves and duration notation for step_duration, plus a full usage example.

  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 'Create a scale run — ascending or descending scale sequence for fills and transitions,' which is a specific verb+resource combination. It clearly differentiates this from sibling tools by focusing on scale-based note sequences and their musical applications.

  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 states use cases: 'Used for drum fills, melodic transitions, lead build-ups, and bass walks.' This gives contextual guidance on when to use the tool. It does not explicitly list alternatives or when NOT to use it, but the application context is sufficient.

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

• mcp_opendaw_create_tempo_rampA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description fully explains the mechanism: it adds a series of tempo change events via ValueEventBox, describes interpolation behavior, and mentions return data. The no-op example adds useful behavioral insight. However, it doesn't disclose potential side effects such as interaction with existing tempo events or whether the operation is reversible.

  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, starting with a clear purpose, followed by parameter explanations, return info, and three illustrative examples. Every section adds value, and the examples are particularly informative. Although long, it is appropriately sized for a tool with this complexity.

  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 description covers all six parameters, provides usage examples, describes the return value, and places the tool in a musical context. The presence of an output schema means detailed return structure isn't required, making this description complete for correct selection and 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 description thoroughly explains every parameter: start_beat, end_beat, start_bpm, end_bpm with ranges, curve options with meanings, and steps with default and effect. This 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 opens with a clear, specific action: 'Create a smooth tempo ramp (ritardando or accelerando) across a beat range.' It also distinguishes itself from add_tempo_change by stating it creates multiple events for a smooth curve, making the tool's unique purpose 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?

  The description provides strong usage context by naming musical scenarios (ritardando, accelerando) and includes three examples covering different use cases including a no-op. It differentiates from add_tempo_change by explaining the multi-event mechanism, but it doesn't explicitly state when not to use this tool or formally recommend alternatives beyond the implicit contrast.

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

• mcp_opendaw_create_trance_arrangementA
  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. It provides extensive behavioral detail: exact drum pattern, bass pattern, arp pattern, lead style, chord progression, and output (notes per track). However, it does not disclose whether the tool overwrites existing notes on the specified tracks or requires empty tracks, which is a notable gap in side-effect transparency for a generative 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 well-structured: it opens with a one-line summary, then uses bullet points for each track, includes a genre differentiation paragraph, and ends with concise parameter definitions and examples. While lengthy, every section adds valuable information for an AI agent to understand and invoke the tool correctly.

  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 provides enough context for invocation: it explains the musical output, parameter meanings, and mentions the return value (notes per track and total). It hints at prerequisites ('unit_index: AU index with note tracks') and gives examples. However, it lacks clarification on velocity and start_beat, and does not specify behavior if tracks already contain notes, which is a minor 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?

  Since schema description coverage is 0%, the description must explain the parameters. It covers bpm, bars, root, octave, unit_index, and the four track indices, with ranges and musical rationale (e.g., 'root: Root note (F is a classic trance key — Fm)'). However, it omits velocity and start_beat entirely, which are present in the schema but not explained in the description.

  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 the tool's function: 'Create a full trance arrangement — driving drums + rolling bass + supersaw arp + pluck lead across 4 tracks.' It clearly identifies the genre and differentiates from sibling arrangement tools through detailed musical comparisons (e.g., 'house has off-beat stabs, techno has sub drones, synthwave has 16th arpeggios, trance has rolling 8ths'). This 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 Guidelines5/5

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

  The description explicitly explains when to use this tool: for uplifting trance with a rolling off-beat bass, and contrasts it with other genres ('same as synthwave but faster and euphoric... different from house, techno, synthwave'). It also provides default BPM and key context, giving the agent clear criteria for selecting this tool over alternatives.

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

• mcp_opendaw_create_trillA
  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 full burden and does well: it explains alternation behavior, accent/start options, target track selection, and return value ('Returns notes created, rate, note count'). It does not disclose all edge-case side effects (e.g., overwrites, failures), but enough is provided for safe 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 front-loaded with a one-line definition, then uses a compact parameter listing. The genre context is relevant and not bloated; every section adds value.

  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 10 optional parameters and no annotations, but the description covers every parameter, provides target selection semantics, and states the output summary. This is complete enough for an agent to invoke 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 free-text description enumerates and explains all 10 parameters with defaults, ranges, and semantics (e.g., rate values '32nd','16t', duration 0.5-32). This fully compensates for the schema's lack of param 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 opens with 'Create a trill — rapid alternation between two notes,' providing a specific verb and resource. It clearly distinguishes this from ornament-generation siblings like create_mordent or create_turn by defining the trill concept and its musical contexts.

  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 context for when a trill is appropriate (baroque, jazz, metal, electronic) and explains the mechanism. However, it never names alternative sibling tools or states when NOT to use it, so exclusions are missing.

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

• mcp_opendaw_create_two_hand_pianoA
  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. It discloses return values ('Returns notes created, left/right hand voicings, and chord count'), explains the structural pattern (left hand accompaniment, right hand melody), and notes subtle behaviors like 'left hand slightly quieter.' However, it does not explicitly state whether the operation overwrites existing notes or if prerequisites such as a valid note track are enforced beyond mentioning indices.

  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 well-structured: a clear summary, followed by parameter details, and a return statement. Each sentence earns its place, especially the enumeration of hand patterns and octave explanations. It is slightly verbose but appropriate for a 13-parameter tool with zero schema help.

  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 complexity (13 parameters, 1 required, no schema descriptions), the description is remarkably complete: it addresses input, behavior, patterns, and output. It lacks explicit error handling or edge cases (e.g., what happens if melody_pitches is empty for right_hand='melody'), but the coverage is strong enough for an agent to invoke 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 is the sole source of parameter meaning. It compensates thoroughly by explaining every parameter in detail, including examples for chords, enumerating left_hand and right_hand options with descriptions, clarifying melody_pitches usage, and defining octave and rate semantics. This far exceeds baseline.

  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 combination: 'Create a two-hand piano arrangement — left hand accompaniment + right hand melody.' It clearly distinguishes from siblings by explicitly contrasting with create_chord_progression and create_melody, making the tool's unique role evident.

  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 explicit when-to-use guidance: 'Unlike create_chord_progression (block chords only) or create_melody (single line), this combines both hands into one coherent arrangement.' This directly tells the agent when this tool is appropriate versus alternatives, fulfilling the dimension fully.

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

• mcp_opendaw_create_variationsA
  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. It states the operation reads from a source region and writes new regions to a target track, implying non-destructive behavior (source is read-only). It details each transformation effect. However, it does not disclose edge cases like whether existing regions on the target track are overwritten, or behavior on invalid inputs. Still, it provides substantial behavioral insight.

  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 long but every sentence is information-dense and earned. It front-loads the core purpose, then systematically explains each parameter with a labeled list. The variation-spec enumeration is necessary for correct usage and is well-formatted. 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?

  Given the tool's complexity (8 parameters, no annotations, output schema present), the description covers purpose, parameters, return values, and even musical context. It omits nothing critical for an agent to invoke it correctly. The output schema exists, so return types need no further description.

  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 titles with no descriptions (0% coverage), so the description must fully explain parameters. It does so exhaustively: all 8 parameters are described with formats, defaults, and examples (especially the variations string syntax with all supported spec forms). This is exemplary compensation for 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 opens with a specific verb and resource: 'Create thematic variations from an existing note region.' It clearly distinguishes itself from siblings by enumerating the exact transformations (transpose, invert, reverse, augment, diminish, fragment, octave_shift) and the source/target region mechanics. This is a precise, non-tautological purpose statement.

  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 context: it is for theme-and-variations composition, citing historical examples. It explains when to use it (when creating variations from a note region) but does not explicitly contrast with sibling tools like create_motif_variations or create_motif_development. Thus it has strong implied usage but lacks explicit exclusions/alternatives.

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

• mcp_opendaw_create_volume_fadeA
  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 behavioral burden. It discloses that the tool creates volume automation events, ramps between dB levels, uses an exponential curve by default, and returns specific data. It does not mention whether it overwrites existing automation or is reversible, but it gives a clear operational picture 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 organized in a logical flow: opening purpose, usage context, parameter list, return value, and examples. Every sentence serves a purpose; the parameter documentation and examples justify the length. It front-loads the core information and avoids fluff.

  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 complexity (8 parameters, no annotations, no schema descriptions), the description covers all essential aspects: what it does, when to use it, all parameters with defaults, and return values. The presence of examples further enhances completeness, leaving little ambiguity for an AI 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 description coverage is 0%, so the description fully compensates. It explains every parameter with units, defaults, and directional dependencies (e.g., start_volume_db default 0 for fade out, -60 for fade in), and provides two concrete examples that clarify usage. This exceeds the schema's bare titles.

  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 verb ('Create a volume fade automation') and the resource ('audio unit'), explicitly covering both fade directions. It distinguishes itself from sibling tools like create_filter_sweep, create_pan_sweep, and set_audio_region_fade by focusing on volume automation on the AU's volume parameter.

  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 context for when to use this tool: 'The most common mix technique for intros, outros, breakdowns, and section transitions.' It does not explicitly mention alternatives or when not to use it, but the stated context is sufficient to guide selection.

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

• mcp_opendaw_delete_audio_unitA
  4.6/5.0
  Behavior4/5

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

  The annotations already mark this as destructive (destructiveHint: true), and the description adds useful behavioral details: it performs proper cleanup of connected boxes via ProjectApi.deleteAudioUnit(), and it protects the master output from deletion. This goes beyond the annotation without contradicting it.

  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 four short sentences, front-loaded with the primary purpose, then the cleanup behavior, then the critical index constraint. Every sentence adds value with no redundancy or 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 single-parameter destructive tool, the description adequately covers what it deletes, how it cleans up, and the only special-case constraint (index 0). The output schema exists, so return details are not required. It is complete for an agent to select and 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?

  The input schema only provides the parameter name 'unit_index' as an integer with no description (0% coverage). The description fully compensates by explaining that unit_index identifies the audio unit to delete and must be >= 1 because index 0 is the master output. This gives the agent the necessary semantic constraint.

  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 it deletes an entire audio unit with all its tracks, effects, and sends, which is a specific verb+resource combination. It distinguishes this tool from siblings like mcp_opendaw_delete_track, mcp_opendaw_remove_effect, and mcp_opendaw_remove_send by emphasizing the whole-unit 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 provides clear operational context by stating the primary output AU (index 0) cannot be deleted and requiring unit_index >= 1. It implies when to use this tool (full unit removal) versus alternatives like delete_track, though it does not explicitly name alternatives or list when-not-to-use scenarios.

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

• mcp_opendaw_download_audioA
  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 full burden of behavioral disclosure. It adds meaningful behavioral details: 'Supports any HTTP(S) URL pointing to WAV/MP3/FLAC/OGG,' 'Uses streaming download with timeout,' 'Files saved to /tmp by default (or custom dir),' and 'output_dir... Must exist.' It also reveals the return shape ('absolute file path, size, and suggested next step'). It doesn't cover overwrite behavior or authentication edge cases, but for a download tool it is fairly 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 longer than minimal but well-structured: a purpose sentence, a workflow context paragraph, support/behavior notes, a bulleted parameter list, return value statement, and two examples. Every sentence adds information, but it could be tightened slightly. The structure makes it easy to scan, so it earns a 4 rather than a 3.

  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 3 parameters, no annotations, and a present output schema, the description covers purpose, parameters, behavior, return value, and examples. It omits failure modes (e.g., overwrite policy, invalid URL handling) and network-specific concerns (rate limits, authentication), leaving some room for completeness. However, the output schema presumably defines return details, so this is a fully adequate description for its complexity.

  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 fully. It does: each parameter is given meaning beyond the schema—'url: Direct URL... (e.g. Suno CDN audio_url from chirp_generate),' 'filename: Output filename (default: derived from URL path),' 'output_dir: Directory to save (default /tmp). Must exist.' This adds real semantic value over the bare schema titles.

  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 begins with a specific verb+resource+destination: 'Download an audio file from a URL (e.g. Suno CDN) to local disk.' It clearly distinguishes from siblings by framing its role in a workflow: 'Bridges the gap between AI music generators (Suno, Udio) and the DAW: generate a track → get audio URL → download → import_audio_to_tracks.' This sets it apart from other audio tools that operate on already-local files.

  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 provides explicit usage context: 'Bridges the gap between AI music generators (Suno, Udio) and the DAW...' and an explicit alternative: 'Without this, you need manual curl/wget outside the MCP pipeline.' This tells when to use the tool and what alternative exists, which satisfies the dimension's requirement for explicit when/alternatives.

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

• mcp_opendaw_duplicate_note_eventA
  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 of disclosing behavior. It specifies exactly which properties are copied (position, duration, pitch, velocity, cent, chance, playCount), describes transposition/shift options, and notes the returned values. This provides substantive behavioral detail, though it does not mention side effects like whether the original is modified or how collisions are handled.

  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 efficiently structured: a one-line summary, a list of copied properties, parameter semantics, and the return value. Every sentence carries useful information with no redundancy, 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.

  Completeness5/5

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

  Given the tool's moderate complexity, the description covers all required aspects: operation, target selection, offset behavior, and return value. The presence of an output schema means return value details are not strictly necessary, but they are included anyway. No significant gaps remain.

  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 thoroughly compensates by explaining each parameter's meaning: unit/track/region indexes as coordinates, note_index, and the offset params including their units (PPQN, semitones). It also clarifies defaults, which adds value 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 ('Duplicate'), a clear resource ('a note event'), and a scoping constraint ('within the same region'), with optional position/pitch offset. This clearly distinguishes it from sibling tools like 'duplicate_region' or 'duplicate_notes'.

  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 context: it duplicates a single note event within the same region and explicitly lists the copied attributes and optional offsets. However, it does not explicitly name alternatives or state when not to use this tool, 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.

• mcp_opendaw_explode_chordsA
  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 transparency burden. It discloses the splitting algorithm, low-note-to-voice mapping, edge cases (chords with fewer/more notes), and per-parameter behavior for direction and velocity_balance. It does not explicitly state whether the original chord track is preserved or removed, a minor behavioral omission.

  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 long but serves the complexity of a 7-parameter tool. It is front-loaded with a clear purpose, followed by algorithmic explanation, typical uses, and a structured Args section. Every sentence adds value and the formatting is clear 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 complexity and the presence of an output schema (which presumably defines return values), the description is impressively complete. It covers purpose, algorithm, parameter semantics, edge cases, and examples, leaving no significant gaps for a tool of this nature.

  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 compensates by explaining every parameter in detail: unit_index, track_index, region_index, num_voices (with behavior for mismatched chord sizes), direction (with all enum meanings), target_units (with format and validation), and velocity_balance (with all enum meanings). This goes far 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 clearly states the tool's purpose with a specific verb and resource: 'Explode chords into separate voice tracks.' It explains the algorithm and provides concrete examples (piano → bass + cello + viola + violin), distinguishing it from sibling tools like create_chorale or create_harmony.

  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 when to use it: 'This is the fundamental orchestration technique — converting a chord progression into individual instrumental parts' and gives typical use cases. However, it does not mention alternatives or exclusions, 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.

• mcp_opendaw_export_dawprojectA
  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 of behavioral transparency. It discloses that the format is a ZIP with specific contents, that the extension is automatically added, and that the file path is returned. This goes beyond the tool name but could be richer (e.g., overwrite behavior, non-destructive nature).

  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 front-loaded with the primary action. It uses three short paragraphs: purpose, format explanation, and args/returns. Every sentence adds relevant information with no waste.

  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 is simple with one optional parameter and an output schema. The description covers the purpose, file format details, parameter behavior, and return value. It is complete for an export tool of this complexity.

  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 'filename' is described with meaning beyond the schema: no extension should be provided, and '.dawproject' is appended automatically. Since schema description coverage is 0%, the description fully compensates for the one 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 clearly states the tool exports the current project as a .dawproject file, naming specific compatible DAWs (Bitwig/Ableton/rePitch). This specific verb+resource+format distinguishes it from sibling export tools like export_midi, export_mix, and render_full.

  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 context for when to use this tool: when interoperability with other DAWs supporting dawproject is desired. It explains the format's purpose but does not explicitly name alternative tools or state when not to use it, so no exclusions.

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

• mcp_opendaw_export_effect_chainA
  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 compensates well: it discloses the internal serializer ('Uses PresetEncoder.encodeEffects'), the output format ('base64 preset bytes'), and error behavior ('or error'). It lacks explicit side-effect/permission information, but 'export' implies a read-only 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 well-structured and economical: a one-sentence purpose, a brief implementation note, parameter explanations, and return value. Every sentence adds value, with no redundant fluff.

  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 export tool, the description covers everything needed: what it does, how it works, parameter semantics, the complementary import tool, and the return format. The existence of an output schema further reduces the need to elaborate return structures.

  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 provides only types and a default, but the description explains both parameters in plain language: 'unit_index: AU index to export from' and 'effect_type: "audio" for audio effects, "midi" for MIDI effects.' This 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 opens with a specific verb and resource: 'Export an effect chain (audio or MIDI) from an AU as a base64 preset.' This clearly states the tool's function and distinguishes it from sibling operations like import_effect_chain or get_effect_chain. The scope (audio or MIDI) is explicitly included.

  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 context by noting the exported preset 'Can be imported into another AU via import_effect_chain,' establishing the primary use case. It does not explicitly enumerate alternatives or when-not-to-use scenarios, but the purpose and related workflow are transparent.

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

• mcp_opendaw_extract_rhythmA
  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. It details output fields, grid resolutions, syncopation scale, and includes an example. It does not explicitly say whether the tool modifies notes, but the analysis-focused description strongly implies read-only 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 well-organized with a summary, bullet features, grid options, use cases, parameters, and an example. Though long, it is structured and front-loaded, with every sentence contributing value.

  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 description fully covers the tool's behavior, including outputs, grid resolutions, parameter semantics, and an example. Given the output schema handles return values, this description is contextually complete for an analysis 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?

  The schema has 0% description coverage, but the description compensates by explaining each parameter: unit_index, track_index, region_index with default behavior, and grid with all possible values. It elaborates on grid resolution options, providing meaningful context 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 clearly states it extracts rhythmic patterns from notes and lists specific outputs such as onset grid, syncopation, and IOI. The verb 'Extract' and resource 'rhythmic pattern from notes' are precise, distinguishing it from analysis and generation 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 'Useful for' section lists explicit scenarios like measuring syncopation, extracting groove for groove_transfer, and feeding rhythm to generate_melody. This provides clear usage context, though it does not explicitly state when not to use the tool or name alternatives for exclusion.

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

• mcp_opendaw_generate_melodyA
  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. It discloses the step-by-step algorithm (scale building, contour mapping, weighted random selection, rhythm application, rest insertion) and return values. However, it does not state whether existing notes on the target track are replaced or appended, an important side-effect 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 long but well-structured: summary, detailed option lists, numbered algorithm steps, parameter list, return value, and examples. Every sentence adds value, and the organization makes it easy to scan.

  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 11 parameters, no schema descriptions, and complex algorithm, the description is remarkably complete: covers all parameters, algorithm behavior, musical intent of each option, and return values. Minor gaps like track content replacement are noted but do not undermine overall completeness.

  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 thoroughly documents every parameter, including enumerated options for contour, rhythm, scale, and numeric ranges/defaults for bars, velocity, octave, and rest_probability. 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.

  Purpose5/5

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

  The description clearly states the tool generates a melodic line from a scale using contour-guided random selection. It explicitly says 'Creates a melody from scratch — no chord progression needed', distinguishing it from sibling tools like create_melody_from_progression.

  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 strong context for usage: 'no chord progression needed' and examples for different musical scenarios (arch-shaped C major, ascending pentatonic, sparse ambient). However, it does not explicitly name alternative tools or give when-not-to-use guidance, 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.

• mcp_opendaw_identify_chordsA
  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 the full burden. It discloses the grouping algorithm, tolerance behavior, chord types matched, and return fields. It does not explicitly state that it is read-only, but 'Reads all notes from a region' strongly implies a non-destructive operation. It lacks edge-case behavior (e.g., no chords detected) but is otherwise 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 front-loaded with the main purpose, then follows a logical flow: algorithm, use cases, parameters, return value. Every sentence earns its place; the parameter explanations are necessary given the schema has no descriptions. It is long but not bloated.

  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 complexity and the presence of an output schema, the description covers the essential context: input parameters explained, algorithm described, known chord types enumerated, and return fields listed. It is sufficient for an agent to select and invoke the tool correctly. The only minor omission is error or empty-result behavior, but the output schema likely covers return structure.

  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 compensates fully. Every parameter (unit_index, track_index, region_index, group_tolerance, min_notes) is explained with meaning, defaults, and context (e.g., '0.25 = notes within a 16th note of each other'). This adds substantial value over 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: 'Identify chords from existing notes in a region'. It clearly distinguishes this analysis tool from generation tools like mcp_opendaw_create_chord_progression, and explains the algorithm and output. Purpose is 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?

  Provides concrete use cases: 'understanding imported MIDI, analyzing AI-generated progressions, reverse-engineering a track's harmony, or verifying that generated chords match the intended progression.' This is clear context but stops short of explicit exclusions or direct comparisons to alternatives, so it misses the top score.

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

• mcp_opendaw_insert_restsA
  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 of disclosing behavior. It clearly states that the tool deletes notes, explains the three deletion modes, and describes the effect of shorten_neighbors. While it does not explicitly mention reversibility or undo options, the destructive nature is transparent enough for an agent to infer the operation's impact.

  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 well-structured and front-loaded with the core purpose, followed by a clear 'Args:' section. While longer than the two-sentence ideal, every sentence contributes useful detail necessary for correct invocation. The organization into bullet-like list items aids readability, though some redundancy exists between the opening and the Args section (e.g., both mention position-based operation).

  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 complexity (7 parameters, multiple modes, and a destructive operation) and the absence of schema descriptions, this description is notably complete. It covers all parameters, mode semantics, and differentiates from a sibling tool. Minor omissions include edge-case behavior (e.g., when no notes match rest positions) and explicit reliance on undo tools, but the provided information is sufficient for most usage scenarios.

  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 provides comprehensive parameter documentation despite the schema having 0% coverage. It gives meaningful examples, such as rest_positions '0,1,2,3' or '1.5,3.5', explains tolerance_beats in musical terms (32nd/16th note), details each mode's behavior, and specifies the condition for shorten_neighbors. This fully compensates for the empty 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 clearly states the tool's function with a specific verb and resource: 'Insert rests at specified beat positions by removing notes.' It further distinguishes itself from the sibling tool thin_notes by emphasizing its positional approach, making its purpose unambiguous and contextually unique.

  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 contrasts this tool with thin_notes, stating that unlike thin_notes (which removes by interval/velocity/random strategy), this works positionally. This provides clear guidance on when to choose this tool over an alternative, even though it does not explicitly say '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.

• mcp_opendaw_list_automatable_fieldsA
  4.6/5.0
  Behavior4/5

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

  Annotations include readOnlyHint=true, and the description reinforces this by saying 'List' and describing return metadata. It adds context about what the tool returns (field names, current values, automatable status) and clarifies 'supports Pointers.Automation'. No contradiction, but the description is not overly detailed about edge cases.

  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, with three short paragraphs: purpose, automation relevance, parameter explanations, and return value summary. Every sentence adds value 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?

  Given the output schema, the description doesn't need to detail return fields; it summarizes them. The tool is simple (list fields) and the description covers purpose, parameters, and output, making it complete for an agent to select and invoke 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 coverage is 0% but the description fully explains both parameters: 'unit_index' is the audio unit index containing the instrument, and 'sample_index' is for Playfield sample slots with default -1 for top-level. This adds meaningful semantics 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 uses a specific verb ('List') and identifies the exact resource ('automatable parameter fields on an instrument or specific Playfield sample'). It clearly differentiates from sibling tools like list_instrument_params and list_effect_parameters by focusing on automatable fields only.

  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 when to use this tool: to discover which fields support automation ('only these can be automated'). It also clarifies context for sample_index with Playfield. However, it does not explicitly mention alternatives or exclusions, so it earns a 4.

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

• mcp_opendaw_list_automation_events_detailA
  4.6/5.0
  Behavior4/5

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

  Annotations include readOnlyHint=true, and the description is consistent, describing a read-only listing operation. It adds behavioral context beyond the annotation by specifying return content ('Returns event list with positions in beats, values, and interpolation details') and units. No contradiction; lacks mention of error cases or scale but sufficient for a 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 tight and well-structured: purpose sentence, comparison, parameter explanations, and return summary. Every sentence earns its place with no 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?

  The description covers purpose, differentiation, parameter semantics, and return format. The output schema exists, so return details are structured elsewhere. Minor gaps: no mention of error conditions or handling of empty/invalid tracks, but for a simple list tool this is acceptable given the annotations and schema.

  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 has 0% description coverage, but the description compensates by clarifying 'unit_index: AU index' and 'track_index: Value (automation) track index.' This adds domain meaning beyond the raw integer type, though not exhaustive about lookup methods.

  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's purpose: 'List all automation events on a value track with full detail — position, value, interpolation.' It also distinguishes itself from the sibling tool by noting 'More detailed than list_automation_events — includes interpolation type and curve slope.' This is a specific verb+resource+scope with explicit differentiation.

  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 frames when to use this tool vs the alternative: 'More detailed than list_automation_events — includes interpolation type and curve slope.' The parameter explanations also clarify which track/unit to target, giving clear context for invocation.

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

• mcp_opendaw_list_effect_parametersA
  4.6/5.0
  Behavior4/5

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

  The readOnlyHint annotation is present, and the description adds value by stating what the tool returns: 'parameter names, current values, units, and ranges.' This goes beyond the annotation to disclose output structure, but does not detail error behaviors or edge cases.

  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, two line-item parameter definitions, and a return summary. No extraneous information is present; 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?

  Given the tool's simplicity, the presence of a readOnlyHint, and an output schema, the description covers purpose, parameter semantics, and return content adequately. It is sufficient for an agent to select and 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 coverage is 0%, yet the description explicitly defines both parameters: 'unit_index: Audio unit index' and 'effect_index: Effect position in the chain (0-based, from add_effect return).' 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 opens with a specific verb and resource: 'List all parameters of an effect on an audio unit.' This clearly differentiates it from sibling tools like list_midi_effect_params or list_instrument_params, which target different effect types.

  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 useful context by specifying that effect_index is 0-based and comes from add_effect return, implying a prerequisite call. However, it does not explicitly state when to use this tool over alternatives or provide exclusion criteria, 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.

• mcp_opendaw_list_note_regionsA
  4.6/5.0
  Behavior4/5

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

  The readOnlyHint annotation already signals a read operation. The description adds value by specifying the output fields returned (region_index, unit_index, track_index, position_beats, duration_beats, label, note_count) and the meaning of -1 for both parameters, which goes beyond the annotation. No contradictions with the annotation were found.

  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, followed by two concise parameter explanations and a clear list of return fields. Every line contributes useful information with no redundancy or 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 straightforward list operation, the description covers the purpose, parameter behavior, and return structure. Since an output schema exists and the tool is simple, there are no significant gaps. The description is sufficiently complete for an agent to select and 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?

  The input schema provides no descriptions for unit_index and track_index (0% coverage), but the description fully compensates by explaining each parameter and the special -1 value indicating 'all'. This is essential semantic information that 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 clearly identifies the action ('List all note regions'), the resource ('note regions'), and the key returned attributes ('position, duration, and note count'). This distinguishes it from sibling tools like list_notes and list_audio_regions, which operate on different entities.

  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 concrete parameter semantics: unit_index and track_index, with -1 meaning 'all'. This gives clear context for invoking the tool correctly. However, it does not explicitly compare to alternatives or state when to prefer this over list_notes/list_audio_regions, so it misses the higher bar for explicit exclusions or alternative guidance.

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

• mcp_opendaw_list_value_regionsA
  4.6/5.0
  Behavior4/5

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

  With readOnlyHint=true, the description adds value by explaining the -1 sentinel behavior for scanning all AUs and all value tracks, plus listing returned fields. No contradiction with annotations, and no destructive/concurrency concerns are relevant.

  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: purpose, behavior, parameter explanations, and return type are each covered in one short line. No fluff 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 read-only list tool with two parameters and an existing output schema, the description covers the essential selection and invocation details. It explains parameter semantics, returned fields, and scope behavior sufficiently.

  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 explicitly explains both parameters: unit_index and track_index, including the meaning of -1 as 'search all'. 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 states a specific verb ('List') and resource ('automation regions on value/automation tracks'), and further clarifies with 'ValueRegionBox'. This clearly distinguishes it from sibling listing tools like list_audio_regions or list_note_regions.

  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 the tool: when you need region-level data (position, duration, loop, mute, label) on value/automation tracks. It does not explicitly name alternatives or exclusions, but the scope is unambiguous.

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

• mcp_opendaw_list_warp_markersA
  4.6/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, and the description adds behavioral context by specifying the return format (position, seconds, isAnchor) and the empty result when no stretch mode is present. This goes beyond the annotation without contradicting it.

  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, using short sentences with clear sectioning for parameters and return value. Every sentence adds value, and there is no redundant 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?

  With an output schema present and simple list operation, the description covers purpose, usage, parameter meaning, and return behavior. It is sufficiently complete for an agent to select and 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%, but the description explicitly defines each parameter: 'unit_index: AU index', 'track_index: Track index within the AU', 'region_index: Audio region index'. 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 opens with 'List warp markers on a time-stretched or pitch-stretched audio region', which is a specific verb+resource statement. It further explains what warp markers are and distinguishes this from sibling tools like list_markers or list_transient_markers by specifying warp markers on stretched regions.

  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 'Used for tempo-matching audio regions', providing clear context for when to use the tool. It also implies a precondition (time-stretched/pitch-stretched region), but does not explicitly mention exclusions or alternatives, which keeps it from a 5.

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

• mcp_opendaw_merge_consecutive_notesA
  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 of behavioral disclosure. It explains the scanning algorithm, merging rules (same pitch, gap threshold), and the resulting note span. It also details the effects of same_pitch_only and velocity_mode. However, it does not explicitly state that the operation permanently modifies the track or is destructive, but the phrase 'merged into one note' implies replacement, and the logic is thoroughly described.

  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 despite its length. Every sentence contributes: a clear one-line summary, an algorithm explanation, usage guidance, and a structured parameter list. There is no redundancy or filler. The formatting is scannable and front-loaded with the core purpose.

  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 six parameters, an output schema, and a moderately complex transformation. The description covers the purpose, algorithm, use cases, and all parameter semantics. With an output schema present, return values need not be described. The description is fully self-contained for an agent to decide if and how to invoke 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%, but the description's Args section explains every parameter in detail, including examples for max_gap_beats (0.0, 0.25, 1.0) and enumerates all velocity_mode options. This greatly exceeds the schema's bare titles and provides all necessary semantic meaning 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 opens with a specific verb and resource: 'Merge consecutive notes of the same pitch into single sustained notes.' This clearly distinguishes it from sibling tools like merge_note_regions (which merges regions) and merge_note_tracks (which merges tracks). The behavior is unambiguous and unique.

  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 provides use cases: 'cleaning up repeated hits, converting staccato patterns to sustained notes, or simplifying busy passages.' This gives clear context for when to apply the tool. It does not explicitly mention when not to use it or name alternatives, but the context is strong 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.

• mcp_opendaw_merge_note_regionsA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden and delivers: explicitly states B is deleted, A is extended, positions adjusted, silence fills gaps, and returns merged details. This is exceptional disclosure 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?

  Well-structured with intro, behavior, edge case, use cases, parameter definitions, return note, and example. No redundant sentences; all content 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?

  Output schema exists, so return values are covered. Description includes algorithm details, non-adjacent gap behavior, and example. Missing domain context on what 'AU' stands for, but overall complete for a mutating region merge 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?

  Schema provides only titles with 0% description coverage; description compensates by explaining each parameter's role (AU index, track index, region A as identity-preserving absorber, region B as deleted). Adds example call. Minor gap: 'AU index' is not elaborated, but sufficient for 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?

  States clearly it merges two note regions on the same track into one, with specific behavior (copies notes from B to A, deletes B). Distinguishes from sibling tools like merge_note_tracks and merge_consecutive_notes by specifying same-track scope and region-level 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?

  Lists concrete use cases (joining verse+chorus, consolidating split regions, merging MIDI takes, simplifying arrangement) that signal when to invoke. Does not explicitly name alternatives or state when not to use, but the context is clear enough.

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

• mcp_opendaw_move_audio_unitA
  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 of behavioral disclosure. It discloses the reindexing behavior, relative delta semantics, and the return value (new index or error). It does not mention permissions, reversibility, or edge cases, but for a simple move operation, this is adequate and goes beyond what the schema provides.

  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 main purpose, and each sentence contributes meaningful information. The parameter explanations are tightly integrated and directly useful, with no fluff 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?

  Given the simple two-parameter tool, the description covers purpose, precise behavior, parameter semantics, and expected return. An output schema exists to document the return value, so the description need not detail that further. It is sufficient for an agent to select and invoke this 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. It does so effectively by explaining both parameters: unit_index is 'Current AU index' and delta is 'Relative move (-1 up, +1 down).' This adds semantic meaning beyond the raw schema properties and clarifies their roles.

  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 ('Move') and resource ('an audio unit up or down in the mixer order'), and further clarifies the scope by noting it reindexes within its type group (Instrument/Aux/Output). This distinguishes it from sibling tools like move_effect and move_track.

  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 context by explaining that the move is relative and reindexes within type groups, but it does not explicitly state when to use this tool versus alternatives or mention exclusions. The context is clear enough for an agent to infer the appropriate scenario, but it stops short of explicit when-to-use or 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.

• mcp_opendaw_move_region_contentA
  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 of behavioral disclosure. It does an excellent job explaining the audio vs. MIDI behavior, including the tempo map conversion and the sign convention for MIDI notes. It also mentions the return values. However, it does not disclose potential side effects (e.g., whether the operation is destructive or reversible via undo) or note any permission/associated DAW engine state requirements. This leaves some gaps for an AI agent to infer.

  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. The first sentence states the core purpose, followed by targeted detail for audio vs. MIDI, then a concise parameter list, and a brief return-value note. Every sentence adds valuable information; there is no fluff or repetition. It remains compact enough to parse quickly.

  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 lack of annotations and schema descriptions, the description provides a complete picture: it defines the operation, distinguishes between audio and note regions, explains parameter meanings, and states the return values. It even accounts for tempo map conversion. While it does not discuss edge cases (e.g., negative delta or region boundary limits), it covers all necessary information for an AI agent to select and invoke the tool correctly for typical use 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 coverage is 0% (no descriptions in the input schema). The description compensates fully by explicitly listing each parameter: 'unit_index: AU index', 'track_index: Track index within the AU', 'region_index: Region index', and 'delta_beats: Shift amount in beats (positive = content moves left, region shrinks from left)'. This adds semantic meaning, including the critical sign convention for delta_beats, which is not evident from the schema alone.

  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: 'Shift the content start of a region without moving the region itself.' This clearly differentiates it from sibling tools like set_region_position or move_notes, which alter the region position or notes independently. The distinction is concrete 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 states 'Useful for realigning content within a region after tempo changes,' providing clear usage context. It does not explicitly mention alternative tools or when not to use it, but the phrase 'without moving the region itself' implicitly contrasts with region-moving operations. No exclusions are needed for a niche tool like this.

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

• mcp_opendaw_ppqn_to_partsA
  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. It discloses that the conversion accounts for time signature changes and lists the exact return components (bars, beats, semiquavers, ticks, active time signature). This goes beyond the bare schema and clearly frames the tool as a pure, non-destructive read 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 compact and well-structured: action, use case, parameter explanation, and return summary. Every sentence adds value, and the information is front-loaded. 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 one-parameter conversion tool with an output schema, this description is complete. It states the purpose, parameter semantics, key behavioral nuance (time signature awareness), and expected output. No significant gaps remain for typical usage.

  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 a type ('number') with 0% description coverage. The description fully compensates by explaining the meaning of position_ppqn and giving the conversion factor (960 = 1 quarter note). This makes the parameter semantics crystal clear.

  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 ('Convert') and identifies both the input (a PPQN position) and the output (musical parts: bars, beats, semiquavers, ticks). This clearly differentiates the tool from siblings like ppqn_to_seconds and seconds_to_beats, which convert to other units.

  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 'useful for understanding where a position falls in the musical grid' line gives a clear use case, and it notes that time signature changes are taken into account. It does not explicitly mention alternatives or when not to use the tool, but the context is sufficient given the distinct output format.

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

• mcp_opendaw_reharmonize_progressionA
  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. It thoroughly explains the transformation behavior for each technique, the meaning of intensity levels, and explicitly states the return value (progression string + mapping + explanation). This is significantly transparent. However, it does not explicitly state whether the tool modifies project state or is purely computational, which would have made it fully 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 long but every sentence earns its place. It is front-loaded with a clear summary, then systematically explains each parameter with examples and musical rationale. The use of bullet-like formatting for techniques and intensity levels improves scannability without wasting 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?

  Given the tool's complexity (4 parameters, 5 techniques, multiple intensity levels) and absence of annotations, the description is remarkably complete. It covers input format, all technique variants with musical context, intensity semantics, target_chord behavior, and the return payload. The existence of an output schema means return-value details are not strictly needed in the description.

  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 (progression, technique, intensity, target_chord) is explained with concrete musical examples, possible values, and their effects. This goes far beyond the bare schema, providing essential context 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 opens with a specific verb and resource: 'Reharmonize a chord progression — substitute chords with functionally equivalent alternatives for richer harmony.' This clearly states the tool's function and distinguishes it from sibling tools like create_chord_progression or modulate_progression. The detailed technique list further clarifies its unique 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 provides clear context for when to use the tool (reharmonization for richer harmony) and details each technique's musical purpose (e.g., 'Jazz standard', 'Adds forward motion'). However, it does not explicitly name alternative tools or state when not to use this tool compared to siblings, so it misses the explicit exclusion guidance for a 5.

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

• mcp_opendaw_render_full_formatA
  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. It discloses the return values ('Returns both WAV and converted file paths'), the dependency on system ffmpeg, default sample rate, and that bitrate is ignored for WAV/FLAC. It could go further (e.g., potential runtime, side effects), but the provided transparency is solid.

  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: a purpose sentence, parameter explanations, and a final sentence covering combination and return. No fluff or repetition; every line 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 the tool's moderate complexity (4 optional params, no required fields), an output schema, and no annotations, the description is comprehensive. It covers purpose, parameters, dependencies, and return values. Missing usage exclusion is the only small gap, already captured in usage_guidelines.

  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. It explains each parameter meaning beyond defaults: filename ('without extension'), sample_rate, format values and defaults, bitrate behavior including 'Ignored for WAV/FLAC'. This adds significant value over 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 opens with a specific verb and resource: 'Render the entire project and convert to MP3 or FLAC in one step.' It also explicitly notes it 'Combines render_full + convert_audio,' which clearly distinguishes it from sibling rendering and conversion 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 clear context for when to use this tool (when a one-step full-project render and format conversion is needed) and references the two underlying operations, 'render_full + convert_audio.' However, it does not explicitly state when NOT to use it or list alternative tools for WAV-only or conversion-only tasks.

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

• mcp_opendaw_render_rangeA
  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 full burden. It discloses the underlying implementation ('Uses OfflineEngineRenderer with custom range'), the output ('Returns the path to the exported WAV and audio metadata'), and the speed benefit. It does not explicitly state that rendering is non-destructive, but as an export operation this is largely implied and no contradictory behavior is hinted.

  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 one-sentence purpose, a concise parameter list, an implementation note, and the return value. Every sentence provides value with no filler. The purpose is front-loaded, making it easy for an agent to scan.

  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 moderate complexity (4 parameters, all documented), the presence of an output schema that covers return values, and the clear usage context, the description is complete. It even includes an internal implementation detail and a performance comparison, which helps the agent reason about when to choose this tool over full renders.

  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 compensates fully by explaining every parameter: start_beat (with '0 = project start'), end_beat, filename (without .wav extension), and sample_rate (with default). This adds concrete meaning beyond the bare schema field names and 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 opens with a specific verb and resource ('Render only a portion of the project') and gives a concrete example ('chorus only'). It clearly distinguishes itself from full-export tools by explicitly limiting scope to a range, which is reinforced by the tool name and sibling names.

  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: 'for quick A/B comparison' and 'Faster than full export for checking specific sections during mixing.' It implies when to use it (section-level mixing checks) but does not explicitly name alternative tools or describe when not to use it, though the comparison to full export gives sufficient guidance.

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

• mcp_opendaw_replace_instrumentA
  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. It transparently discloses that the operation deletes the old instrument and creates a new one, which is critical destructive behavior. It also states return data (old and new instrument type) and constraints, though it does not mention potential side effects or success/failure conditions.

  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 with a clear opening statement, followed by implementation details, constraints, parameter explanations, and return value. Every sentence adds necessary information with no fluff or repetition, striking a good balance between completeness and conciseness.

  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 moderate complexity, the description covers all key aspects: operation, scope, limitations, prerequisites, parameter semantics, and return value. With an output schema present (per context signals) and the description already stating the return type, the tool is fully specified for an agent to use 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 only provides parameter names and types with 0% coverage. The description compensates thoroughly by defining unit_index as an audio unit index with a minimum of 1, and new_instrument as a factory key with the allowed values listed explicitly ('Vaporisateur', 'Nano', 'Soundfont', 'Apparat'). This is essential information 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 opens with a specific verb and resource: 'Replace the instrument on an audio unit with a different MIDI instrument.' It clearly distinguishes this from sibling tools by specifying it operates on audio units and is limited to MIDI instruments, and even notes which instruments are excluded (Tape).

  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 when-to-use guidance: works only for MIDI instruments (Nano, Vaporisateur, Soundfont, Apparat) and explicitly states when not to use it (Tape cannot be replaced this way). It also gives a prerequisite (the AU must have a CaptureMidiBox), but it does not mention alternative tools.

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

• mcp_opendaw_seconds_to_beatsA
  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 takes on the burden of disclosing behavior. It states that the tool accounts for tempo automation and returns beats, PPQN position, or an error, offering important context beyond a basic conversion.

  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 main action. Every sentence adds value: core function, tempo automation note, use case, parameter, and return value, with 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 simple one-parameter conversion tool, the description covers the operation, relevant behavior, parameter semantics, and return value. The presence of an output schema means return details need not be elaborated further, making this 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?

  Despite 0% schema description coverage, the description explicitly explains the 'seconds' parameter as time in seconds (float), fully compensating for the schema's lack of detail and adding clear meaning.

  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 (convert seconds to beats) and resource (project's tempo map). It distinguishes itself from sibling conversion tools like mcp_opendaw_ppqn_to_seconds by specifying the direction of conversion.

  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 a clear use case: aligning audio regions to the musical grid when tempo changes mid-song. While it doesn't explicitly mention alternatives or exclusions, the context is sufficient for an agent to decide when to invoke this tool.

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

• mcp_opendaw_set_articulationA
  4.6/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses behavior: it explains exactly how each articulation alters note durations, how staccato_ratio and micro_gap affect the result, what happens to the last note and chord notes, and the return value. This is exemplary 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 long but well-structured: opening statement, articulation definitions, parameter semantics, return note, and examples. Every section adds necessary value, and the most critical info appears early. 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 6-parameter mutation tool with no annotations, the description covers selection scope, per-articulation behavior, parameter defaults, edge cases, and return format. It is complete enough for an agent to invoke correctly without additional 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 carry the parameter burden. It does: all six parameters are explained with defaults, value ranges, and musical meaning (e.g., 'staccato_ratio: 0.5 = half the available time', 'micro_gap: PPQN gap to leave between notes'). This vastly exceeds schema-only information.

  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's purpose: 'Set articulation for notes' with explicit legato/staccato/tenuto variants. It is specific about the resource (notes) and operation, but it does not differentiate itself from the sibling tool mcp_opendaw_apply_articulation, so it misses full 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 Guidelines4/5

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

  The description provides rich usage context, including musical recommendations ('Use for smooth string lines...', 'Use for sustained passages...') and edge-case behavior (last note, chords). It does not explicitly state when to use this tool instead of alternatives, but the context is clear enough for selection.

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

• mcp_opendaw_set_neuralamp_modelA
  4.6/5.0
  Behavior4/5

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

  With no annotations, the description discloses key behaviors: it creates a NeuralAmpModelBox, links it, returns 'success + model_size', and errors if the effect is not a NeuralAmp. It does not mention reversibility or overwriting effects, but covers the main behavioral contract.

  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 a clear purpose. The parameter list is compact yet complete, and every sentence adds value 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?

  Despite having no parameter descriptions in the schema, the tool description covers all parameters, return values, error conditions, and the headless-loading use case. It provides sufficient context for an agent to invoke this 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 carries full parameter meaning. It explains unit_index as 'AU index', effect_index as 'Effect index in the audio effect chain (must be a NeuralAmp)', model_json as 'Full NAM model JSON string', label default and pack_id optional—all 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 clearly states a specific action: 'Load a Neural Amp Modeler (NAM/Tone3000) model JSON into a NeuralAmp effect.' It distinguishes the tool from siblings like mcp_opendaw_get_neuralamp_model by focusing on loading rather than retrieving, and specifies the target resource (NeuralAmp effect).

  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: 'This bypasses the popup-based Tone3000 Select Flow, enabling headless model loading.' It also indicates the effect_index must be a NeuralAmp. However, it lacks explicit exclusions or named alternatives, so it stops short of full when/when-not guidance.

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

• mcp_opendaw_set_piano_keyboardA
  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 transparency burden. It discloses that the operation returns success along with the old and new values, giving insight into the response behavior. However, it does not mention side effects on existing piano roll data, error handling, or whether the change is reversible. Still, for a simple setter, this is respectable 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 two sentences long and front-loads the core action. The first sentence states the purpose; the second provides parameter details and return behavior. Every word is informative, 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 setter, the description is complete: it specifies the parameter's allowed values, the domain (piano roll), and the return format. The presence of an output schema means the description doesn't need to elaborate further on return structure. This is sufficient for an agent to select and 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?

  The input schema only defines keyboard_type as an integer with no description or enum, and schema coverage is 0%. The description fully compensates by explicitly listing valid integer values (88, 76, 61, 49) and human-readable labels (full piano, stage, compact, controller). This adds crucial meaning beyond what the 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 clear, specific action: 'Set the piano roll keyboard type.' This identifies the exact resource (piano roll keyboard) and distinguishes it from sibling tools like set_piano_note_scale or set_piano_mode. The valid values are also enumerated, leaving no ambiguity about the tool's function.

  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 context for when to use the tool (to change the piano roll keyboard size) and lists all valid options. It doesn't explicitly state when not to use it or mention alternatives, but the purpose is obvious enough that a user can infer appropriate usage. No exclusion criteria are given, which would be needed for a 5.

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

• mcp_opendaw_set_revamp_filterA
  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 of behavioral disclosure. It adds meaningful context such as frequency being exponential (20–20000 Hz), gain applicability limited to shelves/bells, q to bells and LPF, and order to HPF/LPF. These constraints go beyond raw ranges and explain which parameters have effect for which sections, which is valuable behavioral 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 structured as a clean, front-loaded summary followed by one-line parameter entries. Every sentence earns its place; there is no fluff, and the format makes it easy for an agent to scan the required and optional parameters and their constraints.

  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 complexity (8 parameters, no annotations), the description covers all necessary invocation details: the effect must be a Revamp, the valid section values, parameter ranges, and when parameters apply. It also states required parameters implicitly via the schema, and the existence of an output schema means return values need not be described. The tool is fully specified 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%, but the description compensates fully by explaining all 8 parameters: unit_index as AU index, effect_index as a Revamp effect in the chain, section enum with the seven valid values, enabled as a boolean, plus ranges and applicability for frequency, gain, q, and order. This adds meaning well beyond the schema's bare property titles.

  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: 'Configure a filter section on a Revamp (parametric EQ) effect.' This clearly distinguishes it from generic effect parameter setters among siblings, as it targets a particular effect type (Revamp) and a specific aspect (filter sections).

  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 the tool is appropriate: it requires the effect_index to be a Revamp, and it lists the valid filter section types. It does not explicitly name alternatives or say when not to use it, but the 'must be a Revamp' constraint and section types 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.

• mcp_opendaw_thin_notesA
  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 takes on the full burden of behavioral disclosure. It clearly states that notes are selectively removed, explains the three removal strategies in detail, and mentions the return counts. It does not explicitly warn that the operation is destructive or irreversible, but the removal semantics are evident.

  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 long but perfectly structured: a clear summary, strategy breakdown, parameter list, and concrete examples. Every sentence adds value, and the use of bullet points and formatting makes it scannable. 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 tool with 8 parameters, 3 strategies, no annotations, and no schema descriptions, the description is fully complete. It covers purpose, strategies, parameter semantics, default behaviors, strong-beat preservation, and return values. The examples further illustrate real usage. 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 has 0% coverage (no property descriptions), so the description must compensate fully — and it does. Every parameter is explained with types, defaults, value ranges, and context (e.g., 'interval: keep every Nth note (2=halve, 3=third). Must be 2-16'). Examples show parameter usage in practice.

  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: 'Thin out notes in a region — reduce note density for cleaner patterns.' It clearly distinguishes this tool from other MIDI manipulation tools by focusing on density reduction, and explains the use case after AI generation, transcription, or dense arrangement. The three strategies further clarify its unique purpose.

  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 the tool: after AI generation, transcription, or dense arrangement to clean up cluttered patterns. It also explains each strategy's intended use ('Creates space', 'Cleans up ghost notes', 'Creates organic variation'). However, it does not explicitly mention alternative tools or exclusions, so it misses the top score.

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

• mcp_opendaw_apply_full_mixA
  4.7/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 details the exact chain assignment per track, the return value, and the meaning of parameters. However, it does not mention potential side effects such as whether existing chains are overwritten, or whether the operation can be undone. This is a minor gap given the tool's clear mutation intent.

  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, starting with a one-line summary, then alternative guidance, parameter details, chain assignment, return value, and examples. Every sentence adds value; there is no fluff. The bullet points and code examples make it easy to scan.

  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 four parameters, behavioral details, return value, and provides examples. It is quite complete for a complex tool. However, it does not explicitly mention prerequisites (e.g., that the unit must contain note tracks) or edge cases (e.g., what happens if num_tracks exceeds available tracks). These gaps are minor given the tool's clarity.

  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 compensates thoroughly. It explains each parameter in detail: genre lists all supported values, unit_index identifies target, num_tracks explains track roles (0=drums, 1=bass, 2+=melodic), and master_lufs gives reference targets. The chain assignment section further elaborates how parameters map to behavior.

  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+resource+scope: 'Apply a complete mix in one call — genre-aware processing chains on every track + mastering.' It explicitly distinguishes itself from sibling tools by naming the individual chain tools it replaces (add_drum_chain, add_bass_chain, add_instrument_chain, add_mastering_chain).

  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 provides explicit guidance on when to use this tool: 'Replaces 5-6 separate calls (add_drum_chain + add_bass_chain + add_instrument_chain × N + add_mastering_chain).' It also gives concrete examples with different genres and LUFS targets, which clarifies the intended use cases.

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

• mcp_opendaw_apply_velocity_lfoA
  4.7/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 delivers substantial behavioral context: it explains the oscillating algorithm, parameter formulas (e.g., 'modulates ±depth*center'), and the return payload (notes_processed, min/max/avg stats). However, it does not explicitly state that the operation mutates note velocities in place or warn about destructiveness/reversibility, which would have made it fully 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 front-loaded with the core purpose, then uses a compact Args block with one line per parameter, followed by a Returns section. Every sentence adds information—the differentiation sentence, parameter examples, and return field list all serve purpose without redundancy. The structure is scannable and efficient for an 8-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?

  The description covers the tool's operation, all parameters, output format, and sibling differentiation, which is strong given the lack of annotations and schema descriptions. Minor gaps remain: no mention of prerequisites (e.g., the target track must be a note track with notes) or error/empty-region behavior, but the core knowledge 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.

  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 8 parameters with rich detail: rate includes beat-cycle examples (0.25=every 4 beats, 1.0=per beat), shape enumerates the waveform options and their meanings, phase explains starting positions, and center gives the exact modulation formula. This exceeds what a typical schema description would 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 opens with a specific verb+resource: 'Apply periodic velocity modulation — velocity LFO along note positions,' which precisely states what the tool does. It further clarifies by contrasting with 'apply_velocity_curve (monotonic ramps)' and emphasizing 'REPEATING velocity patterns synced to beat positions,' distinguishing it from sibling velocity 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 closest alternative (apply_velocity_curve) and states when to choose this tool over it: for 'pumping, breathing, or wave-like dynamic motion' and repeating patterns rather than monotonic ramps. It also provides concrete scenario descriptors ('pumping, breathing, wave-like') that signal appropriate use cases.

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

• mcp_opendaw_create_l_system_melodyA
  4.7/5.0
  Behavior4/5

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

  With no annotations, the description carries full burden. It discloses the deterministic behavior, the meaning of symbols and intervals, parameters' effects, and the return value. However, it does not explicitly state side effects like whether the tool appends notes to an existing region or overwrites, leaving some ambiguity 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.

  Conciseness4/5

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

  The description is long but well-structured, starting with the core definition, then explaining the algorithm, use cases, presets, and a complete Args list. It is front-loaded and every section earns its place, though slight trimming could make it more concise without losing value.

  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 15 parameters, no annotations, and the presence of an output schema, the description is exceptionally complete. It covers the mathematical background, presets, custom options, all parameters, and return value, providing all necessary context for an agent to select and 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 is essential. It provides a clear one-line explanation for every parameter (root, scale, bars, octave, preset, axiom, rules, symbol_map, iterations, duration, velocity, rest_symbol, unit_index, track_index, start_beat), fully compensating 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.

  Purpose5/5

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

  The description states 'Create a melody using an L-system (Lindenmayer system)—a deterministic rewriting system,' which is a specific verb+resource+approach. It distinguishes itself from siblings by contrasting deterministic L-systems with Markov chains and random walks, clarifying its unique role among melody generation 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 contrasts L-systems with Markov chains and random walk, noting that L-systems are fully deterministic, and lists ideal use cases such as self-similar structures and deterministic generative composition. This gives clear guidance on when to choose this tool over alternatives like create_markov_melody or create_random_walk_melody.

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

• mcp_opendaw_create_markov_melodyA
  4.7/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. It explains the algorithmic behavior (Markov chain with transition matrix), the effect (melodies with stylistic memory), and the output ('Returns notes created, transition statistics, and seed'). It does not explicitly state non-destructiveness, but the 'create' verb and output description imply it. This is substantial but could be more explicit about 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 structured with a clear opening, an explanatory paragraph on Markov chains, and a parameter list. It is lengthy but every section earns its place given the tool's complexity and the need to compensate for sparse schema descriptions. It is not redundant; the example for interval_weights is particularly valuable.

  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 12-parameter generative tool with no annotations and an existing output schema, the description is comprehensive. It covers the algorithm, parameter semantics, output, and a comparison to a sibling tool. There are few gaps; it even explains the significance of Markov order and the default weight 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?

  Schema description coverage is 0%, but the description fully compensates with an 'Args' section explaining all 12 parameters. It provides details like the interval_weights JSON format with an example, root note naming, scale options, and order semantics. This goes far beyond the schema's titles and defaults.

  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+method: 'Create a melody using a Markov chain over scale-degree intervals.' It clearly distinguishes from siblings like random_walk by contrasting zero-order vs higher-order behavior, making the tool's function unique.

  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 an alternative: 'Unlike random_walk (zero-order: each step independent of history), Markov chains capture interval-to-interval tendencies.' It also explains when Markov chains are appropriate (stylistic memory) and covers default vs custom weight usage, giving clear when-to-use guidance.

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

• mcp_opendaw_create_sendA
  4.7/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 behavioral burden and does so excellently. It discloses exactly what gets created (new AudioBusBox, AudioUnitBox, AuxSendBox), what happens to the dry signal, that it's a parallel send not a redirect, and what it returns (send_index and fx_unit_index). This is rich, honest 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.

  Conciseness4/5

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

  The description is longer than average but well-structured: summary sentence, detailed behavior, parameter definitions, return values, and workflow. Each section adds value, and the front-loaded summary helps immediate comprehension. It could be slightly trimmed but is appropriately sized for the tool's complexity.

  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 description covers purpose, behavior, all parameters, return values, and a workflow, making it fully self-contained despite the bare schema and lack of annotations. The output schema exists, but the description already explains the key return fields. It's hard to imagine a gap that an agent would need filled.

  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 explain the parameters. It does: src_unit is described as the source audio unit index, name includes examples, send_level_db gives a range (-∞ to +12) and a suggested starting point (-6dB), and routing enumerates 'pre' vs 'post' with default. All four params are meaningfully explained.

  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: 'Create a parallel FX send bus from an audio unit.' It then explains the mechanics (new AudioBusBox, AuxSendBox, dry signal continues) and explicitly distinguishes from a redirect, making the tool's purpose unmistakable and differentiating it from sibling tools like create_audio_bus.

  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 context for when to use the tool: it's a parallel send workflow, and it states 'not a redirect'. It also gives a sequential workflow (create_instrument_track → create_send → add_effect) and explains that the FX bus unit index is used for adding effects. It doesn't explicitly list alternative tools for when not to use it, but the context is strong enough.

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

• mcp_opendaw_create_talaA
  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 disclosure burden and succeeds admirably. It details generative behavior: laya maps to note durations (vilambit=2-beat, madhya=1-beat, drut=0.5-beat), bols map to specific MIDI pitch ranges (bayan+dayan at 36-38, dayan at 46-52), and the cycle repeats with sam as the strongest beat. It also states what the return value contains (notes, vibhag structure, tali/khali positions, bols).

  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 lengthy (~300 words) but well-structured: purpose, then background, then tala catalog, laya definitions, pitch mapping, args, and returns. Nearly every sentence earns its place because the domain knowledge directly informs parameter selection (e.g., choosing tala_name requires knowing beat structures). Slight redundancy exists (cyclicity emphasized repeatedly), but the front-loaded opening and clear hierarchy prevent it from being bloated.

  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 7-parameter domain-specific creation tool with no annotations, the description is remarkably complete. It covers domain background, all parameter semantics, value options, behavior implications, and return contents. Even with an output schema available (per context), the description pre-emptively states return values. The only minor omission is explicit definition of 'AU index,' but the DAW context and sibling tool naming conventions make it inferable.

  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% (no param descriptions), placing full burden on the description. The Args section explains all 7 parameters, and the body enriches them substantially: tala_name's six valid values each get structural breakdowns (beats, vibhag divisions, tali/khali positions), laya gets duration semantics, velocity gets range 0-1, and cycles gets range 1-16. This far exceeds the bare schema titles.

  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 opening sentence 'Create an Indian classical tala — cyclic rhythmic structure with vibhag sections and tali/khali markings' provides a specific verb (create) + resource (Indian classical tala) with defining characteristics. This clearly distinguishes it from sibling tools like create_clave, create_colotomic, and create_euclidean_rhythm, which serve different rhythmic traditions.

  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 establishes unmistakable context: it is for Indian classical rhythm composition, listing specific talas and their traditional uses (e.g., 'ektal — used in classical vocal and sitar'). However, it never explicitly names alternatives or states when NOT to use this tool vs. other rhythmic pattern creators, stopping short of full exclusion guidance.

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

• mcp_opendaw_create_voice_exchangeA
  4.7/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 full burden. It discloses the transformation modes, swap behavior, and return values. However it does not explicitly state behavior when target region already contains notes or whether the source is left unmodified without swap. For a complex mutating tool, 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.

  Conciseness4/5

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

  The description is long but well organized with bulleted lists and an Args section. The opening paragraph could be shortened without losing meaning, but every section contributes. For a tool with 12 parameters, this length is justified.

  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 description covers what the tool does, how it differs from siblings, all parameter semantics, and the return values. With an output schema present, return details are a bonus. Combined with the rich parameter examples, the description is fully 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 Args section gives plain-language explanations for all 12 parameters, including defaults and examples (e.g., 'Default 7 = perfect fifth', 'Default 2.0 = response begins 2 beats after source starts'). The schema itself has zero descriptions, so this adds essential meaning.

  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 clear definition: 'Create a voice exchange — imitative counterpoint where motifs pass between voices.' It then contrasts with clone_track and copy_notes_to_track, positioning the tool as a transformation-based counterpoint tool rather than a copy operation.

  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 explicitly says 'Unlike clone_track (exact copy) or copy_notes_to_track (direct clone), voice exchange transforms the material as it passes between voices.' This provides guidance on when to use this tool. The list of transformation modes also clarifies intended use cases.

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

• mcp_opendaw_create_voice_led_progressionA
  4.7/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 details the voice-leading algorithm step-by-step, explains the voice_range constraint, and states the return value ('Returns chord voicings, voice movements, and total notes'). This provides substantial behavioral insight, though it does not mention potential side effects like whether existing notes are overwritten or if specific track prerequisites are required.

  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: a clear purpose statement, a contrast with the sibling tool, a parameter reference section, and an algorithm breakdown. Every sentence serves a purpose—parameter documentation is necessary given the sparse schema, and the algorithm section adds transparency. It is long but efficiently organized, 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?

  The description covers the core functionality, algorithm, parameters, and return values, which is comprehensive for a creative tool with 9 optional parameters and an output schema. However, it leaves some operational details ambiguous, such as what exactly 'unit_index' refers to, whether existing notes are cleared, and what happens if the specified track does not exist. These gaps are minor given the overall richness but prevent a perfect score.

  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 provides zero descriptions (0% coverage), so the description fully compensates. Every parameter (progression, bars_per_chord, octave, velocity, unit_index, track_index, start_beat, note_duration, voice_range) has a prose explanation with defaults, units, and examples. The progression parameter includes concrete chord progression examples with Roman numeral analysis, making semantics exceptionally clear.

  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's purpose: 'Create chord pads with smooth voice leading — minimal movement between chords.' It explicitly distinguishes itself from the sibling tool create_chord_pads by explaining that create_chord_pads voices chords in root position while this tool re-voices to minimize movement. This provides a specific verb, resource, and scope, and directly differentiates from a similar sibling.

  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 explicit usage context by contrasting with create_chord_pads: 'Unlike create_chord_pads (which voices every chord in root position causing large jumps), this tool re-voices each chord so individual voices move as little as possible.' This tells the agent when to use this tool versus the alternative, and the context 'strings/pads that glide instead of jump' clarifies the intended use case.

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

• mcp_opendaw_displace_rhythmA
  4.7/5.0
  Behavior5/5

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

  With no annotations to fall back on, the description fully discloses behavior: it explains that pitch/duration are unchanged, that the shift mode can extend region duration and clamps notes before position 0, and that circular mode wraps notes around while preserving region length. It also mentions the return value, providing a complete behavioral picture.

  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 well-structured with a summary, bullet points, bolded key terms, and three complete examples. While every sentence earns its place, it could be trimmed slightly without losing value, making it appropriately detailed rather than maximally concise.

  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 description covers the tool's purpose, modes, parameter meanings, edge cases, return value, and practical examples. It is complete for a transformation tool with no annotations, and the presence of an output schema further reduces the need to document return structure in detail.

  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 parameter names and defaults with zero descriptions, but the description gives detailed semantics for every parameter: unit_index, track_index, region_index with -1 wildcards, offset with range and common values, and mode explaining both options. 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.

  Purpose5/5

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

  The description clearly states the tool's function: 'Displace all notes in a region by a fixed rhythmic offset' — a specific verb and resource. It goes further to explain the two modes and the musical effect, distinguishing it from siblings like rotate_notes or shift_mode by emphasizing that pitch and duration are preserved and only timing is altered.

  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 context on when to use the tool: for laid-back, pushed, or on-top rhythmic feels, with examples for each. It does not explicitly name alternative tools or enumerate when not to use it, but the usage guidance is strong through the musical scenarios and mode explanations.

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

• mcp_opendaw_double_melodyA
  4.7/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 full burden. It discloses the core behavior (creates shifted copy), explains diatonic mechanics, and notes the return value. However, it does not state whether original notes are preserved or mention error conditions, minor gaps.

  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 one-sentence summary, then uses structured bullets and a clear parameter list. It is long due to the tool's complexity, but each sentence earns its place; no fluff.

  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 an 11-parameter no-annotation tool, the description covers usage, modes, parameter semantics, and return value. It includes two concrete examples. No missing critical info 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 has 0% description coverage. The description enumerates each parameter with meaning (interval values, diatonic mode, root/scale requirement, velocity_scale, time_offset, region/track selection). This fully compensates and adds examples.

  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: 'Double a melody at a parallel interval — thickening and harmonization.' It clearly distinguishes from sibling tool copy_notes_to_track by noting it supports named intervals and diatonic transposition.

  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 contrasts with copy_notes_to_track ('chromatic transpose only'), and provides use-case guidance: same-region for thickening, cross-track for separate layer. Examples illustrate common scenarios (octave doubling, diatonic thirds, power chords).

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

• mcp_opendaw_engine_sleepA
  4.7/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 explaining behavior. It states the action (suspends audio processing), the purpose (save CPU), and the reversibility (wake() to resume). It does not mention potential side effects on playback or idempotency, but covers the core behavior sufficiently.

  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 concise sentences, front-loaded with the action and followed by usage guidance and resumption instruction. Every sentence adds value with no redundancy or 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 no-parameter tool with an output schema, the description fully covers the tool's purpose, when to use it, and how to reverse it. It gives an agent enough information to select and invoke the tool 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 input schema has zero properties, so there are no parameters to explain. The description correctly focuses on behavior and usage rather than parameter details, earning the baseline score of 4 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 phrase 'Put the audio engine to sleep' and identifies the resource ('audio engine') and the effect ('suspends audio processing to save CPU'). This clearly distinguishes it from sibling tools like engine_wake, engine_panic, and start_engine.

  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 explicit usage context: 'Useful when doing non-audio operations (project editing, box manipulation) and the engine isn't needed.' It also names the complementary action with 'Use wake() to resume,' directing the agent to the correct sibling for the opposite operation.

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

• mcp_opendaw_get_project_infoA
  4.7/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, so read-only is known. The description adds behavioral scope: it returns specific summary fields and explicitly excludes per-track detail, which is useful context beyond the annotation. No contradictions.

  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: first lists the returned data, second provides usage context and sibling comparison. No redundant words, content 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?

  With an output schema present, no need to document return values separately. No parameters to document. Annotations cover safety. The description explains purpose, scope, and relationship to sibling tool, making it complete for a simple read-only overview.

  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?

  Tool has zero parameters, so schema coverage is trivially 100%. The description doesn't need to explain parameters. Baseline of 4 for no-parameter tools 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?

  Description states exactly what the tool does: 'Get a quick project overview: BPM, time signature, track/AU/effect counts, total duration.' It distinguishes from sibling get_project_state by noting it's 'lighter' and has 'no per-track detail,' making its scope clear.

  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 'Single-call summary — lighter than get_project_state (no per-track detail),' which tells the agent when to use this tool (quick overview) and when not (if per-track detail is needed). This names an alternative and gives an exclusion.

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

• mcp_opendaw_repeat_notesA
  4.7/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 disclosing behavior. It explains the copy-and-transform mechanic, cumulative parameter effects (transpose, velocity decay, time gap), and note-structure preservation. However, it does not explicitly state whether original notes are retained or replaced, which is a minor 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 description is well-structured: a one-sentence summary, a behavioral explanation, and a detailed parameter list. Every sentence adds operational value, and the Args section is essential given the sparse schema. 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 tool with 9 parameters, no annotations, and an output schema, the description covers purpose, mechanics, parameter semantics, and usage context. It omits edge cases (e.g., behavior when region has no notes) but overall provides sufficient detail 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?

  The schema has 0% description coverage, but the Args section fully compensates by documenting all 9 parameters with units, ranges, and behavioral meaning (e.g., velocity_decay: '0=fade out, 1=constant, 0.8=gradual fade'). This is far richer than the bare schema definitions.

  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 'Repeat existing notes in a region N times with per-repeat transformations', specifying the verb, resource, and scope. It explicitly contrasts with create_midi_echo, distinguishing this tool from a sibling and eliminating ambiguity about its function.

  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 create_midi_echo as an alternative and explains the difference: 'Unlike create_midi_echo (which decays feedback repeats), this tool preserves note structure and applies a uniform transform per repeat cycle'. It also lists ideal use cases (sequences, ostinato patterns, motivic development), giving concrete guidance on when to choose this tool.

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

• mcp_opendaw_reset_projectA
  4.7/5.0
  Behavior5/5

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

  Beyond the destructiveHint annotation, the description details what is removed and what is preserved (output audio unit). Also clarifies the behavioral benefit ('without reloading the browser'). No contradiction with 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?

  Three concise sentences, each serving a purpose: action, use case, and a key exception/preservation detail. Effective front-loading of the primary verb and resource.

  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 description completely covers what the tool does, when to use it, and what is preserved, which is especially important for a destructive operation. Output schema covers return values, so no gap there.

  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 baseline is 4. The description does not need to explain parameter syntax, and none are present.

  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?

  Clear, specific verb ('Reset the project') and resource with explicit list of what gets removed (audio units, tracks, regions, effects). Distinguishes from sibling tools by describing a global fresh-state 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?

  Provides explicit usage context: 'Useful for starting a new mix session without reloading the browser.' Does not name alternatives, but no direct alternative exists for this reset operation. Could be improved by stating when not to use (e.g., if you need to preserve current arrangement).

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

• mcp_opendaw_set_note_centsA
  4.7/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, and it does so well: it states determinism, mode-specific behaviors (e.g., 'alternating' alternates +cents/-cents, 'gradient' linearly increases cents), the meaning of 'direction', and the return shape ('notes modified, per-mode details, and average cents applied'). The only gap is that it does not mention reversibility/undo implications or any preconditions for this mutation tool, which would be the natural next addition.

  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 well-structured and justified: a front-loaded one-line summary, an alternative contrast, organized use-case bullets, clearly separated Modes and Args sections, and a return statement. Every section adds necessary value given the tool's complexity and zero schema coverage; it earns its length without being padded.

  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 this tool's high complexity (11 parameters, 7 targeting modes, conditional parameter dependencies) and complete absence of annotations and schema descriptions, the description is remarkably complete. It covers purpose, alternatives, use cases, every parameter, every mode's behavior, direction semantics, and expected return content. Nothing essential is left unexplained for an agent to select and invoke this 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 fully compensate, and it does. All 11 parameters receive meaningful explanations with ranges ('-100 to +100'), defaults via schema, and examples ('0,4,8', '60 or C4', '3,7'). The mode-specific semantics of target_pitch, direction, and scale_degree are clarified beyond what the schema titles alone could ever 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 'Set detune (cents) on notes — deterministic microtonal pitch control,' which states a specific verb, resource, and behavior. It explicitly distinguishes itself from sibling humanize_pitch by contrasting deterministic specific offsets with random cents, making selection unambiguous.

  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 and contrasts the sibling tool humanize_pitch ('Unlike humanize_pitch (random cents)'), providing a clear when-not-to-use signal. It also gives seven specific musical use cases (honky-tonk, quarter-tone scales, maqam, etc.) that illustrate exactly 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.

• mcp_opendaw_shift_modeA
  4.7/5.0
  Behavior4/5

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

  The description discloses the surgical algorithm: only differing degrees shift by interval difference, tonic and unchanged degrees stay put. It explains preserve_root behavior and the return value. However, the first example contains a note-name error ('minor 6th (Ab)' should be F natural), which slightly undermines clarity.

  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 structured with a summary, algorithm, examples, contrasts, args, and return. It is long but every section contributes; the typo is the only blemish.

  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 7-parameter tool with output schema, the description covers the algorithm, examples, parameter meanings, and return format. It lacks an exhaustive list of valid scale names, but examples make it inferable. The typo in example one makes it slightly less 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 Args section fully explains each parameter: default meanings (-1 = all), root_note as pitch class, preserve_root semantics. 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 opens with a clear verb-object: 'Transform notes from one scale/mode to another, keeping the tonic.' It explicitly differentiates from force_scale_notes and reharmonize_progression, and the accompanying examples illustrate concrete musical transformations.

  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 directly states when to use this tool over alternatives: unlike force_scale_notes (which snaps to nearest scale tone and changes contour), shift_mode preserves contour; unlike reharmonize_progression (works on chord symbols), shift_mode works on individual notes. This is explicit usage guidance.

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

• mcp_opendaw_accent_beatsA
  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. It explains the core behavior (accent strength from beat position), lists all accent patterns with meanings, describes interpolation for off-beat notes, and states the return value ('Returns count of notes accented and per-level breakdown'). It does not explicitly state that existing velocities are overwritten or whether undo is possible, but the behavior is well disclosed for a creative 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 longer than average but earned every sentence: it uses clear headings, bullets for patterns, a compact parameter list, and a concise example. It is front-loaded with the main purpose and never wastes words on tautology or repetition of schema info.

  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?

  With 7 parameters, no annotations, and an output schema the description still covers all essential aspects: what the tool does, all patterns, interpolation behavior, parameter explanations, use cases, and return value. The example further grounds the abstraction. This is complete 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%, so the description fully compensates by defining every parameter: unit_index, track_index, accent_pattern with allowed values, strong/medium/weak_velocity with ranges (0-1), and region_index with default meaning. The example additionally demonstrates usage, making parameter semantics exceptionally clear.

  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 beat-aware velocity accents to notes based on their position.' It clearly differentiates from the sibling tool apply_velocity_pattern by explicitly noting the difference (beat position vs. note index), so the agent can select it correctly.

  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 contrasts with 'apply_velocity_pattern (which cycles by note index)' and provides a use cases list ('Make drum patterns feel groovy', 'Add natural dynamics to programmed basslines', etc.). This gives clear guidance on when to use the tool and names an alternative, satisfying the 'when/when-not/alternatives' criterion.

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

• mcp_opendaw_add_bass_chainA
  4.8/5.0
  Behavior4/5

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

  With no annotations, the description explains what it creates (Revamp EQ → Compressor → Waveshaper), returns effect indices and parameter values, and describes the drive_amount range. However, it doesn't disclose whether it appends to or replaces existing effects on the target unit, which is 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.

  Conciseness5/5

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

  The description is well-structured and appropriately sized: it starts with the core function, then covers parameters in a clear list, states what it creates and returns, and finishes with practical examples. Every sentence adds value with no 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?

  Given the tool's complexity and the presence of an output schema, the description covers all essential aspects: purpose, parameters, return values, examples, and relationship to alternatives. It is complete enough for an agent to select and 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 has no descriptions (0% coverage), but the tool description fully compensates: unit_index is explained, style lists all five presets with musical characteristics, and drive_amount includes range, default, and usage guidance. 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 clearly states the tool adds a ready-made bass processing chain (EQ → Compressor + optional Waveshaper) to an audio unit. It uses a specific verb and resource, and the explicit chain structure distinguishes it from sibling tools like add_effect or add_mastering_chain.

  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 explicitly says 'One call replaces 2-3 individual add_effect + set_effect_parameter calls,' naming the alternative. It also notes it's designed for bass but works on any low-frequency content, giving clear context for when to use it.

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

• mcp_opendaw_add_instrument_chainA
  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 discloses the exact effect chain created ('Revamp EQ → Compressor → Reverb (→ Delay)') and the return value ('Returns effect indices and parameter values set'). However, it doesn't state whether the chain is appended to existing effects or replaces them, nor does it mention error conditions (e.g., non-instrument units). This is a minor 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 description is front-loaded with a clear purpose, then uses bullet-style parameter explanations and illustrative examples. Though relatively long, every sentence adds functional value—no fluff or repetition. The structure makes the information easy to scan.

  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 moderate complexity (4 parameters, 5 style presets). The description covers purpose, parameter semantics, style selection, defaults, the exact effect chain, and return values. With an output schema present, this is sufficient for an agent to invoke the tool correctly across diverse use 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 descriptions are entirely absent (0% coverage), so the description carries full responsibility for parameter meaning. It thoroughly explains unit_index, style (with five detailed preset definitions), reverb_amount (0-1, default), and delay_amount (0-1, default). The examples further illustrate parameter combinations, adding value 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 first sentence clearly states the action ('Add a ready-made instrument processing chain') and the exact resource ('EQ → Compressor → Reverb (+ optional Delay)'). It also specifies the target usage ('guitars, keys, synth leads, strings, pads'), distinguishing it from related chain tools like add_drum_chain or add_bass_chain.

  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 frames when to use this tool: 'One call replaces 3-4 individual add_effect + set_effect_parameter calls.' It also gives concrete style recommendations for different instruments, making the use case clear. Although it doesn't name sibling alternatives directly, it defines its scope as 'any melodic/harmonic instrument,' which implies exclusions.

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

• mcp_opendaw_add_vocal_chainA
  4.8/5.0
  Behavior4/5

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

  With no annotations, the description takes on full disclosure responsibility. It details the exact chain created ('Revamp EQ → Compressor → Reverb (→ Delay)'), states the return value ('Returns effect indices and parameter values set'), and explains preset behavior. However, it does not explicitly state whether the chain is appended to existing effects or replaces them, nor does it mention error scenarios (e.g., invalid unit_index), which would be useful for full 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 thorough yet well-organized: opening summary, benefit statement, parameter details in structured bullet-like lines, chain output, and three practical examples. Every sentence contributes useful information without redundancy, making it easy for an agent to parse quickly.

  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 moderate complexity (4 params, 5 presets, output schema) and zero annotations, the description is remarkably complete. It covers purpose, parameter semantics, behavioral details, return values, and usage examples, leaving no significant gaps for an agent to guess about. The output schema handles formal return structure, so the description's mention of return contents is 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 coverage is 0%, so the description must fully document parameters, and it does. Every parameter is explained: unit_index ('Target audio unit'), style with five detailed preset descriptions, and both amount parameters with ranges and defaults. This far exceeds what the schema provides, making invocation behavior predictable.

  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 clearly states the tool's function: 'Add a ready-made vocal processing chain to an audio unit — EQ + compressor + reverb (+ optional delay).' It also distinguishes itself from siblings by explicitly noting 'One call replaces 3-4 individual add_effect + set_effect_parameter calls' and specifies scope ('Designed for vocal tracks but works on any melodic content').

  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 provides explicit guidance on when to use this tool: it replaces multiple add_effect and set_effect_parameter calls, making it the efficient choice for standard vocal chains. It also differentiates from other chain tools (mastering, drum, bass, instrument) by focusing on vocal/melodic content, giving clear context for appropriate usage.

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

• mcp_opendaw_analyze_phaseA
  4.8/5.0
  Behavior5/5

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

  Beyond the readOnlyHint annotation, the description adds substantial behavioral context: the specific phase checks performed, the rationale (mono compatibility), frequency-dependent risks, and what the return value contains. This is genuinely useful information that helps an agent interpret results safely.

  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 tightly structured: a one-line summary, bulleted list of checks, two lines on frequency context, and a final parameter explanation. Every sentence contributes information, 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 single-parameter analysis tool with an output schema, the description is complete. It covers what the tool does, what it detects, how to specify the input, and what the result is about. The output schema handles the exact return format, so no additional detail is needed.

  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 schema description coverage at 0%, the description fully compensates by explaining the filename parameter in detail: 'WAV file in exports dir, or absolute path.' This is essential guidance that turns an otherwise opaque string parameter into a usable one.

  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: 'Per-band phase analysis — coherence, polarity, inter-channel delay.' It then lists concrete checks and the final output (mono compatibility score), clearly distinguishing this from sibling analysis tools like analyze_stereo or analyze_spectrum.

  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 by explaining what problems it detects (phase issues that damage mono compatibility) and provides contextual guidance about low vs. high frequency behavior. However, it does not explicitly name alternatives or 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.

• mcp_opendaw_apply_articulationA
  4.8/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 explains that the tool deterministically reshapes note durations, details each articulation's specific effect (e.g., 'staccato — shorten notes to fraction of their grid slot'), and states the return value. However, it does not explicitly mention irreversibility or in-place modification, though the sibling undo tool exists; this small gap keeps it from a 5.

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

  Conciseness5/5

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

  The description is long but appropriately so for a tool with 5 parameters and 4 articulation variants. It uses clear sectioning, bullet lists for parameters, and concrete examples. No sentence is superfluous; each adds either definitional precision or practical guidance, making the length justified.

  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?

  Despite no annotations and zero schema descriptions, the description covers the tool's purpose, parameter semantics, return type, examples, and relationship to sibling tools. It even explains the algorithmic behavior for each articulation and the impact of amount. The tool is complex, but the description leaves little ambiguity about what will happen when invoked.

  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: unit_index, track_index, region_index (with the -1 special case), articulation (with per-type behavior), and amount (with per-articulation meaning and examples). This far exceeds what the bare schema provides, giving the agent complete parameter understanding.

  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 articulation to existing notes' and enumerates the articulation types. It also explicitly distinguishes the tool from siblings: 'Unlike velocity_curve (dynamics) or humanize (random), this applies deterministic duration ratios', making its scope and unique 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 Guidelines5/5

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

  The description names two direct alternatives (velocity_curve, humanize) and explains why this tool is the right choice for deterministic articulation: 'Unlike velocity_curve (dynamics) or humanize (random), this applies deterministic duration ratios'. This gives clear when-to-use guidance relative to at least two siblings, and the examples further illustrate appropriate invocations.

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

• mcp_opendaw_apply_contourA
  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 full responsibility for behavioral disclosure. It includes important behaviors: timing and duration remain unchanged, original pitch range center is preserved, and snapping to scale degree is optional. However, it does not explicitly state the destructive nature (e.g., that pitches are overwritten) or mention undo/restore implications beyond the preserve flags, leaving a slight 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 description is structured cleanly: purpose statement, algorithm explanation, contour definitions, and args list. Every sentence adds value—no redundant repetition of schema titles or types. It is front-loaded with the primary action and scales into necessary detail 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?

  Given 9 parameters, no annotations, and an existing output schema (so return values need not be described), the description is remarkably complete. It covers the algorithmic behavior, all contour semantics, parameter nuances, and even provides a differentiation from a sibling. This equips the agent to invoke the tool correctly in 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 compensate for the schema's lack of parameter docs. It does this thoroughly: each parameter is explained with units, ranges, defaults, and allowed values (e.g., range_semitones '1-48, default 12=octave', full contour list, scale list). This is essential and well-executed.

  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: 'Apply a melodic contour shape to existing notes.' It further details the behavior (redistributes pitches while keeping timing/duration) and explicitly contrasts with transpose_notes ('uniform shift'), making the tool's unique purpose unmistakable and well-differentiated from 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?

  The description explicitly names the alternative transpose_notes and explains the difference: 'Unlike transpose_notes (uniform shift), this reshapes the melody direction.' This provides a clear when-to-use/when-not-to-use signal, telling the agent to reach for this tool when reshaping contour rather than shifting uniformly.

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

• mcp_opendaw_apply_velocity_curveA
  4.8/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 full burden. It discloses the deterministic mapping mechanism (each note's position to a velocity value), details each curve's mathematical behavior, and states the return value. It stops short of noting irreversibility or clamps on out-of-range inputs, but the disclosure 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?

  Well-structured: purpose, mechanism, differentiation, parameter specs, return value, then three practical examples. No sentence is wasted; the length is justified by the tool's complexity and 0% schema coverage.

  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 7-parameter tool with no annotations and no schema-side parameter descriptions, this description is fully complete. The curve_type values are individually explained, defaults are given, return semantics are stated, and concrete usage examples anchor the 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?

  Schema description coverage is 0%, yet the description documents all 7 parameters with defaults, ranges (0-1 for velocities), and behavioral meaning. 'power' gains extra semantic depth ('2.0 = sharp attack, 0.5 = slow swell'), and region_index's -1 sentinel is explained. 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 verb+resource ('Apply a velocity envelope across notes') and lists the curve variations (ramp, arc, trough, power curve). It explicitly distinguishes itself from the sibling humanize_notes, making the tool's identity unambiguous.

  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 states when to use the tool ('useful for build-ups, fade-ins, crescendo rolls, and expressive phrasing') and explicitly contrasts it with humanize_notes for random variation. This gives an agent clear criteria for choosing this tool over an alternative.

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

• mcp_opendaw_change_base_signatureA
  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 of behavioral disclosure. It transparently states that existing signature change events are recalculated to preserve approximate absolute positions, which is a critical side effect. It also discloses the default signature and return type, offering meaningful behavioral context beyond a simple mutation.

  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 single-sentence purpose, a single-sentence side effect, two lines of parameter definitions, and a return note. Every sentence adds value without any fluff 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?

  Given the tool's simple two-parameter schema and lack of annotations, the description covers all essential aspects: purpose, side effects, parameter semantics, and return value. The output schema further reduces the need to describe return details, making this description complete for safe and effective use.

  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, but the description fully explains both parameters with examples and valid values (e.g., nominator 4 for 4/4, denominator 4 for quarter note). This provides the agent with all necessary information to construct correct arguments without ambiguity.

  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 ('Change the base time signature of the project') with a specific resource and scope. It distinguishes itself from sibling tools by emphasizing the 'base' or 'initial' signature and noting that existing signature change events are recalculated, which sets it apart from tools like add_signature_change or set_time_signature.

  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 context on what the tool does and its effect on existing signature changes, implying it is for global signature changes rather than per-position edits. However, it does not explicitly mention alternative tools or state when not to use it, so it lacks explicit exclusions.

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

• mcp_opendaw_clone_trackA
  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 transparency burden. It clearly discloses creation behavior (new track in same or new audio unit), what is copied (notes, regions, structure), and key constraints (new_unit requires same instrument type). However, it does not explicitly state whether the source track remains unmodified or mention undo behavior, which would be valuable for a mutation-like 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 well-structured with a summary, alternative comparison, practical use cases, and parameter list. Every section adds value; the use-case list is concise and illustrative without being verbose. It is front-loaded with the core purpose and keeps parameter descriptions tight.

  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 7-parameter cloning tool with no annotations, the description is remarkably complete. It covers what the tool does, when to use it, key behavioral details, and parameter semantics. The output schema exists, so no requirement to describe return values. The only minor omission is error-handling specifics, but overall it is comprehensive.

  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, but the description compensates fully with detailed parameter explanations, including ranges and defaults for transpose (-24 to +24), velocity_scale (0.1-2.0), and time_offset_beats (-16 to +16), plus a clear explanation of new_unit's behavior. This goes well beyond the schema's bare titles and defaults.

  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 'Clone a track — full duplication of notes, regions, and structure,' which is a specific verb+resource with clear scope. It further differentiates itself from copy_notes_to_track by stating it creates a new track from scratch, 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 Guidelines5/5

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

  Explicitly contrasts with copy_notes_to_track: 'Unlike copy_notes_to_track (which copies notes between existing tracks), clone_track creates the destination track from scratch.' Also provides a list of concrete use cases ('Essential for: Doubling, Octave layering, Parallel harmony...') that tell the agent when to choose this tool.

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

• mcp_opendaw_consolidate_noteA
  4.8/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 behavioral disclosure burden. It explicitly discloses that the original note is deleted, that the new notes are created as independent playCount=1 notes positioned according to the curve, and that the return value is the number created or an error when playCount=1. This gives the agent essential side-effect and outcome information.

  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. It opens with a clear one-line purpose, follows with a concise explanation of the transformation, lists parameter meanings succinctly, and closes with the return/error behavior. Every sentence carries useful information with no 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?

  The description fully covers the tool's preconditions, behavior, parameter semantics, and return/error behavior. Although an output schema is indicated, the description also states the return value explicitly. Given the moderate complexity and the zero-coverage input schema, this description is sufficiently complete for an agent to select and 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?

  The input schema provides only parameter names and integer types, with zero description coverage. The description compensates fully by defining each parameter's role: unit_index (AU index), track_index, region_index, and note_index within the region. This adds precise hierarchical 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 clearly identifies the operation: consolidating a repeated note (playCount > 1) into individual separate notes. It uses a specific verb ('consolidate') plus the exact target resource (repeated note), and explicitly distinguishes this from ordinary note operations by describing the playCount condition and the expansion behavior.

  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: apply when a note has playCount > 1 and needs to be expanded into independent notes. It also states an exclusion/error case (playCount=1). However, it does not explicitly name alternatives or discuss when other consolidation tools might be more appropriate, so it falls slightly 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.

• mcp_opendaw_constrain_note_rangeA
  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. It discloses the effect on notes (clamping loses pitch info, wrapping preserves pitch class), the fallback behavior, and the return values (adjusted/clamped/wrapped counts). However, it does not state whether the operation is destructive/in-place or if it can be undone, which is a minor 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 long but well-organized with clear sections: introduction, mode explanations, common instrument ranges, parameter list, returns, and examples. Every element adds value and there is 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 tool with 6 parameters, two modes, and no annotations, the description covers all necessary context: what problem it solves, how each mode behaves, parameter semantics, return values, and concrete examples. The added instrument range reference is a thoughtful extra that helps agents choose appropriate min/max values.

  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 fully compensates by explaining every parameter: unit_index, track_index, region_index with '-1 = all' semantics, min/max_pitch with defaults and bounds, and mode values with explanations. This completely covers what 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 states exactly what the tool does: 'Constrain notes to a pitch range' with two distinct modes (clamp and octave_wrap). It clearly identifies the use case (notes out of playable range after generation/transposition) and distinguishes this from sibling tools like transpose_notes or rotate_notes.

  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?

  Explicit guidance is given on when to use the tool ('After AI generation, transcription, or aggressive transposition') and when to choose each mode: clamp for exact range safety (e.g., MIDI 0-127), octave_wrap for instrument ranges. The edge case of ranges smaller than 12 semitones is also documented.

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

• mcp_opendaw_create_bordunA
  4.8/5.0
  Behavior4/5

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

  The description explains key behaviors: sustained vs. retriggered (retrigger_bars), softer default velocity, and the return of created notes. Without annotations, it makes reasonable effort to disclose what the tool does, though it doesn't state whether existing notes on the target track are cleared or appended.

  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?

  Structured with a one-line summary, a contextual definition paragraph, and per-parameter bullet lines, all of which add semantic value 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?

  Covers purpose, usage, all parameters, and return value ('Returns notes created, pitches, total duration'), providing enough context given the tool's complexity and the lack of annotations or schema descriptions.

  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?

  All 10 parameters receive detailed explanations with examples (intervals '0,7' = open fifth), defaults, and ranges (octave 1-6, bars 1-16), fully compensating 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 opening sentence defines the tool precisely: 'Create a bordun — continuously sustained drone chord as a textural layer.' It further contrasts with pedal_point, making the purpose unambiguous and distinct from the sibling tool.

  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 differentiates from pedal_point: 'Unlike pedal_point (which is a single repeated/anchored note), the bordun is a *sustained textural layer*.' This provides clear when-to-use guidance and names the primary alternative.

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

• mcp_opendaw_create_compingA
  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. It explains rhythmic behavior, ghost notes, syncopation, and the return values (notes, chords, rhythm pattern). It does not mention potential side effects on existing notes, but for a creation tool this is a minor omission. The behavior is well-articulated.

  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 long but efficiently structured: clear intro, differentiation, then a parameter list with examples. It is front-loaded with the purpose, and every sentence provides useful information (defaults, examples, semantics) without fluff.

  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 9-parameter tool with one required param and an output schema, the description covers all parameters, return values, usage context, and examples. It also clarifies sibling relationships, making it fully complete for selection and 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 coverage is 0%, yet the description documents every parameter with detailed semantics: chords format and example, rhythm pattern characters and examples, note_spacing, syncopation, and defaults. This fully compensates for the bare schema and adds substantial 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 clearly states 'Create comping — rhythmic chordal accompaniment' and differentiates from sibling tools by explicitly contrasting with create_chord_progression (sustained blocks) and create_stab (house stabs). The verb and resource are specific, and the unique rhythmic identity is highlighted.

  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 provides explicit guidance on when to use this tool versus alternatives: 'Unlike create_chord_progression (sustained blocks) or create_stab (house stabs), comping gives each chord a rhythmic identity.' It also lists genre examples (jazz, funk, reggae, country) to illustrate appropriate use cases.

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

• mcp_opendaw_create_cross_rhythmA
  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 burden. It discloses key behaviors: independent voice cycling, LCM alignment, bars×4 beat fill, voice attenuation, constraints (2-6 voices, bars 1-16), and return values. However, it does not mention whether existing notes are overwritten or appended, which is a potential side effect 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 appropriately sized for a complex tool. It is well-organized with sections for definition, contrast, context, parameters, return values, common patterns, and an example. Every sentence adds value, and the first sentence front-loads the core purpose.

  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?

  Despite 7 parameters and no annotations, the description covers purpose, parameter semantics, usage context, constraints, return values, and examples. The output schema further reduces the need to explain return structure, but the description also covers it. This is complete for the tool's complexity.

  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 every parameter: voices format with example, bars range, unit_index, track_index, start_beat, duration, and base_velocity with attenuation behavior. This goes beyond the schema's type/default info, making the tool usable without external knowledge.

  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 statement: 'Create a cross-rhythm — multiple voices with independent period lengths creating shifting alignment.' It clearly defines what the tool does and explicitly contrasts it with polyrhythm, distinguishing it from sibling tools like mcp_opendaw_create_polyrhythm.

  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 'Unlike polyrhythm...' and explains the difference, providing when-not guidance. It gives musical context (African cross-rhythms, Steve Reich, Talking Heads, minimalism) and common pattern examples, helping the agent decide when to use this tool instead of alternatives.

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

• mcp_opendaw_create_fugatoA
  4.8/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 transparently explains that fugato generates subject, answer, countersubject, and episode material, describes real vs tonal answer modes, and states that an empty subject_notes auto-generates a subject. It also discloses the return value ('notes created, subject preview, voice entries, and fugato structure'). Minor gap: it doesn't address whether creation appends or overwrites existing notes on the target track.

  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 long but well-organized, starting with a definition, then components, answer modes, and Args. Each section serves a purpose, and the stylistic musical explanation contextualizes the tool for an AI agent. Despite its length, it avoids redundancy and 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 the high complexity (16 parameters, fugue theory, no schema descriptions), the description covers the tool's purpose, algorithm, parameter semantics, and return value. The presence of an output schema further reduces the need to detail return structure explicitly, and the description mentions the key return elements. It is a self-contained reference for invoking the 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 coverage is 0%, so the description must compensate, and it does with a full Args section covering all 16 parameters. Notably, subject_notes includes a concrete JSON example and explains pitch_offset semantics. The description goes well beyond the schema titles, providing musically meaningful explanations for answer_mode, countersubject_interval, and episode_bars.

  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 'Create a fugato — a fugal passage with subject entries and imitation,' establishing a clear verb+resource. It further distinguishes itself from create_voice_exchange by stating that fugato generates the entire fugal texture from scratch, 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 Guidelines5/5

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

  The first paragraph explicitly differentiates this tool from create_voice_exchange: 'Unlike create_voice_exchange (transforms existing notes between tracks), fugato generates the entire fugal texture from scratch.' It also clarifies that a fugato is 'not a full fugue,' providing a when-not-to-use boundary. This is strong usage guidance.

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

• mcp_opendaw_create_fugueA
  4.8/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 algorithmic behavior thoroughly: how subject is stated, imitated with tonal/real answer, optional countersubject, and stretto overlap. It also explains defaults and ranges. However, it doesn't mention side effects like whether existing notes in the target track are deleted or if a new region is required, which is a minor transparency gap 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 long but well-organized and front-loaded. The opening two sentences establish the purpose and sibling distinction; then a clear parameter list with inline explanations; finally a return summary. Every sentence provides necessary information for a tool with 14 parameters. It is structured to be scannable 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?

  Given the tool's complexity (14 params, no annotations, no explicit output schema shown), the description is complete: it explains the musical algorithm, all parameter semantics, the return values, and how it differs from a sibling. It even provides guidance on musical choices (e.g., more voices = denser counterpoint). This covers the full context 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.

  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 compensates fully by explaining all 14 parameters with types, ranges, defaults, examples, and cross-relations (e.g., countersubject must be same length as subject, key_root for tonal answer). This exceeds what the schema provides, making parameter semantics excellent.

  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 clear verb+resource: 'Create a fugue — polyphonic composition with subject, answer, and countersubject.' It defines the musical form and distinguishes it from sibling create_canon, which is exactly what a good purpose statement should do.

  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 compares to create_canon: 'Unlike create_canon (strict imitation), a fugue uses tonal answers (adjusted intervals) and independent countersubjects.' This tells the agent when to prefer this tool over an alternative. It also explains optional features (stretto, countersubject) and parameter choices, providing strong usage context.

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

• mcp_opendaw_create_motif_developmentA
  4.8/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 disclosure burden. It reveals key traits: writes a single continuous line (not separate regions), flows through stages without stopping, and returns 'total notes, stage count, pitches used.' It doesn't mention whether existing notes are overwritten or merged, but given the depth of process description, it is largely 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 substantial but every sentence adds value: overview, motivational context, sibling differentiators, and parameter explanations are well-structured and front-loaded. The 'Beethoven 5th' analogy is concise and memorable. No filler or redundant repetition of schema defaults.

  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 complexity (10 params, 0% schema coverage), the description is highly complete. It explains the composition stages, provides examples, lists return values, and states the track/AU requirements ('unit_index: AU index with a note track'). It is more than sufficient for an AI agent to correctly select and invoke 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 description fully compensates for every parameter. It explains motif format with examples ('1,1,1,2' vs '60,60,60,62'), defines each development step (sequence_up, fragment, invert, etc.), and clarifies scale, root, octave, step_duration, velocity, unit_index, track_index, and start_beat. This is far beyond what the schema alone 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+resource: 'Develop a motif into a through-composed melodic line that evolves.' It clearly explains the tool transforms a short motif (2-8 notes) into a continuous melodic line through named compositional stages. It also explicitly distinguishes itself from create_variations and create_sequence, which are 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 Guidelines5/5

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

  The description includes explicit usage guidance: 'Unlike create_variations... create_motif_development writes ONE continuous line' and 'Unlike create_sequence (pure transposition), this tool mixes multiple development techniques.' This tells the agent exactly when to choose this tool over alternatives. It also gives the 'Beethoven 5th approach' analogy as real-world context.

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

• mcp_opendaw_create_passacagliaA
  4.8/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 burden of behavioral disclosure. It explains how the tool generates notes: repeating bass pattern, evolving chords, variation styles, velocities, and placement parameters. It also mentions return values. However, it doesn't explicitly state whether it adds to existing MIDI data or clears/overwrites notes, which could be relevant for an agent deciding whether to call this 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 long but every sentence earns its place. It opens with a concise definition, gives historical/modern context, differentiates from similar tools, then lists all parameters with examples and defaults. The structure is logical and front-loaded with the core purpose, followed by necessary parameter details. No fluff or redundant statements.

  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 complexity (12 parameters, no annotations, no output schema in the provided schema), the description is remarkably complete. It covers the musical concept, parameter semantics, variation styles, time signature handling, and even states return values. The agent has enough information to invoke the tool correctly and interpret the result.

  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 all 12 parameters. It does so thoroughly: each parameter is explained with format, examples, defaults, and sometimes constraints (e.g., 'bass_repeats: 1-16', 'chord_octave: 1-8', 'variation_style: block/arpeggiated/melodic'). The inclusion of concrete musical examples like '36 43 41 36' and 'Cm,Ab,Eb,Bb' makes the parameter semantics exceptionally clear.

  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: 'Create a passacaglia — repeating bass ostinato with evolving harmonies above.' It clearly defines the musical form and provides examples of context (Bach, Buxtehude, film scoring, metal, electronic). It also explicitly distinguishes this tool from related sibling tools (ostinato, pedal_point, bordun), making its 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 Guidelines5/5

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

  The description provides explicit usage context and differentiates from alternatives: 'Distinct from ostinato (single repeating pattern), pedal_point (single sustained note), and bordun (drone chord).' This tells the agent exactly when to choose this tool over its siblings. It also gives genre/context examples where passacaglia is appropriate.

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

• mcp_opendaw_create_synth_trackA
  4.8/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 the creation behavior, the synth type options (including the soundfont sample requirement), and the return values. It does not mention potential side effects like whether existing tracks are affected, but for a creation tool the primary behavior is well 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 efficiently structured: a main purpose sentence, a differentiation paragraph, parameter explanations, and a return-value note. Every sentence adds value, with no redundancy or fluff.

  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 description covers purpose, usage context, parameters, and return values, and includes cross-references to related tools (create_instrument_track, create_note). Given the tool's moderate complexity and the presence of an output schema, this is fully 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 fully. It does: synth_type is explained with all four valid values and their meanings, and name is defined as the display name. This adds all needed 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 clearly states the tool creates a new instrument audio unit with a synthesizer device and a note track, and explicitly contrasts it with create_instrument_track (Tape device vs. MIDI synth). This provides a specific verb, resource, and scope, fully distinguishing it from 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 Guidelines5/5

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

  The description explicitly says to use this over create_instrument_track when a MIDI synthesizer is desired, and notes that the resulting track responds to notes from create_note. This gives clear when-to-use guidance and names an alternative, making the decision easy.

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

• mcp_opendaw_create_walking_bassA
  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. It goes beyond basics by detailing the exact algorithm: beat 1 root, beat 2 chord tone, beat 3 passing tone, beat 4 approach note. It also explains the effect of bars_per_chord and states the return value (total notes and summary), providing comprehensive 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?

  The description is well-structured and front-loaded: purpose, parameter details, algorithm, and example. Each sentence adds value; no redundancy or fluff. Length is justified by the tool's musical complexity.

  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 description covers the algorithm, all parameters, return value, and includes a concrete example. Given the tool's generative complexity and the presence of an output schema, this description is fully complete for an agent to select and 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?

  Although schema description coverage is 0%, the description explains every parameter inline: chords with JSON example, unit_index, track_index, start_beat, octave with range and MIDI note, velocity range, and bars_per_chord behavior. This fully compensates for the schema gap.

  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: 'Create a walking bass line over a chord progression.' It clearly distinguishes this tool from siblings like create_bassline or create_electronic_bass by specifying the musical style (jazz, blues, swing) and the walking bass technique.

  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 by stating 'Essential for jazz, blues, and swing,' implying when this tool is appropriate. It does not explicitly name alternative tools or exclusion criteria, so it misses the 'when-not' guidance that would earn a 5.

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

• mcp_opendaw_delete_sectionA
  4.8/5.0
  Behavior5/5

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

  The description goes far beyond the destructiveHint annotation. It explains the exact scanning behavior, the half-open interval [from_beat, to_beat), the optional unit_indices restriction, and what is returned ('number of regions deleted, per-track details, and remaining counts'). This gives the agent a thorough understanding of the tool's actions and 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 efficiently structured: a one-sentence summary, then behavior, use cases, parameters, return value, and two examples. Every sentence adds value, and the content is well-organized and front-loaded. Although it is longer than typical descriptions, the length is justified by the tool's complexity and the lack of parameter descriptions in the schema.

  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 complexity (multiple tracks, range semantics, optional unit filtering), the description is remarkably complete. It covers the action, the scope, the parameters, and the return value. The presence of an output schema means the description need not detail return structure, but it does anyway. There are no significant gaps for an agent to misuse the 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?

  With schema description coverage at 0%, the description fully compensates by explaining each parameter: from_beat (start), to_beat (exclusive end), and unit_indices (comma-separated AU indices, defaults to all AUs). The examples further clarify usage. This is exactly what a well-compensated parameter section looks like.

  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+scope: 'Delete all regions within a beat range across all tracks.' It distinguishes itself from the sibling delete_region by explicitly saying 'One call replaces N delete_region calls' and positions itself within the CRUD trilogy (duplicate/move/delete). This makes the tool's function unmistakable and differentiated.

  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 concrete use cases ('clear bars 9-12') and explicitly contrasts with delete_region ('One call replaces N delete_region calls'). It does not explicitly state when NOT to use it (e.g., for a single region), but the context is clear enough that an agent can infer the appropriate scenario. The missing explicit exclusion prevents a 5.

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

• mcp_opendaw_diatonic_transpose_notesA
  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. It explains the transformation logic with examples (C major C→D = +1 step), states that it preserves the scale, and specifies the return value ('Returns per-track note counts transposed'). It does not explicitly mention in-place mutation or undoability, but the core behavior is clearly 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 front-loaded with the definition, then provides examples, use cases, and parameter details in a structured layout. Every sentence adds useful information without redundancy. The mild length is justified by the need to explain diatonic transposition and document all parameters outside the schema.

  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 6 parameters and no annotations, the description covers purpose, differentiation, parameter semantics, and return value. The output schema exists, so the return-value note is a bonus; nothing critical 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.

  Parameters5/5

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

  The schema has zero property descriptions, yet the description covers all six parameters with defaults, examples, valid scale names, and step semantics (e.g., '+3 = up a third'). This fully compensates for the schema gap and adds meaning beyond raw types and defaults.

  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 line clearly states 'Transpose notes by scale steps (diatonic) instead of semitones (chromatic)' and contrasts with the sibling transpose_notes, making the tool's unique function unambiguous. The verb 'transpose' plus the resource 'notes' and the specific method 'by scale steps' precisely identifies what it does.

  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 contrasts with transpose_notes ('Unlike transpose_notes ... diatonic transpose preserves the scale') and lists concrete use cases: 'creating variations that stay in key, modal interchange, sequence construction ... walking bass from scale degrees, and counterpoint writing.' This tells an agent when to choose this tool over the chromatic counterpart.

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

• mcp_opendaw_duplicate_sectionA
  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 full burden and delivers: it explains overlap semantics, exclusive end beat, region types supported (note/audio/automation), content preservation, and return value. This goes well beyond a minimal description and fully discloses 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 well-structured: purpose first, then mechanics, parameter list, and examples. Every sentence adds value; no filler or repetition. The examples are concise and illustrate both basic and advanced usage.

  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 complexity (4 params, no annotations, output schema available), the description covers all essential aspects: what the operation does, which regions are affected, how parameters work, return value, and examples. It even clarifies the exclusive range semantics.

  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 has 0% description coverage, but the description provides clear meanings for all four parameters (from_beat, to_beat, target_beat, unit_indices) with additional context like 'beat 0 = start of project' and default behavior for unit_indices. Examples further clarify parameter usage.

  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 duplicates all regions within a beat range to a new position, with specific mechanics described (scans all tracks, finds overlapping regions, copies with relative offset). It distinguishes from siblings like duplicate_region by explicitly working on sections across all tracks and audio units.

  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?

  Clear context is provided with real-world use cases ('copy verse 1 to bar 17') and examples. It doesn't explicitly contrast with single-region duplication tools (e.g., duplicate_region), but the scope ('all regions within a beat range') and 'Scans all tracks' make the intended usage obvious.

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

• mcp_opendaw_export_dry_stemA
  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 burden of behavioral disclosure. It explains what the tool captures (raw instrument output before effects, sends, volume/pan) and states the return value (path to WAV and audio metadata). It does not mention potential side effects like file overwriting or engine prerequisites, but for an export operation 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 well-structured with a concise summary, a clear contrast to the sibling tool, a bulleted parameter list, and a return value statement. Every sentence adds value and there is no redundancy or 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?

  The description is complete for a tool with three simple parameters: it explains what the tool does, when to use it, parameter constraints, and return values. An output schema exists, so return details are adequately covered, and no further context is needed 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 provides only titles and types, but the description adds crucial semantics for all three parameters: unit_index must be > 0 and not the output AU, filename is without .wav extension, and sample_rate defaults to 48000. This 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 clearly states the tool exports a single audio unit as a DRY stem, specifying it captures raw instrument output with no effects or channel strip. It explicitly distinguishes itself from export_single_stem, which routes through the channel strip, 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 Guidelines5/5

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

  The description explicitly contrasts this tool with export_single_stem, clarifying when to use each variant. It also provides concrete use cases (freezing, flattening, re-amping) and notes the constraint that unit_index must not be the output AU, giving clear context for selection.

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

• mcp_opendaw_filter_notesA
  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 fully discloses behavior: 'list' is read-only, 'delete' and 'keep' are destructive, the -1 wildcard behavior is explained, and return values are stated. It clearly tells the agent what changes will be made.

  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?

  Although lengthy, the description is well structured with sections for criteria, actions, use cases, parameters, and examples. Every section adds value, and the core purpose is front-loaded. No redundant or filler sentences.

  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 10-parameter tool with no annotations, the description covers all necessary context: filter criteria, wildcard semantics, destructive vs read-only actions, return values, and musical use cases. The output schema exists and handles return details, so not explaining every field is acceptable.

  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 compensates fully. Every parameter is explained with ranges, defaults, and the -1 wildcard convention. Multiple examples map parameter values to musical outcomes, making the semantics exceptionally clear.

  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+resource ('Filter notes by criteria') and clearly distinguishes the three actions (list/delete/keep). It identifies the note-region scope, which separates it from sibling tools like delete_note or list_notes.

  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?

  Includes a 'Use cases' section with concrete musical examples and specifies that 'list' is read-only while delete/keep are destructive. It lacks an explicit comparison to alternative tools (e.g., when to use list_notes instead), but the guidance is strong and practical.

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

• mcp_opendaw_import_audio_to_tracksA
  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 discloses the operational pipeline: 'create instrument tracks → load each stem → place on tracks at start_beat.' It explains both modes, lists supported file formats, documents return values, and suggests next steps (apply_genre_mix, render_full), providing transparency well beyond a basic summary.

  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 efficiently organized with a pipeline overview, mode explanation, parameter details, return info, and three illustrative examples. Every sentence serves a purpose, and the core purpose is front-loaded, making it easy to scan without unnecessary verbosity.

  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 complexity (4 params, mode variations, pipeline behavior), the description is complete. It covers both import modes, parameter semantics, return data, and even offers workflow suggestions. The output schema's existence reduces the burden for return-value details, but the description still exceeds what's needed for safe usage.

  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 compensates completely. It defines file_path's absolute path and supported formats, enumerates all mode values with their meanings, and explains start_beat and bpm with defaults and effects. This adds substantial semantic 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 opening line states a clear verb+resource: 'Import an audio file into the DAW, optionally split into stems on separate tracks.' The pipeline description (audio file → split → create tracks → load/place) distinguishes it from granular siblings like load_audio or create_audio_track, making the tool's role 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 gives a concrete use case as 'the Suno-to-DAW bridge' and explains when the mode parameter is used vs. not. However, it does not explicitly list when to use this composite tool over manual alternatives (e.g., load_audio + create_audio_track + place_audio_region), so the guidance is context-rich but not exhaustive.

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

• mcp_opendaw_merge_note_tracksA
  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 burden, and it does well: it discloses overlap resolution strategies, source deletion behavior (via delete_source), and transposition range. It also mentions auto-creation for missing dest_region. However, it does not mention error conditions, whether the dest track must be created beforehand, or undo/reversibility; these gaps prevent 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.

  Conciseness5/5

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

  The description is long but well-organized: a one-sentence summary, a contrast paragraph, use cases, and a cleanly formatted Args block. Every sentence adds value, with no filler. The structure makes the long content easy to scan, and the front-loaded purpose ensures the key information is immediate.

  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 complexity (9 parameters, multiple overlap strategies, and an output schema), the description covers everything an agent needs to know to invoke it correctly. It explains the merge semantics, side effects (deletion), edge cases (auto-create dest_region), and option values. There is no obvious missing information that would impede correct usage.

  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 and does fully explain all 9 parameters. Each parameter gets a line with a clear meaning, including the -1 semantics for region indices and a detailed list of all overlap strategies. The transpose range (-24 to 24) and default behaviors are also specified, far exceeding 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+resource: 'Merge notes from a source track into a destination track.' It clearly distinguishes itself from copy_notes_to_track by explaining the difference ('Unlike copy_notes_to_track... merge consolidates two note streams'). It also lists concrete use cases, 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 Guidelines5/5

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

  The description explicitly contrasts with a sibling tool ('Unlike copy_notes_to_track (which just copies)') and gives typical use cases (merge melody, consolidate counterpoint, etc.). It also clarifies the delete_source parameter allows copy versus move behavior, which serves as a guide for when to use this tool versus a plain copy operation.

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

• mcp_opendaw_move_notesA
  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 fully carries the burden. It clearly discloses the mutation behavior: copies notes, auto-creates or appends to a destination region, deletes source notes by default, and clamps velocity to 0-1. It also reveals return fields like source_region_cleared, making the tool's effects 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-structured: a concise first sentence captures the core action, a short paragraph provides usage context, and a bulleted Args list adds necessary parameter details. Every sentence contributes value, and the front-loaded summary allows quick understanding.

  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 description covers all aspects needed for an agent to use this 10-parameter tool: parameter semantics, default behaviors, the difference from copy_notes_to_track, and the return value. It also clarifies edge cases like dest_region=-1. The presence of an output schema further supports completeness.

  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 Args section explains every one of the 10 parameters with additional meaning beyond the schema titles, including defaults and examples (e.g., velocity_scale: '0.8 = quieter, 1.2 = louder'). This 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 clearly states the operation: 'Move notes from a source region to another track — copy + delete.' This specific verb-resource pair distinguishes it from sibling tools like copy_notes_to_track, especially with the delete_source parameter explicitly linking to copy behavior.

  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 use cases: 'Useful for splitting material across tracks, reorganising arrangements, or moving a section to a different instrument.' It also references copy_notes_to_track when delete_source=False, giving an alternative. However, it does not explicitly say when NOT to use it, so it lacks a full when-not/exclusion statement.

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

• mcp_opendaw_move_sectionA
  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 burden. It discloses the cut-and-paste behavior, that it scans all tracks across specified AUs, and that it returns move details. However, it does not discuss edge cases like target collisions or overlapping source/target ranges, which leaves some 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?

  The description is front-loaded with a one-sentence summary, followed by a logical breakdown: behavior, parameters, return, examples. No sentences are redundant; the examples earn their place by clarifying the half-open range and offset logic.

  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 moderate complexity and the presence of an output schema, the description covers all necessary aspects: operation scope, parameter meanings, return values, and explicit comparison to duplicate_section. It even explains the relative offset behavior and default AU handling, making it fully actionable for 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%, so the description must fully define parameters. It does, specifying from_beat, to_beat (exclusive), target_beat (relative to project start), and unit_indices (comma-separated, default all AUs). The examples further illustrate the beat-to-bar mapping, 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 opens with 'Move all regions within a beat range to a new position' and explicitly frames it as a non-destructive cut-and-paste, contrasting with duplicate_section. This specifies a concrete verb+resource and differentiates it from sibling rearrangement 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?

  It explicitly names an alternative: 'Unlike duplicate_section, this removes the original.' It also explains the ideal use case ('move the bridge from bar 33 to bar 17') and highlights that one call replaces delete+create sequences, giving clear when-to-use guidance.

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

• mcp_opendaw_scale_durationsA
  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 full responsibility for behavioral disclosure and delivers comprehensively. It details each mode's exact behavior (multiply, add, set, quantize, legato), explicitly mentions clamping to min/max, quantize overriding value, and legato gap semantics. It also states the return value (count of notes modified and duration stats), providing a thorough behavioral contract.

  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 detailed but well-organized: an introductory summary, a structured list of modes with clear definitions, parameter explanations, and a practical example block. Every sentence adds meaningful information; no filler or redundancy. The formatting with bullets and spacing enhances readability without bloating the 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 complexity (8 parameters, 5 modes, clamping, quantize override), the description covers all necessary context: parameter meaning, mode behavior, defaults, and examples. The return value is also described, which, combined with the output schema, gives a complete picture. No significant gaps remain.

  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 for all 8 parameters. It does so by explaining every mode's effect on the value parameter, defining min/max as clamp range, region_index's -1 meaning, and quantize override behavior. The inclusion of concrete examples (e.g., mode=multiply with value=0.5) further clarifies parameter usage 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 clearly states the tool's purpose: 'Scale the duration of all notes in a region' with an explicit scope (MIDI note length control). It distinguishes itself from siblings by referencing scale_velocity ('Like scale_velocity but for note durations'), making it immediately clear which operation it performs and how it differs from similar 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 provides clear usage context: 'Useful for changing articulation globally — make all notes shorter (staccato feel), longer (legato feel), or snap to a grid.' It also names an alternative (scale_velocity) to clarify when this tool is not appropriate. While it doesn't explicitly enumerate when not to use it, the comparison to scale_velocity gives a strong implicit guideline.

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

• mcp_opendaw_split_note_regionA
  4.8/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 full burden, and it excels: it explains that a new region is created, the original is trimmed, and that straddling notes are kept in the original region (with a DAW-behavior rationale). It also states that the function returns original and new region details, covering key behavioral 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 well-structured and front-loaded, starting with a clear one-sentence summary followed by behavioral details, use cases, parameter explanations, and an example. Every section earns its place and the example illustrates usage concretely 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?

  The tool has moderate complexity with four required parameters and an output schema, and the description provides comprehensive coverage: behavior, parameter constraints, edge-case handling, return value note, and an example. The output schema covers return structure, so the description needn't detail that further.

  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 each parameter: unit_index is 'AU index', track_index is 'Note track index', region_index is 'Region to split (0-based)', and split_beat is 'Absolute beat position to split at (must be within region range)'. This adds significant meaning beyond the bare parameter names.

  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 'Split a note region into two at a given beat position,' a specific verb+resource+parameter statement that clearly defines the operation. It distinguishes this from sibling tools like delete_note_region, duplicate_note_region, and merge_note_regions by explicitly describing the split behavior.

  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 'Use cases' section provides clear contextual guidance, including dividing long regions, cutting silence off the end, creating variations, and preparing for arrangement edits. It doesn't explicitly name alternatives or say when not to use it, but the listed scenarios make the appropriate usage clear.

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

• mcp_opendaw_split_stemsA
  4.8/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 local GPU execution with hardware specs and runtime estimate, automatic resampling to 44100Hz, mode-specific behaviors, DAW bridge requirement for import_to_daw, and return value format. This goes far beyond the schema in explaining what happens when the tool is invoked.

  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, starting with a concise purpose statement, a brief hardware note, a detailed but organized mode list, and clear workflow examples. Every sentence contributes value, and the formatting makes it easy to scan.

  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 complexity (multiple modes, file I/O, optional DAW integration, performance characteristics), the description covers purpose, parameters, return values, prerequisites, and even output_dir defaults. The only omission is error handling, but that is not critical given the thorough coverage elsewhere.

  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, but the description fully compensates by explaining each parameter: input_path must be an absolute path, mode has seven enumerated options with semantics, output_dir has a default and pattern, and import_to_daw describes its effect and prerequisite. This adds critical meaning beyond the bare schema definitions.

  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: 'Split an audio file into stems using SOTA open-source separation models.' This clearly states the tool's function and differentiates it from sibling tools like mcp_opendaw_export_stems or mcp_opendaw_separate_stems by emphasizing input is an audio file and the action is splitting into stems.

  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 case ('Split an audio file into stems') and detailed mode explanations with specific trade-offs (e.g., 'ensemble: Max quality, 4 passes... Slowest, best SDR'). It includes workflow examples but does not explicitly compare with alternatives like mcp_opendaw_export_stems, so usage context is clear but exclusion criteria are absent.

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

• mcp_opendaw_strum_notesA
  4.8/5.0
  Behavior5/5

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

  Despite no annotations, the description discloses the algorithm in detail: notes are grouped by simultaneous start, sorted by pitch, then offset by speed × index. It explains the effect on the first note, parameter ranges, and even mentions the return value. This goes well beyond a basic description.

  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 efficient and well-structured: purpose, method, parameter details, return value, and examples. No fluff; the technical details are necessary for correct use.

  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 complex MIDI transformation tool with 6 optional parameters and no annotations, the description covers operation, parameter semantics, return value, and usage examples. The output schema covers return structure, so the description need not do 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?

  All six parameters are explained in the description, including direction values, speed ranges with musical equivalents, jitter range, and index semantics. Since the schema provides no descriptions (0% 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?

  States the tool's function with a specific verb and resource: 'Strum simultaneous notes — convert block chords into guitar-style strums.' The description distinguishes this from sibling tools by focusing on strumming chord voicings, not other rhythmic manipulations.

  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 use context: it is for block chords that start simultaneously, converting them into guitar-style strums. Examples show common scenarios (downstroke, upstroke, humanization). However, it does not explicitly name alternatives or exclusions, so it stops short of full when-not guidance.

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

• mcp_opendaw_subdivide_notesA
  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 delivers extensively. It discloses that 'Original notes are replaced in place when same track,' explains the override behavior (accent_first overridden by velocity_pattern), and details the effects of pitch and velocity patterns. This goes far beyond a basic statement and gives the agent concrete 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 well-structured: an opening summary, a use-case paragraph, and a clear Args block. Every sentence serves a purpose, providing necessary detail without fluff. It is longer than some, but the tool's complexity (8 parameters, multiple pattern options) justifies the length. 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.

  Completeness5/5

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

  Given the tool's complexity, no annotations, and the presence of an output schema, the description covers all necessary ground: purpose, usage context, parameter semantics, and behavioral effects (replacement, overrides). Return values are presumably handled by the output schema, so the absence of that info is not a gap. This is a fully realized description.

  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 no property descriptions (0% coverage), so the Args section in the description is essential. It explains every parameter with meaningful detail: examples for subdivisions (2=diminution, 4=sixteenth fragmentation), enumerates all pitch and velocity pattern options, and clarifies default behaviors like region_index=-1 meaning first region. This adds substantial value 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 action: 'Subdivide each note in a region into N smaller notes,' clearly identifying the verb, resource, and scope. It also distinguishes this tool from siblings by emphasizing its use for diminution and rhythmic fragmentation, which differentiates it from tools like create_chop or double_melody.

  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 context on when to use the tool: 'Useful for diminution (quarter → 2 eighths), rhythmic fragmentation, and creating faster passagework from longer notes.' However, it does not explicitly state when not to use it or reference alternative sibling tools, so it stops short of full explicit guidance.

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

• mcp_opendaw_time_warp_notesA
  4.8/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 that both position and duration are scaled, explains the two origin behaviors ('start' preserves relative spacing, 'zero' warps from absolute zero), notes that the DAW BPM is unchanged, and states the return value. It doesn't mention potential edge cases like overlapping notes or undo behavior, but covers the core behavioral traits thoroughly.

  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: an opening definition, a contrast with the sibling, use cases, parameter breakdown, and a return note. Each sentence contributes value without redundancy, and the most important information is front-loaded for quick scanning.

  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 description is complete for selection and invocation: it covers purpose, usage guidelines, all parameters, return values, and a key behavioral distinction. Even though an output schema exists, the description still briefly mentions what is returned, making it self-sufficient for the 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?

  All five parameters are explained with meaningful semantics beyond the schema: index defaults (-1 meaning all), warp_factor range and examples (0.5, 2.0, etc.), and origin behaviors. This fully compensates for the 0% schema description coverage, giving the agent everything needed to set parameters 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 clearly states the tool warps note positions and durations by a factor, with specific examples (half-time, double-time) and a direct contrast to scale_durations. It specifies the verb (warp), resource (note positions and durations), and scope (every note in a region), effectively distinguishing it from 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 Guidelines5/5

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

  Explicitly names scale_durations as an alternative and explains when to use this tool (true time warp) versus that one (only duration change). It also gives concrete musical use cases for half-time (trap, lofi, build-ups) and double-time (intensifying sections, fills), providing clear context for selection.

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

• mcp_opendaw_transcribe_drumsA
  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 admirably. It discloses the entire processing pipeline (frequency bands, onset detection, pitch mapping, velocity estimation), the use of create_notes_batch for note creation, and the return values. It even explains the sensitivity threshold semantics.

  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 with a summary, numbered pipeline, use cases, parameter list, return values, and an example. It is long but every section adds value, and the front-loaded purpose ensures quick comprehension.

  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 complex audio transcription tool with no annotations, the description covers input format, algorithm details, parameter semantics, return values, and examples. It leaves no critical gap and even provides practical usage context for integration.

  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 fully. It explains every parameter in plain language: filename (path semantics), bpm (0=auto-detect), sensitivity (range and default), unit_index, and track_index. This goes far beyond the schema's type/default info.

  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 statement: 'Transcribe drum onsets from an audio file into MIDI notes on a DAW track.' It clearly distinguishes this from siblings like transcribe_melody and transcribe_audio by focusing on drum onsets, and the pipeline and use cases reinforce the specific 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 provides concrete use cases (extract drum groove, transcribe recording, replace drums) and explicitly references detect_bpm as a prerequisite for auto-detection. It implies when to use this tool, though it lacks an explicit 'when not to use' or named alternative for non-drum audio.

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

• mcp_opendaw_scale_velocityA
  4.9/5.0
  Behavior5/5

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

  With no annotations, the description takes full responsibility for behavioral disclosure. It explains all five scaling modes with clamping behavior, describes the return value (count, original and new velocity ranges), and provides three concrete examples with expected outcomes. This goes far 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 lengthy but every sentence earns its place: definition, differentiation, parameter breakdown, return value, and examples. It's well-structured with clear hierarchy, making the complexity approachable without unnecessary fluff.

  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?

  Despite zero schema coverage and no annotations, the description covers every aspect needed to invoke the tool correctly: purpose, usage context, all parameters, mode-specific behavior, clamping, return value, and practical examples. It is a complete standalone reference.

  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 description provides exhaustive semantics for mode (all five options with formulas), value, region_index, and min_velocity/max_velocity, going far beyond the schema's bare parameter names. However, it omits explicit explanation for the required unit_index and track_index parameters, though the examples imply their positional role.

  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 'Scale' and resource 'velocity of all notes in a region', clearly stating the tool's core function. It immediately distinguishes itself from create_crescendo with an 'Unlike' clause, making its unique 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 Guidelines5/5

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

  The description explicitly contrasts with create_crescendo, stating what that tool does (gradient) versus what this tool does (uniform scaling). This gives the agent clear when-not guidance and an explicit alternative, satisfying the top of the scale.

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

• mcp_opendaw_add_anticipationA
  5/5.0
  Behavior5/5

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

  With no annotations, the description carries full burden. It discloses the algorithm (finds notes on strong beats, inserts anticipation before them), the structural transformation '[original note shortened] → [anticipation on weak beat] → [strong beat note]', and cross_track behavior that preserves original notes when set. This exceeds typical 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 long but appropriately so for an 11-parameter tool. It is logically structured: definition, comparison, structure, operational summary, genres, and parameter details. Every sentence adds value with no 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?

  The description covers the musical concept, algorithm behavior, all parameters, genre applicability, and cross-track options. An output schema exists, so not describing return values is acceptable. This is a complete, self-sufficient description.

  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 compensates thoroughly by documenting all 11 parameters with ranges, defaults, and musical rationale, e.g., anticipation_offset '0.0625-0.5, default 0.25 = sixteenth note before' and direction options with meanings. No parameter is left unexplained.

  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 opening line 'Add anticipation notes before strong-beat notes' is a specific verb+resource statement. The description further distinguishes this from sibling tools like passing tones, suspensions, and neighbor tones, making it unmistakably the anticipation ornament tool.

  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 'passing tones (which connect two different pitches stepwise), suspensions (which hold a note into the next chord), and neighbor tones (which ornament a single note)' and names applicable genres (jazz, pop, Latin), providing clear when-to-use context and differentiation from similar tools.

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

• mcp_opendaw_analyze_spectrumA
  5/5.0
  Behavior5/5

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

  The readOnlyHint annotation already declares it as a safe read operation. The description adds substantial context: input requirements (WAV file in exports directory or absolute path), the exact return content (band-by-band analysis, global descriptors, mix suggestions), and semantics of each metric (e.g., spectral_centroid as brightness). No contradiction with 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?

  Well-structured with a clear opening line, bullet-point frequency bands, metric definitions, and usage examples. The length is justified by the density of useful information; every sentence contributes value, and critical information (purpose, workflow, args) 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?

  Covers input expectations, output content (band-by-band analysis, global descriptors, mix suggestions), and interpretation guidance. With an output schema present, it doesn't need to detail exact return types, but it provides sufficient context for correct invocation and result usage.

  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?

  Although schema coverage is 0%, the description fully compensates with the Args section: 'filename: Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.' This precisely specifies the single parameter's format and acceptable values, going beyond the bare schema 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 clearly states the tool's purpose: 'Spectral analysis of audio across 7 ISO frequency bands' followed by detailed band definitions and metrics. This distinguishes it from sibling analysis tools like analyze_stereo, analyze_dynamics, and analyze_mix by focusing specifically on spectrum analysis.

  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 provides usage context: 'Use after analyze_track for mix decisions' and gives concrete interpretation rules (e.g., high low_high_ratio → bass-heavy mix, low spectral_centroid → dark/muffled). This tells the agent when to invoke the tool and how to act on the results.

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

• mcp_opendaw_apply_genre_mixA
  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 disclosure burden. It details per-track effect recipes (compressor+EQ, saturation, reverb/delay, sidechain) and specifies genre-specific variations. It also discloses sidechain behavior and returns the effects added per track, giving full visibility into the operation's outcome.

  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 uses tight lead sentences, bulleted recipe lists, a compact parameter explanation block, and two clarifying examples. Each section earns its place without redundancy, and the most important information (purpose and workflow) 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?

  With 4 parameters and zero schema descriptions, this description covers all necessary invocation context: usage scenario, workflow position, genre-specific behavior, parameter constraints, and return value. The output schema exists, and the description states it returns 'effects added per track and parameter values', so 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?

  Schema description coverage is 0%, but the description thoroughly compensates for every parameter: genre lists the 11 allowed values, unit_index is defined as 'AU index with the arrangement tracks', num_tracks is specified as '3 or 4, must match arrangement', and sidechain is described as 'drums→bass' with genre-family guidance. This is exactly what the agent needs to invoke 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?

  Description opens with 'Apply genre-specific mixing effects to tracks after creating an arrangement' – a specific verb+resource+context. It clearly distinguishes itself from sibling tools like create_*arrangement and manual effect-chaining calls by positioning itself as the connection between arrangement creation and rendering.

  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 places tool in the workflow: 'Closes the loop: create arrangement → apply genre mix → ready to render.' It also states this replaces '10-20 manual add_effect + set_effect_parameter calls', directly identifying the alternative. Examples pair it with specific arrangement-creation functions (create_dnb_arrangement, create_jazz_arrangement), making when-to-use unmistakable.

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

• mcp_opendaw_apply_swingA
  5/5.0
  Behavior5/5

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

  No annotations are present, so the description carries full burden. It discloses key behavioral traits: no velocity/duration changes, deterministic, no randomness, reversible, and returns per-track note counts shifted. This gives the agent a solid safety and side-effect profile.

  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 structured with a purpose statement, parameter details, return value, and a usage example. Every sentence adds value; there is no fluff 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?

  With no annotations and a rich schema, the description covers what the tool does, when to use it, parameter semantics, return value, and an example. This leaves no significant gaps for an agent to select and 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 coverage is 0%, but the description explains all four parameters in detail: unit_index, track_index, swing_amount (including range and musical examples like 0.55-0.66 for hip-hop/lofi), and grid (with default and interpretation). 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 opens with a specific action: 'Apply swing feel to existing notes without changing velocity or duration.' It also explicitly contrasts with humanize_notes, making the purpose and distinction from siblings clear.

  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 states when to use this tool versus an alternative: 'Unlike humanize_notes (which couples swing with random velocity/timing changes), this tool applies pure swing.' This tells the agent when to choose this over a known sibling.

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

• mcp_opendaw_clear_region_notesA
  5/5.0
  Behavior5/5

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

  Even though the annotation destructiveHint=true already signals mutating behavior, the description goes further by explaining precisely what is preserved (region position, duration, track placement) and what is returned (notes cleared, remaining region info). It also documents the special -1 behavior, adding transparency beyond the annotation.

  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: a one-line summary, a clarifying elaboration, differentiation from siblings, parameter explanations, return value note, and two examples. Every sentence adds value, and the front-loaded summary immediately conveys the core purpose.

  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 destructive nature and three parameters, the description is complete: it covers behavior, scope, special values, return values, and even provides worked examples. The output schema isn't shown, but the return value is described in prose, and the sibling differentiation fills any remaining context 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 has 0% description coverage, so the description must fully compensate. It does: unit_index, track_index, and region_index are all explained, with the crucial -1 = all note regions on the track semantics. Concrete examples make parameter usage crystal clear.

  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: 'Clear all notes from a region while keeping the region on the timeline.' It clearly distinguishes itself from siblings by explicitly comparing to delete_note_region and delete_note, 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 Guidelines5/5

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

  It explicitly states when to use this tool: as the 'erase and rewrite' operation when the producer wants to start fresh without deleting the region container. It also names alternatives and what they do differently, giving clear when-to-use vs. 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.

• mcp_opendaw_create_random_walk_melodyA
  5/5.0
  Behavior5/5

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

  With no annotations, the description fully discloses the stochastic algorithm: notes depend on previous ones, max_step constrains movement, direction_bias sets probability, and boundary behavior controls octave limits. It even mentions return statistics (range, average interval, direction ratio), giving a clear picture of the tool's behavior beyond its name and schema.

  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 long but well-structured: a clear opening definition, algorithm explanation, artistic context, sibling comparison, and a systematically formatted Args list. Given 16 parameters, every section earns its place without redundancy or fluff.

  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?

  Despite 16 parameters, zero schema descriptions, and no annotations, the description covers all parameters, provides defaults, ranges, relationships (e.g., bars vs duration), musical use cases, and return values. The output schema is noted as present, so not explaining exact return structure is acceptable. It is complete for a complex generative 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 coverage is 0%, but the description documents every parameter with ranges, defaults, and examples. For instance, 'max_step: Maximum scale steps per move (1-7, default 3). 1 = only adjacent scale tones...' and 'direction_bias: -1.0 to +1.0... 0.5 = 75% chance up.' 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.

  Purpose5/5

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

  The description states exactly what the tool does: 'Create a melody using a random walk through a scale — stochastic generation.' It uses a specific verb, resource, and method, and clearly distinguishes itself from the sibling generate_melody by contrasting stepwise dependence with contour-guided weighted random.

  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 provides rich usage context, naming aesthetic applications (Eno, Xenakis, ambient textures, IDM melodies) and explicitly comparing to generate_melody: 'Unlike generate_melody (contour-guided weighted random), random walk produces stepwise motion where each note depends on the previous one.' This tells the agent when to choose this tool over an alternative.

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

• mcp_opendaw_create_solo_automationA
  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 goes into significant detail about internal behavior: 'Internally calls create_mute_automation for each non-solo track with events [[0, false], [start_beat, true], [end_beat, false]] — audible before solo, muted during, audible after.' This discloses the exact event sequence and guarantees restoration, far exceeding typical 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 well-structured: summary, use case, internal mechanics, parameter list with examples, return value, and examples. It is longer than a two-liner, but every sentence adds value given the low schema coverage. The front-loaded first sentence conveys the core purpose immediately, and the structure is easy to scan.

  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 tool has 5 parameters, no annotations, and a non-trivial behavior (multi-track mute automation). The description covers the use case, internal implementation, each parameter, return value, and practical examples, making it fully self-contained. It even mentions the output in prose, aligning with the output schema.

  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 manually explains every parameter: solo_track, total_tracks, start_beat, end_beat, unit_indices — including types, defaults, and examples. It even provides two code examples showing realistic parameter values, fully compensating 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.

  Purpose5/5

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

  The description opens with a precise action statement: 'Mute all tracks except the solo track for a beat range, then restore.' It clearly identifies the resource (tracks) and the operation (mute/restore), and it distinguishes itself from the sibling tool create_mute_automation by emphasizing it is a one-shot solution.

  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 explicitly explains when to use this tool: 'Essential production technique: spotlight one element... Without this you need N separate create_mute_automation calls with coordinated timing — this tool does it in one shot.' It names the alternative and gives concrete musical examples (drum break, bass spotlight), making the use case unmistakable.

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

• mcp_opendaw_create_stutterA
  5/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 succeeds: it explains the algorithmic behavior (rate evolution patterns, accent structures, velocity ramps, gate, pitch jitter), and discloses that it uses a seeded random generator for reproducibility. It also describes return values, so the agent knows what to 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 long but every sentence earns its place. It is front-loaded with a one-line purpose, then context, then a structured parameter list. The line breaks and bullet lists make it easily scannable despite the length.

  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?

  All 13 parameters are fully explained, usage context is given, and return values are specified. The description is completely self-sufficient given the abundant defaults and the output schema note.

  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 compensates thoroughly by documenting each of the 13 parameters with plain-language meaning, valid ranges, defaults, and musical intent. It adds meaning far beyond the schema's type/default definitions.

  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 precise verb+resource: 'Create a stutter edit' and defines it as 'rapid rhythmic repetitions with evolving rate and dynamics.' It distinguishes from sibling tools by explicitly contrasting with create_chop and create_trill, and lists specific musical use cases.

  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 explicit when-to-use guidance: 'Unlike create_chop... or create_trill... stutter edit evolves over time' and includes a bulleted list of essential use cases (build-up transitions, glitch fills, vocal-chop patterns, energy ramps). This clearly directs the agent to choose this tool over alternatives.

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

• mcp_opendaw_create_track_regionA
  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 full burden. It discloses the error condition for audio tracks, the auto-detection of track type, default naming and hue behavior, and the return payload (region UUID, type, position). This goes well beyond a simple 'creates a region' 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 description is well-organized with an opening summary, bullet points for track-type behavior, a parameter list, and a return-value note. Every sentence serves a purpose, with no redundancy or unnecessary 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?

  Given the tool's complexity (6 parameters, no annotations, output schema present), the description covers the core function, auto-detection behavior, error condition, parameter semantics, and return values. It is sufficient for an agent to invoke the tool correctly without additional 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%, but the description fully compensates by explaining all six parameters: unit_index (-1 = search all AUs), track_index, start_beat, duration_beats, name (empty = auto), and hue (0-360, -1 = auto). This gives the agent everything needed to fill the parameters 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 clearly states the tool creates a region on any track (note or value) using a generic API, and explicitly distinguishes it from audio-track region creation by directing the user to place_audio_region instead. The verb 'Create' plus resource 'region' and scope 'track' 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 Guidelines5/5

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

  It provides explicit usage context: automatically detects track type, supports note and value tracks, and for audio tracks it returns an error and directs to the alternative tool (place_audio_region). This is a clear when-to-use and when-not-to-use guideline, unmatched by siblings.

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

• mcp_opendaw_detect_scale_from_notesA
  5/5.0
  Behavior5/5

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

  The description explains the analysis method (pitch class distribution, Pearson correlation, 15 scales) and discloses the full return structure including confidence rating. It adds substantial behavioral context beyond the readOnlyHint annotation, without contradicting it.

  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 long but well-structured with clear sections: purpose, method, scale list, return fields, use-before list, parameter definitions, and a concrete example. Every section earns its place and the core statement 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?

  The description covers the tool's full behavior: what input it needs, what analysis it performs, what it returns, how it relates to other tools, and a usage example. Given the tool's analytical complexity and the sparse schema, this description is complete and leaves no essential 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%, but the description provides meaningful explanations for all three parameters: unit_index (AU index), track_index (Note track index), and region_index with special values (-1 = first region, -2 = all regions). 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.

  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 statement: 'Detect the musical scale/key from MIDI notes in a region.' It also explicitly distinguishes itself from the sibling tool detect_key, which works on WAV audio, making the tool's purpose and scope unmistakable.

  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 directly contrasts with detect_key (audio vs MIDI) and provides an explicit 'Use this before' list naming force_scale_notes, diatonic_transpose_notes, generate_melody, and reharmonize_progression. This gives clear when-to-use guidance and alternatives.

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

• mcp_opendaw_reorder_sectionsA
  5/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 an excellent job. It explains the algorithm (collects note content, places in new order, back-to-back, from original start), handles edge cases (overlapping sections are allowed but placed sequentially), and states what is returned. This is far beyond a basic 'reorders sections' 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?

  Though the description is longer than typical, every sentence adds value: a one-line summary, behavioral details, parameter explanation with example, and return information. It is well-organized and front-loaded, making it easy for an agent to grasp the essential information quickly.

  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?

  Despite having an output schema, the description still mentions the return values, and it fully covers the parameter semantics, behavioral rules, and usage context. For a tool with this complexity (full song structure rearrangement), the description is comprehensive and 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 coverage is 0%, so the description fully compensates by explaining both parameters in detail. It defines section_order as a JSON array with start/end beats, gives an example, and clarifies ordering semantics (sections placed sequentially). It also explains unit_indices and its default behavior ("" = all units).

  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's purpose with a specific verb and resource: 'Reorder song sections — rearrange blocks on the timeline.' It also explicitly distinguishes itself from the sibling tool swap_sections, making it clear this is the full structure editor versus a simple swap.

  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 guidance on when to use this tool: 'This is the full song structure editor: instead of swapping two sections (swap_sections), you can completely rearrange the form.' It also includes a concrete example of transforming a song structure, giving the agent clear usage context.

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

• mcp_opendaw_shuffle_notesA
  5/5.0
  Behavior5/5

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

  With no annotations provided, the description fully carries the burden of behavioral disclosure. It explains key traits: random permutation, seed-based reproducibility, and the effect of shuffle_amount on the fraction of notes shuffled. It also clarifies what each mode preserves (rhythm, pitches, timing windows), making the operation's behavior transparent beyond the raw schema.

  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 into clear sections (usage, modes, args), with the first sentence delivering the core purpose. While it is relatively long, every sentence provides value—explaining modes, parameters, or reproducibility. The front-loaded contrast with rotate_notes helps the agent quickly categorize the tool.

  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 9-parameter tool with no annotations, the description covers all essential aspects: the operation, every mode, every parameter, and the deterministic seed behavior. The presence of an output schema means return values are already defined elsewhere, and the description does not need to redundantly explain them. No critical gaps remain.

  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 for parameters, but the description's 'Args' section provides explicit meanings and defaults for all 9 parameters (e.g., 'shuffle_amount: 0.0-1.0, fraction of notes to shuffle', 'group_beats: Group size in beats for within_groups mode'). This fully compensates for the schema gap and adds semantic richness that the schema fields lack.

  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: 'Shuffle note data randomly within a region.' It clearly distinguishes itself from the sibling tool rotate_notes by explaining the difference between random permutation and deterministic cyclic shift. The purpose 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 Guidelines5/5

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

  The description explicitly names an alternative (rotate_notes) and contrasts it, telling the agent when to prefer this tool over the sibling. It also provides detailed mode-by-mode guidance, including a recommendation for the 'pitches' mode ('Most musical'), which helps the agent decide which mode to invoke. This goes beyond merely stating what the tool does; it actively directs selection.

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

• mcp_opendaw_transcribe_audioA
  5/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. It explains the pipeline (parse WAV, auto-detect BPM, transcribe drums with pitch mappings, transcribe melody, create notes via batch), and documents return values, making its behavior highly 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?

  Well-structured with summary, pipeline, use cases, parameters, returns, and example. Every section earns its place, and the key purpose 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?

  Despite being a composite tool, the description covers purpose, pipeline, parameters, return values, and examples. There is no output schema provided, so the explicit return list is valuable, and no gaps remain 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 coverage is 0%, so the description fully compensates by explaining every parameter: filename (exports dir or absolute path), bpm auto-detect, unit_index, drum_track, and melody_track defaults. It includes a concrete usage example.

  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 exactly what it does: transcribes a full audio track (drums + melody) into MIDI notes in one call, and explicitly says it runs transcribe_drums + transcribe_melody, distinguishing it from those 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 Guidelines5/5

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

  Clearly says it eliminates 2 separate calls and positions it in the Suno-to-MIDI pipeline, with concrete use cases. This gives strong guidance on when to use this composite tool versus the individual transcription tools.

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