opendaw-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.385.0
Disambiguation3/5
With 515 tools, there is notable overlap in functionality, e.g., multiple melody generation tools (create_melody, generate_melody, create_random_walk_melody) and numerous genre arrangement tools. While many tools are distinct, the sheer volume creates ambiguity for an agent selecting the correct tool.
Naming Consistency4/5
All tools share the consistent prefix 'mcp_opendaw_' and generally follow a verb_noun pattern (e.g., create_bassline, add_effect). Minor deviations exist (e.g., engine_panic, engine_sleep) but overall naming is predictable.
Tool Count1/5
515 tools is far beyond the typical well-scoped set (3-15). While the DAW domain is broad, this number suggests over-fragmentation and will overwhelm agents with choices, making efficient selection difficult.
Completeness5/5
The tool set appears exhaustive, covering arrangement generation for numerous genres, audio analysis, effect processing, automation, MIDI transformation, and project management. No obvious gaps for a DAW MCP server.
Average 4.1/5 across 492 of 515 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 740 commits in the last 12 weeks
- Last stable release on July 12, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as whether this changes global tempo, requires engine running, or affects existing tempo automation. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence, which is concise but overly minimal for a mutative tool. Could include usage context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex DAW domain, many sibling tools, and no annotations, the description is extremely incomplete. No side effects, prerequisites, or usage context are mentioned.
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 coverage is 0%. Description does not explain the bpm parameter: no valid range, units assumed, or error handling. Parameter meaning is entirely left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 the action 'Set the project tempo' and specifies the unit BPM. It distinguishes from siblings like detect_bpm and set_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 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 set_tempo_change or detect_bpm. Agent must infer usage from name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does not mention effects on existing notes (truncation, stretching, etc.), constraints (min/max), or whether the operation is reversible. The schema type mismatch (integer vs float example) adds confusion.
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 very short, which is beneficial for readability, but it omits critical information about parameters and behavior. It is concise but at the expense of completeness.
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 simplicity of the tool (set duration) and the presence of an output schema, the agent might infer basic returns, but the description lacks details on region content handling, constraints, and error conditions. It is insufficient for safe and correct invocation without additional knowledge.
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 explain all parameters. It only explains duration_beats, and with an inconsistency (integer vs float example). The other three parameters (unit_index, track_index, region_index) are not explained at all, leaving the agent to guess their meaning.
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 the action (Set) and the target (duration of a region). The example clarifies the unit (beats). This distinguishes it from other set_region_* tools which target different properties.
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, no prerequisites mentioned, and no context about selecting the correct region or track. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action (mute/unmute) without any behavioral details such as effects on playback, undo support, or prerequisites. No annotations are provided to supplement this.
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 extremely concise (one sentence), which is efficient but lacks necessary detail for safe tool usage. It balances brevity and completeness poorly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, low schema coverage, and a minimal description, the tool is under-specified. Context like track identification and mute semantics are missing, making it hard for an agent to use correctly without prior knowledge.
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%, and the description does not explain the parameters. The boolean 'mute' and integer 'unit_index' are self-explanatory but the agent needs to know that unit_index refers to a track index and that true/false maps to mute/unmute.
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 mutes or unmutes an audio unit, aligning with the tool name that includes 'set_track_mute'. However, it uses 'audio unit' instead of 'track', causing slight ambiguity. Overall, verb and resource are clear.
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 set_track_solo, set_track_enabled, or set_clip_mute. The agent must infer context from the tool name and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not explain behavioral consequences such as whether other tracks become muted, how existing solo states are affected, or what the default state is. The boolean parameter implicitly indicates setting or unsetting solo, but no further 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 very concise—one sentence—with no wasted words. However, it could benefit from slight expansion to clarify key terms. It is not verbose, but brevity comes at the cost of completeness.
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 simplicity and the presence of an output schema (though not detailed here), the description should at least clarify what the unit_index represents and any side effects. It lacks essential context for an agent to use correctly, especially in a project with many tracks.
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%. The description adds no information about the parameters: 'unit_index' is not explained (e.g., what it refers to, what range is valid) and 'solo' is minimally described as a boolean. The tool fails to clarify the relationship between unit_index and tracks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Solo or unsolo an audio unit' clearly states the action (solo/unsolo) on a resource (audio unit). However, 'audio unit' is ambiguous; from the tool name it likely refers to a track, but it's not explicitly stated, and no differentiation from sibling tools like set_track_mute or set_solo_automation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when soloing is appropriate, how it interacts with other tools, or when to use set_solo_automation instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as whether it is destructive, real-time, or has side effects. Only the panning range is given.
Agents need to know what a tool does to the world before 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 sentences. Front-loaded with the action and range. No superfluous words.
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 schema and no annotations, the description is incomplete. It does not explain what unit_index refers to, nor does it mention output or behavior. The existing explanation of panning range is helpful but insufficient.
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%. The description explains the panning parameter range but does not describe the unit_index parameter at all, leaving its purpose 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 description clearly states the action 'set panning' and the resource 'audio unit'. It also explains the panning range. However, it does not differentiate from sibling tools like mcp_opendaw_set_stereo_tool_panning, which also sets panning. The mention of 'audio unit' might be slightly inconsistent with the tool name's 'track'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites, conditions, or when-not-to-use are provided. The description only explains the function and range.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only says 'Returns success or error.' It does not mention whether connections are overwritten, if multiple connections are allowed, or any side effects (e.g., cable routing conflicts). This is insufficient 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 concise: one sentence for the purpose, followed by a bullet list of parameters, and a note on return value. It is front-loaded and easy to scan, though the parameter list could be more structured (e.g., grouping source vs target).
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 complexity of modular devices (multiple modules, output/input connectors), the description lacks essential context: how to obtain module indices, what connector names are valid, and whether `list_modular_modules` should be called first. The presence of an output schema does not compensate for this missing context.
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?
With 0% schema coverage, the description must compensate. It lists parameters with one-line descriptions (e.g., 'Audio unit index', 'Effect index within the AU'), which add minimal context beyond the parameter names. It does not explain how to find valid module indices or connector names, nor does it provide example values 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 action: 'Connect two modules in a Modular device (create a patch cable).' This provides a specific verb ('connect') and resource ('modules in a Modular device'), and it distinguishes this tool from siblings like `add_modular_module` or `remove_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 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, prerequisites (e.g., modules must exist), or when not to use it (e.g., if a connection already exists). The description lacks any contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose behavioral traits such as whether the tool can be called during playback, what happens to the transport state, or if there are any side effects. It only states the action without 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 a single sentence with no filler, making it concise. However, it lacks structure or front-loading of critical information. For a one-sentence description, it is efficient but could be more informative.
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 simplicity, the description is minimal. It does not mention prerequisites (e.g., engine running), edge cases, or the format of the position value (e.g., integer beats from start). The output schema exists but is not visible; still, the description could be more 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 description coverage is 0%, so the description must compensate. It adds the unit 'beats' but does not clarify whether position is absolute from start, relative, or the expected range. The parameter 'position' remains underdescribed beyond its 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 verb 'Set' and the resource 'playback position' with the unit 'beats'. It distinguishes from siblings like 'transport' (which controls play/stop) and 'set_loop_region' (which sets loop points). 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 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. For example, it does not mention whether it should be used during playback or stopped state, nor does it compare to 'transport' or 'seek' tools. The description lacks 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.
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 discloses removal of cached audio and resumption of live processing, but lacks details on side effects, reversibility, permissions, or impact on other units.
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 action in the first sentence and elaboration in subsequent sentences. Every line adds 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?
Given the tool is a mutation with potential side effects, the description lacks completeness. It does not mention prerequisites (must be frozen), error handling, or behavior if already unfrozen. Output schema exists, but description minimally covers return values.
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 'unit_index' as 'AU index to unfreeze', adding minimal context beyond the schema title. No guidance on how to obtain the index or valid 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 uses a specific verb 'Unfreeze' and resource 'audio unit', clearly stating the action of resuming real-time processing. It is distinct from its sibling 'freeze_audiounit', providing clear 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 explicit guidance on when to use this tool versus alternatives. It implies it is the reverse of freeze_audiounit, but does not specify prerequisites (e.g., the unit must be frozen) 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.
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 mentions the return value but does not disclose error conditions, side effects, permissions, or constraints (e.g., duplicate labels, invalid types, coordinate conflicts).
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 brief and front-loaded with the action. It lists parameters in a clear, readable format. Slight improvement could be a bulleted list, but overall efficient and focused.
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?
Covers core purpose and parameters, mentions return value. Lacks context on what a Modular device is, how to obtain au_index/effect_index, or behavior under edge cases. Adequate for basic use but not fully 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?
With 0% schema description coverage, the description compensates well by explaining each parameter (au_index, effect_index, module_type, label, x, y) and providing the enum values for module_type. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a module to a Modular device, with specific parameters. It is unambiguous but does not explicitly differentiate from sibling add tools, though the modular context is 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 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 connect_modular_modules or remove_modular_module. The description only describes the action, not the context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects, but it only states the action. No mention of what happens to existing tracks, whether it is destructive, or any required 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?
Single sentence, 11 words, no redundancy. Perfectly concise.
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?
Despite no parameters, the description fails to explain the tool's context (e.g., what 'primary audio unit' is, what the output contains). Given an output schema exists, the return value explanation is not required, but other 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?
No parameters exist (empty schema). The description adds no value beyond the schema, but the baseline for zero-param tools 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 'Create a new audio track', distinguishing it from siblings like create_instrument_track. However, the phrase 'on the primary audio unit' is ambiguous without further context, slightly reducing clarity.
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 vs alternatives like create_instrument_track or create_audio_bus. No preconditions 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.
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 burden. It explains that notes are created on a track using GM percussion, and lists styles and instruments. However, it does not specify whether existing notes are overwritten or appended, nor any 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded in the first sentence, but the description is lengthy with cultural background, instrument mapping, and style details. While informative, some content could be trimmed for conciseness without losing essential guidance.
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 (7 parameters, no annotations, has output schema), the description lacks essential parameter explanations and does not mention the output schema. It provides cultural context but omits practical invocation details.
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 provides no explanation of the 7 parameters (bars, style, velocity, etc.). The style list in the description is not explicitly linked to the 'style' parameter. The agent gets no help understanding 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 description clearly states the tool creates a Cuban comparsa percussion pattern, explaining the cultural context and differentiating it from siblings like create_clave or create_songo_pattern. The verb 'create' and resource 'comparsa' are specific.
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 implicitly clear from the domain-specific purpose, but there is no explicit guidance on when to use this tool versus alternatives like create_clave or create_tumbao. No when-not conditions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It details the output musical content but fails to explain side effects (e.g., whether it creates new tracks, modifies existing project, or requirements). This leaves ambiguity about tool invocation consequences.
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 the core purpose but includes verbose musical details (exact track specifications, chord progression theory). While detailed, it could be more concise without losing essential guidance.
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 complexity (11 parameters, 0 required, no schema descriptions), the description is incomplete. It does not explain how parameters map to output, what the output schema contains, or whether the arrangement is additive or destructive. Agents lack sufficient context to use the tool effectively.
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 add parameter meaning. It only mentions defaults (128 BPM, F minor) but does not explain how other parameters (bars, octave, velocity, etc.) affect the arrangement. Agents cannot infer parameter impact without additional 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 it creates a full EDM festival/mainstage arrangement with specific elements (4-on-floor, supersaw, pluck, lead). The verb 'Create' and resource 'EDM arrangement' are precise, and it distinguishes from sibling genre-specific 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 usage for EDM arrangement creation but does not explicitly state when to use this tool versus alternatives (e.g., other genre arrangement tools). No exclusion criteria or when-not-to-use advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds musical context but fails to state whether existing track content is overwritten, if tracks must pre-exist, or other side effects. 'Locked together' is vague.
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?
Well-structured: purpose, track breakdown, parameter list, examples. Some musical elaboration could be trimmed for brevity, but generally efficient.
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?
Lacks critical preconditions (e.g., track existence), behavior on existing notes, and interaction with project state. Output description is brief but covered by output schema presence.
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 explains 7 of 10 parameters (bpm, bars, root, octave, unit_index, track indices) with defaults and ranges. Missing velocity and start_beat, but adds musical context for some params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 trap arrangement with drums, 808 bass, and bell melody across 3 tracks. It distinguishes this from siblings like create_afrobeat_arrangement by specifying genre and components.
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 on when to use this tool vs alternatives (e.g., other create_*_arrangement tools). The examples show usage but lack context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that the region retains its position/duration/content and source loses the region, and that it returns success or error. However, it omits side effects, error conditions, or project state changes beyond the move.
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?
Description is concise with 6 sentences, starting with a clear purpose statement followed by a parameter list. No redundant information; well-structured and 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?
Given that this is a mutation tool with no annotations, the description lacks prerequisites (e.g., region/track existence) and does not specify error handling or edge cases. Output schema exists but is minimal; description could provide more context for robust agent 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?
Schema coverage is 0%, so description compensates by listing all 5 parameters with brief context (e.g., 'Source track index within source unit'). However, explanations are minimal and lack constraints, ranges, or indexing details that would fully clarify parameter usage.
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 it moves a region between tracks, possibly across audio units, and specifies that the region keeps its properties and source loses the region. However, it does not explicitly distinguish itself from similar siblings like 'copy_region_to_track' or 'transfer_region', 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 explicit guidance on when to use this tool versus alternatives. While the action is implied to be for moving a region to a different track, there is no explanation of prerequisites, when not to use, or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description should disclose behavioral traits. It only states 'serialize' but does not mention whether this is a read-only operation, if it modifies state, or any permissions 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?
Extremely concise: two short sentences with no redundancy. Every word is necessary.
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?
With siblings like 'get_full_project_state' and 'get_project_state', the description should differentiate. It does not clarify the output structure or use cases, though output schema exists which partially compensates.
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?
No parameters exist, and schema coverage is 100%. The description adds no additional semantic meaning beyond what the schema provides, which is acceptable given the simplicity.
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 serializes the project state to JSON and returns data. However, it does not differentiate from similar tools like 'get_full_project_state' or 'get_project_state', which may also return 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 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 'get_full_project_state' or 'get_project_state'. The description lacks context for appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states that the tool sets enabled to true or false, but does not mention return values, side effects (e.g., if indices are invalid), or whether the operation is undoable. 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 concise with two short sentences plus parameter explanations. Every sentence adds value without redundancy. Front-loaded with the main purpose.
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?
Despite having 3 required parameters and no annotations or output schema described, the description does not cover how to obtain the indices (unit_index, effect_index) or what the return value is. It lacks completeness for an agent to use this tool without additional context from other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema by explaining each parameter: unit_index is 'Audio unit index', effect_index is 'Effect position in the chain', and enabled is 'true to enable, false to bypass'. This is valuable given that schema description coverage is 0%. However, value ranges or constraints are not specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Enable or bypass' and the resource 'specific effect on an audio unit'. It distinguishes from sibling tools like add_effect, remove_effect, and list_effects by specifying the exact action on an existing effect.
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 (e.g., set_effect_parameter, remove_effect). No prerequisites mentioned, such as requiring the unit and effect to exist. The description does not provide context for when bypassing is preferred over enabling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states 'rename' without any behavioral details such as whether the label is overwritten, if the tool is destructive, or what the output schema contains. No annotations are present to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions 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, with only a two-line purpose statement and a bullet list of parameters. No superfluous text.
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 and a hidden output schema, the description does not explain how to obtain indices (unit_index, track_index, region_index) or the overall project hierarchy. Missing context about what the tool returns.
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 provides brief explanations for each parameter (e.g., unit_index: search all AUs with -1). This adds meaning beyond the schema's bare titles, though not deeply detailed.
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 the verb 'rename' and the resource 'region label' clearly. However, it does not differentiate from sibling tools like set_region_color or set_region_mute, which are also about modifying region properties.
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 other region-modification tools. No prerequisites or context for selecting this tool are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'without deleting it' implying non-destructiveness, but lacks details on reversibility, side effects, or prerequisites (e.g., region must exist). The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences. The first states the purpose, the second documents the key parameter. No extraneous information, 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 boolean operation, the description is adequate. However, it omits parameter details for indices and does not reference the output schema. Given the presence of an output schema, the description could have been slightly more complete to fully guide the agent.
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 for the 'mute' parameter ('true to mute, false to unmute'), which is helpful given 0% schema coverage. However, it does not explain track_index, region_index, or unit_index, leaving gaps for the 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 clearly states the action: mute or unmute a specific region without deleting it. The tool name reinforces this purpose. However, it does not distinguish from sibling tools like set_clip_mute or set_track_mute.
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. The description only states what it does, without context on prerequisites, typical use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describes what tracks are created (drums, bass, lead, chords) and their musical patterns, but does not disclose potential side effects such as whether it overwrites existing tracks, requires specific instruments, or modifies the project in other ways. It provides moderate transparency but leaves 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 the core purpose ('Create a hardstyle arrangement — 150 BPM festival hard dance') and then provides concise yet detailed breakdowns of genre characteristics and track patterns. Every sentence provides useful context, though the structure could be slightly improved by separating parameter details from general 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?
Given the tool has 7 parameters with no required fields and no parameter descriptions, the description is incomplete. It does not explain how parameters like velocity or key_root influence the arrangement, nor does it provide behavioral context such as whether the tool requires a pre-existing project or will create tracks from scratch. The presence of an output schema helps but does not compensate for the lack of parameter semantics.
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%, meaning the schema provides no parameter descriptions. The tool description only mentions track_index in the context of track creation but fails to explain how other parameters (bpm, bars, key_root, velocity, start_beat, unit_index) affect the output. This is a critical gap that severely limits an agent's ability 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 the tool creates a hardstyle arrangement at 150 BPM, and lists 4 specific tracks with their musical patterns. Among the many create_*_arrangement siblings, this description effectively distinguishes the tool by genre and BPM, making it easy for an agent to select the correct genre arrangement tool.
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 genre creation by describing the genre and track structure, but it does not provide explicit guidance on when to use this tool versus other arrangement tools, nor does it mention any prerequisites or exclusions (e.g., whether existing tracks are cleared or if specific samples are required).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already marks destructiveHint=true. The description adds no behavioral context beyond parameter identification (e.g., side effects, reversibility, or whether the deletion is permanent).
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 short and to the point, with the main action stated first and parameters listed after. It is efficient but could be formatted as a structured list for better readability.
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 purpose and parameter meanings. However, it lacks information about return values (output schema is present but not described) and assumes familiarity with the DAW's indexing system.
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 parameter explanations are the sole source. They provide basic meaning (e.g., 'unit_index: Audio unit index') but assume system knowledge and do not link to other tools (e.g., list_audio_regions for 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 'Delete an audio region from the timeline' with a specific verb and resource, distinguishing it from sibling tools like delete_region (which may affect non-audio regions) and delete_note_region.
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 (e.g., delete_region or delete_clip). The description assumes the user knows to choose based on resource type, but does not explicitly state conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It states clips are scheduled to play but does not disclose whether playback is immediate, how scheduling works (e.g., at next bar), what happens to currently playing clips, or potential side effects. The tool's behavior remains vague.
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 very concise with two sentences, front-loading the core function. It avoids unnecessary details. A minor improvement could be structuring the parameter description more explicitly, but it is efficient for a simple 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?
For a tool with one parameter and a straightforward action, the description covers the basics: what it does and what input it expects. However, it lacks information about return values (output schema exists but is not referenced) and error conditions. It is minimally 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?
Schema coverage is 0%, so the description must add meaning. It specifies that clip_ids is a 'Comma-separated list of clip UUIDs to trigger', which clarifies format and purpose. However, it does not explain UUID format or error handling for invalid IDs, leaving some 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 ('schedule clips to play'), the resource ('clips'), and the context ('session view (live triggering)'). It distinguishes the tool from siblings like 'schedule_clip_stop' and 'set_clip_playback' by specifying live triggering in session view.
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 usage guidelines are provided. The description does not mention when to use this tool over alternatives, prerequisites (e.g., clips must exist), or contexts where it is inappropriate. This leaves the agent without guidance on proper invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states 'Returns success, or error' without elaborating side effects, reversibility, or permissions. The brief description is insufficient 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 concise with a one-line summary followed by a brief parameter list. Every sentence adds information; no redundancy. Well-structured for quick scanning.
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 simple rename operation with 4 parameters and an output schema, the description covers parameter semantics but lacks details on return value structure, error conditions, or prerequisites. Adequate but not thorough.
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%, but the description adds context for each parameter: unit_index as 'AU index', effect_index as 'Effect index in the chain', label as 'New label/name', and is_midi_effect clarifies targeting. This adds moderate 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 the verb 'Rename' and the resource 'effect or MIDI effect device'. It distinguishes from sibling tools like rename_unit and set_clip_label by specifying the target as an effect device.
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 on when to use this tool vs alternatives (e.g., rename_unit). The description implies usage by listing parameters but lacks 'when not to use' or 'see also' references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite lacking annotations, the description discloses the mapping function (powerByCenter), range (-96 to +6 dB), and the 0 dB mapping to 0.768. This adds some behavioral awareness, but does not address side effects, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each adding distinct information: action, mapping, range and 0 dB reference. No filler, but could be more concise by merging technical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return value details are covered. However, with no annotations, the description misses prerequisites (e.g., does the unit need to exist?) and behavioral constraints, leaving gaps 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?
With 0% schema coverage, the description should explain both parameters. It implicitly describes volume_db (dB value) but does not explicitly mention unit_index's role. The mapping details add context for volume_db but not enough for completely clear parameter use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set volume of an audio unit in dB') and provides technical details like range and mapping, but the term 'audio unit' slightly diverges from the tool name's 'track', and it doesn't explicitly distinguish from sibling set tools (e.g., set_track_mute).
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 vs alternatives like set_track_panning or set_track_mute. The description only provides internal implementation details (VolumeMapper), not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Control transport' and lists actions, but omits details like what 'toggle' does (e.g., toggle between play and stop), whether position is reset, or any side effects. This is insufficient for a transport control 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 sentences, front-loaded with the purpose, and lists the parameter values efficiently. 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?
Given the tool's simplicity and the presence of an output schema (not provided but indicated), the description is mostly complete for basic usage. However, it could mention that the action is immediate or provide feedback 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?
The schema has 0% description coverage (no enum, no description). The description adds the allowed values: 'play', 'stop', 'toggle', which partially compensates. However, it does not clarify case sensitivity or exact format. With only one parameter, more explicit guidance would be better.
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: 'Control transport: play, stop, or toggle.' It lists the three specific actions, making the function explicit. It does not explicitly distinguish from siblings but the action set is unique enough among the many tools.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternatives like start_engine or other transport-related tools. It only lists the action parameter values without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral context. It only states 'Undo the last editing operation' without disclosing scope (single vs. multiple undos), redo availability, or side effects. This is insufficient for an agent to understand the full 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 a single, concise sentence with no wasted words. It perfectly matches the tool's simple nature.
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 simplicity and the presence of an output schema, the description is still minimal. It fails to mention whether multiple undos are supported, how undo history is managed, or any return value context. This lack of detail hurts 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?
The input schema has 0 parameters with 100% coverage. The description adds no additional parameter meaning, but since there are none, a baseline score of 3 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 undoes the last editing operation. The verb 'undo' combined with 'last editing operation' is specific and distinguishes from sibling 'mcp_opendaw_redo'.
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 'redo' or other editing tools. The usage context is only implied (after an editing operation), but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description indicates returns (notes created, phrase structure) but does not disclose side effects like whether it overwrites existing notes or how track/unit parameters affect behavior. Moderate 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?
Description is front-loaded with purpose and well-organized into explanation, parameter definitions, and example. Slightly verbose with redundant genre listing but overall concise for the 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?
Covers the core usage and musical concept, but lacks guidance on valid scale values (14 types from music_theory not enumerated), exact note syntax for patterns, and integration context (track/unit defaults). Agent may need additional knowledge to use 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 compensates by explaining key parameters (scale, root, patterns, repeats, etc.) and providing examples. A few parameters like track_index and unit_index are omitted, but the main musical parameters are well-covered.
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 creates call-and-response patterns with antecedent/consequent phrase structure. However, it fails to distinguish from the sibling tool `mcp_opendaw_create_call_and_response`, which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like `create_melody` or the similarly named sibling. Lacks context on prerequisites or scenarios for optimal use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden. It explains the structural output and track layout (melody track, bass track) but does not explicitly state that MIDI notes will be generated on the specified tracks or disclose side effects like overwriting existing data.
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 numbered sections but is verbose, including extensive musical theory that may not be necessary for tool selection. It is front-loaded with the purpose, but the length reduces conciseness.
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 (9 parameters, no schema descriptions, no annotations), the description fails to cover key aspects like parameter defaults and behavior for parameters like start_beat, unit_index, and velocity. The output schema is missing, further reducing completeness.
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 lists scale_name options and implicitly explains track_index and track_index+1 for bass, but does not describe other parameters like key_root, velocity, exposition_bars, etc. Only partial parameter meaning is 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 clearly states the tool creates a sonata form structure with three sections (exposition, development, recapitulation). It uses specific verbs and resources, distinguishing it from other 'create_*' tools by providing detailed classical music form 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 explains the musical context of sonata form but does not explicitly state when to use this tool vs. other form tools (e.g., create_binary_form, create_ternary_form). Usage is implied but not compared or contrasted with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses structure (ABA), contrast types, and ornamentation behavior. It also notes that melody goes on track_index and bass on track_index+1. However, it does not mention side effects, overwriting behavior, or scope of changes (e.g., does it clear existing notes?). With no annotations, more detail is needed.
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 the core purpose but becomes lengthy with historical and educational detail. While informative, it could be more concise for an AI agent, as the extensive examples and explanations may distract from the key operational 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?
Given the tool's complexity (10 parameters), the description covers musical theory well but lacks practical details like placement (start_beat, unit_index) and velocity. It assumes an output schema exists but does not clarify return values. Gaps remain for a complete operational 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 description explains concepts like A and B bars, contrast types, and ornamentation, which map to some parameters. However, parameters like velocity, start_beat, and unit_index are not mentioned. With 0% schema coverage, the description partially compensates but leaves 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 first sentence clearly states the tool creates ternary form (ABA) with contrasting middle section. The verb 'create' plus resource 'ternary form' is specific, and the educational context distinguishes it from other form-creating siblings like binary or sonata form.
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 explains what ternary form is and provides genre examples, but it does not explicitly state when to use this tool versus alternatives (e.g., binary form, sonata form, rondo). No guidance on when not to use it or comparison with other form tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses that it uses offline rendering (faster, no engine), explains the method parameter's actual behavior, and mentions output includes path and metadata. However, it does not address potential side effects like file overwriting or project state 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 concise, with the main action and key details front-loaded. It could be more structured with per-parameter bullet points, but overall it is efficient without wasted 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?
With an output schema available, the description need not detail return values. It covers the main purpose, method behavior, and parameters. However, it lacks information on prerequisites (e.g., project must be loaded), error conditions, or asynchronous behavior. For a tool with many siblings, more context on when to use it would be beneficial.
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 well by explaining each parameter: filename (without .wav extension), sample_rate (default 48000), and method (always uses offline regardless of value). This adds meaning beyond the schema's types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders the full project mix to a WAV file, with specifics about using OfflineEngineRenderer and the method parameter's backward compatibility. However, it does not explicitly distinguish itself from render_full or other export tools like export_stems, which could cause 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?
No explicit guidance on when to use this tool over alternatives like render_full or export_stems. No prerequisites or scenarios mentioned. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds minimal behavioral insight beyond stating it returns events with specific fields. It does not describe any other 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.
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 unnecessary words. It efficiently conveys purpose and return structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 tool with an output schema, the description is mostly complete. However, it lacks differentiation from the similar sibling 'get_signature_events', which reduces contextual 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?
There are no parameters, so schema coverage is 100%. Per guidelines, zero parameters default to baseline 4. The description adds no parameter info, which is acceptable.
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 lists all time signature changes on the timeline's signature track and specifies return fields. However, it does not distinguish from the sibling tool 'mcp_opendaw_get_signature_events', which likely has a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_signature_events' or 'add_signature_change'. The description only states what it does without offering usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 usefully states that durations and velocities are preserved and that only positions are mirrored. It also notes the return value (count of notes reversed). However, it does not specify if the operation is destructive, reversible, or how it handles invalid inputs. Given the absence of annotations, this is adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise: four sentences plus a parameter list. The first sentence restates the name, but the following sentences add essential behavioral info. The structure is clear, with the parameter definitions separated. Could be slightly tighter by merging redundant statements, but overall well-organized.
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 three parameters and no annotations. The description explains the parameters' meanings and the return value. However, it does not address edge cases, error handling, or prerequisites (e.g., does the region need to contain notes?). The output schema exists but the description covers the return value. Overall, it is adequately complete for a tool of this simplicity but leaves some 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 0% description coverage (no descriptions in the schema itself), but the tool description provides meaningful explanations for all three parameters: unit_index, track_index, and region_index (with the special value -1 for all regions). This adds significant value beyond the raw schema, helping the agent understand the exact parameters and their roles.
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 reverses note order in a region ('Reverse the order of notes in a region — retrograde variation'). It specifies what is swapped (positions) and what is preserved (durations, velocities). While it does not explicitly differentiate from sibling tools like shuffle_notes or rotate_notes, the purpose 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but provides no guidance on when to use it versus alternatives. There is no mention of prerequisites, expected inputs, or scenarios where this tool is preferred over other note manipulation tools. The agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention whether scheduling a stop overrides existing schedules, whether clips must be already playing, or any side effects. The description is too minimal for an operation that involves scheduling.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with two sentences. It front-loads the purpose and follows with parameter documentation. No unnecessary words 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?
Given the tool is a scheduling action with a single parameter and an output schema, the description covers the basics but is incomplete. It lacks explanation of the scheduling behavior (e.g., timing, overlap) and does not help the agent understand when to prioritize it over related 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 schema has 0% description coverage, so the description must compensate. It explains 'track_ids' as a 'Comma-separated list of track UUIDs to stop clips on', which adds meaning beyond the type. However, it lacks details like how to obtain UUIDs or whether the list is validated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Schedule clips to stop on specified tracks (session view)'. It includes the verb 'schedule', the resource 'clips to stop', and the context 'session view'. This distinguishes it from its sibling 'mcp_opendaw_schedule_clip_play'.
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?
While the description indicates the basic use case (scheduling stops), it provides no guidance on when not to use this tool, such as for immediate stop, or alternatives like using transport controls. There are no exclusions or comparisons to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It discloses that the operation is a view-only global transpose (no audio effect) and returns old/new values. However, it omits details like scope (affects all tracks?), reversibility, prerequisites, or side effects. This is adequate but not thorough.
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 three sentences: purpose, parameter explanation, return value. It is front-loaded and efficient. Every sentence adds value, though it could be slightly more concise by combining the return info.
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 with one parameter and an existing output schema, this description covers the basics. However, it lacks context about the scope of the global setting (e.g., does it apply to the entire project or only the current track?), which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the parameter name and type with no description. The tool description adds the valid range (-48 to +48) and explains the purpose ('Number of semitones to transpose'). This significantly enhances understanding 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 clearly states the verb 'Set' and resource 'global transpose for the piano roll view', and adds a clarifying note ('does not affect audio playback'). However, it does not distinguish from similar sibling tools like transpose_notes or diatonic_transpose_notes, which would help an agent choose the correct 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?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't explain that this is a global view setting, contrasting with per-note transposition. The agent is left to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses that MIDI notes are created with GM percussion mapping and syllable text in the result. However, it does not specify whether notes overwrite or merge, track creation behavior, or limitations. Some gaps remain.
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 long (30+ lines) and includes extensive cultural context and tala details. While the first sentence clearly states the purpose, the following details could be more concise. The GM percussion mapping is useful, but some content may be extraneous for an AI agent.
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 7 parameters with no schema descriptions and no annotations, the description covers the concept and style options well but lacks explanation for most parameters and does not describe return value details (though output schema exists). It also does not clarify if notes are added to existing clips or overwrite. Completeness 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 7 parameters with 0% description coverage, so the description must provide meaning. It extensively explains the `style` parameter with 6 tala options and briefly mentions `track_index`. However, the other 5 parameters (cycles, velocity, tempo_bpm, start_beat, unit_index) receive no explanation, leaving significant gaps 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 tool creates Indian Carnatic konokol as MIDI, specifies the verb 'create', the resource 'konokol', and output format 'MIDI'. It distinguishes this tool from others by focusing on a specific rhythmic tradition, with extensive detail on tala structures.
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 that the tool creates konokol notes on a specified track and details the style options and GM mapping. However, it does not explicitly compare with alternatives like `mcp_opendaw_create_tala` or provide guidance on when to choose this over other rhythm creation tools. Usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only says 'Create a time-stretched audio clip' without disclosing side effects, permissions, or interactions with existing clips.
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 short paragraph followed by bullet points for parameters, but could be better structured with a separate purpose line.
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 parameters but lacks overall behavioral context (e.g., prerequisites like loaded audio, what happens on success). Output schema exists, so return values are not needed, but more creation context would help.
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 coverage, the description adds meaning for most parameters (e.g., sample_id source, playback_rate values, transient_mode options), though some like clip_index and track_index remain somewhat vague.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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' and the resource 'time-stretched audio clip' in 'session view', distinguishing it from sibling tools like create_pitch_stretched_clip and 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter explanations but no guidance on when to use this tool versus alternatives, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true. The description adds that it removes all content on the track (regions, clips, notes), which is helpful but does not mention reversibility, permissions, or other 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 extremely concise: one sentence for purpose, two lines for parameters, one line for return. Front-loaded with the core action. 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?
Given the simplicity of the tool (two integer params, destructive), the description covers the primary effect and parameter meanings. It omits discussion of error handling or undo capabilities, but an output schema exists for the return. Overall adequate for a straightforward deletion.
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 one-line explanations for each parameter ('Audio unit index', 'Track index within the unit'), adding basic meaning beyond schema titles. However, it lacks details on how to obtain these indices 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 clearly states 'Delete a track from an audio unit' and lists the side effects (removing regions, clips, notes). It distinguishes from siblings like delete_region and delete_audio_unit, but does not explicitly compare, so it's clear but not perfectly differentiated.
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 vs other deletion tools (e.g., delete_audio_unit, delete_region). No prerequisites or context for usage provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 parameter values are copied and that the tool works for both chain types. However, it does not describe side effects (e.g., whether the original is unaffected), where the duplicate is inserted, or behavior on invalid inputs. 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 concise and well-structured: a clear purpose sentence, a reference to the upstream issue, a note on chain support, a bullet-style parameter list, and a return value statement. No superfluous 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 explains the core action, parameters, and return value. However, it omits details on error handling (e.g., invalid indices), placement of the duplicate, and any effects on the original chain. Given the tool's simplicity and the presence of an output schema, it is mostly adequate but not fully comprehensive.
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 explains each parameter with context: unit_index is the AU index, effect_index is the position in the chain, and chain_type specifies audio or MIDI with default. This adds meaning beyond the schema's bare titles and defaults, though it could clarify indexing (0-based?) and 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 clearly states it duplicates a single effect within an AU's effect chain, copying parameter values. It references the Ctrl+D shortcut and mentions support for both audio and MIDI chains. However, it does not specify where the duplicate is placed (e.g., after the original), which slightly reduces clarity.
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 as the MCP equivalent of Ctrl+D for audio effects and states it works for both chain types. However, it provides no explicit guidance on when to avoid this tool in favor of siblings like clone_effect_chain or duplicate_audiounit, nor does it mention prerequisites or error conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses that it copies various note properties and can offset position/pitch, and returns new note data. However, it does not mention side effects, authorization needs, or error conditions (e.g., invalid note_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?
Description is concise and well-structured: purpose, copied properties, parameter explanations, return value. Each sentence adds value 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?
Given 6 parameters and an output schema, description covers all parameters and specifies return fields. It explains the core operation and offsets but lacks details on error handling or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning for all 6 parameters: explains unit/track/region coordinates, note index, and defaults for offsets. Provides units (PPQN, semitones) and context beyond 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?
Description clearly states the tool duplicates a note event within the same region with optional offsets. It lists copied properties, distinguishing from generic duplicate tools. However, it does not explicitly differentiate from sibling tools like 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 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 such as duplicate_notes or create_note. The description implies duplication within a region but does not state when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the data source (parsed from code comments) and what information is included (label, index, values, mapping type, 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?
Two sentences, front-loaded with purpose, and includes substantive detail about output fields; could be slightly optimized but is effective.
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?
With 0% parameter coverage and no usage guidance, the description is incomplete despite having an output schema; it fails to address the most critical gap (input parameter semantics).
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 any of the three input parameters (unit_index, device_type, device_index), leaving the agent without guidance on how to specify the target 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?
Description clearly states the verb 'list' and resource '@param declarations on a scriptable device', uniquely identifying the tool's purpose among many sibling list 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?
No explicit guidance on when to use this tool versus other parameter listing tools like list_effect_parameters or list_instrument_params; context is implicit from the title and description but could be improved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the basic operation. It does not disclose side effects, destructiveness, or what happens to the MIDI chain after removal.
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: one functional sentence and two lines listing parameters. It is front-loaded, though the parameter listing is slightly redundant with the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 required parameters, both explained, but lacks information about the return value (output schema exists but not shown), prerequisites, and the fact that it is a destructive operation. It would benefit from cross-referencing sibling tools for obtaining indices.
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 adds meaningful explanations: 'Audio unit index' and 'MIDI effect position to remove (0-based)', which clarify the integer parameters beyond the schema's minimal 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 'Remove', the resource 'MIDI effect', and the context 'from an audio unit's MIDI chain'. It differentiates itself from sibling tools like 'remove_effect' and 'add_midi_effect'.
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 (e.g., replace_effect or add_midi_effect), nor does it mention prerequisites like obtaining unit_index and effect_index.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states 'Returns success or error' but does not disclose side effects, validation behavior (e.g., what happens if bus_index is invalid), or whether the change is immediately applied. The hue range is specified, but overall transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three brief lines, front-loading the purpose and parameter definitions. There is no unnecessary text. However, it might be too minimal, missing some potentially helpful context for an AI agent.
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 the core action and return value. However, it lacks information about error handling, prerequisites (bus must exist), and whether the operation is undoable. With no annotations and a basic description, 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.
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 provides the only explanations: 'bus_index: Bus index' and 'hue: Color hue 0-360 (HSL).' While brief, it adds meaning beyond the schema's type-only definitions. However, it could be more precise (e.g., zero-based indexing, bus existence requirement).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Set the color (hue 0-360) of an audio bus.' This is a specific verb+resource pair and clearly distinguishes from sibling tools like set_clip_hue (which operates on clips) and set_region_color (which operates on regions).
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., set_clip_hue for clips). There is no mention of prerequisites (e.g., bus must exist) or contexts where this tool is inappropriate. The description only states the action without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the syntactic constraint (effect must be a Delay) and lists fraction options. No mention of side effects, reversibility, or impact on project state. This is insufficient for 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise. The first sentence states the purpose, followed by bullet-list parameter explanations. No redundant 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?
Output schema exists, so return values are not needed. The description covers purpose and parameter semantics adequately but lacks behavioral transparency and usage guidelines. For a tool with 3 parameters and constrained values, it is minimally complete but has 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 coverage is 0%, so description adds meaning. It explains fraction with allowed values, effect_index with the 'must be a Delay' constraint. unit_index is briefly described as 'AU index' but could be clearer. Overall, it compensates for missing schema 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?
Clearly states it sets synced delay time on a Delay effect using a musical fraction. The description specifies the resource (Delay effect) and action (set synced delay time). It distinguishes from other set_* tools by targeting a specific effect type, though it does not explicitly compare to siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage by requiring effect_index to be a Delay and listing allowed fraction values. However, no explicit guidance on when to use this versus alternatives (e.g., unsynced delay time setup), nor prerequisites like effect existence or state.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description gives no behavioral details beyond the action itself. It does not disclose whether the operation is destructive, requires specific permissions, or any 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 concise: a single sentence followed by bullet-point parameter definitions. No redundant information, though the bullet points somewhat repeat the schema. Still efficient 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 simple setter with 4 undocumented parameters, the description covers the basics and includes examples for the string_value. However, it lacks context about prerequisites (e.g., effect must exist) or any constraints. Output schema exists, so return values are not needed.
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 adds value by listing parameters and providing example values for 'string_value' (e.g., 'hardclip', 'tanh'). However, explanations for other parameters (unit_index, effect_index, parameter_name) are minimal, offering little 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 'Set a string parameter on an audio effect' and gives a concrete example (Waveshaper equation). The tool name also specifies 'string', distinguishing it from sibling tools like set_effect_parameter_int and set_effect_parameter_bool.
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 parameters but does not explicitly state when to use this tool versus alternatives (e.g., set_effect_parameter_int, set_effect_parameter_bool). No guidance on prerequisites or conditions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return value (old and new values) and the toggle nature, but with no annotations, it misses potential side effects or prerequisites. For a simple toggle, it 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?
Three concise sentences: purpose, parameter explanation, and return description. No redundancy, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle with one parameter and output schema present, the description is adequate but could mention the scope (e.g., selected track). Overall, meets minimum viability.
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?
Given 0% schema description coverage, the description adds meaningful explanation of the boolean parameter 'show', specifying its effect. This compensates well for the schema's lack of text.
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 toggles note labels in the piano roll, specifying the resource (note labels) and action. However, it does not explicitly distinguish from sibling tools like set_piano_keyboard, but the purpose is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to show vs hide labels or alternatives. The description lacks context for when to use this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 but fails to mention whether the tool is destructive, if it overwrites existing settings, or what happens on invalid input (e.g., effect index not pointing to a Revamp). It only lists parameters without 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 concise, with a clear first sentence followed by line-by-line parameter explanations. Each sentence serves a purpose, though the parameter details could potentially be integrated into the 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?
While parameter semantics are well-covered, the description lacks overall context such as what the tool returns (output schema exists but is not referenced), prerequisites (effect must be a Revamp), and behavior on success/failure. This is adequate but not fully complete given 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?
The description adds significant meaning to the schema parameters, including ranges (e.g., frequency 20-20000 Hz exponential, gain -24 to 24 dB) and conditional applicability (e.g., gain for shelves/bells only, q for bells and LPF). This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool configures a filter section on a Revamp (parametric EQ) effect, specifying the verb 'configure' and the resource 'filter section' on a specific effect type. This distinguishes it from other set_* tools that operate on different parameters or effects.
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 explicit guidance on when to use this tool versus alternatives like set_effect_parameter. It does not specify prerequisites (e.g., the effect must be a Revamp) or when not to use it, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It mentions returning old and new state, providing some return behavior context, but lacks details on side effects, permissions, or 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, with a clear one-line purpose, parameter explanations, and a return statement. No superfluous 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 basics but omits context about indexing scheme, prerequisites, or how it relates to other mute/enable tools. The output schema exists, so return detail is adequate but incomplete overall.
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 adds meaning by explaining each parameter (unit_index, track_index, enabled) in plain terms, compensating 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool enables or disables a track, using specific verb and resource. However, it claims equivalence to track mute, which could cause confusion given the sibling tool 'set_track_mute' exists.
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 'set_track_mute'. The sibling list contains both tools, but the description does not differentiate them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 indicates a mutation operation ('Set') but does not disclose side effects, permissions, or constraints beyond the effect type. The behavioral impact of changing the source is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the main action. However, it repeats parameter names as mere labels, which could be trimmed. Overall, it is efficient and reasonably structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists (not shown), so return values need not be explained. However, for a mutation tool, the description lacks context about expected outcome (e.g., immediate change) and fallback behavior. It is 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 adds meaning by explaining each parameter: unit_index as 'AU index', effect_index as effect index in chain (must be Vocoder), source with five explicit enum values. This goes 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 'Set the modulator source on a Vocoder effect', using a specific verb and resource. It distinguishes itself from sibling 'set_' tools by targeting 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not provide prerequisites (e.g., existence of a Vocoder effect) or when not to use it. The description only lists parameters without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It only states that the tool adds an effect and returns an index, omitting details about prerequisites (e.g., unit must exist), mutability, error handling, or side effects. 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 two sentences plus a bullet list of effect types. It is relatively concise but the list is lengthy (16 items). The structure is clear, with the main action first followed by parameter details and return value usage.
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 has 2 required parameters and an output (effect_index), the description covers the return value's purpose but does not specify the type or format of the index. It also lacks error conditions or prerequisites. With an output schema present (context says true), the description is adequate but not thorough.
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 0% documentation coverage (no descriptions for parameters). The description clarifies the effect_type parameter by listing valid values, but does not explain unit_index—its type, range, or how to obtain it. With all the burden on the description, this gap significantly reduces usefulness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 an audio effect to an audio unit's effect chain', using a specific verb and resource. It distinguishes from sibling 'add' tools by specifying the domain (audio effect) and includes a list of valid effect types from a related 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 explains that effect_type must be from mcp_opendaw_list_effects and provides a list. It also links the return value to a downstream tool (mcp_opendaw_set_effect_parameter), giving context for subsequent steps. However, it does not explicitly state when not to use this tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It details the three tracks created and their patterns, but lacks information on side effects, prerequisites (e.g., track index conflicts), or whether it overwrites existing content. Adequate but incomplete.
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?
Well-structured with a clear opening and breakdown, but includes lengthy historical background on acid house that, while informative, is not essential for tool usage. Could be more concise.
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?
While output schema exists, the description lacks parameter guidance and does not explain how inputs affect the generated arrangement. For a creation tool with 7 undocumented parameters, this is a significant 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%; the description does not explain any of the 7 parameters (bpm, bars, key_root, velocity, start_beat, unit_index, track_index). It only mentions default key A minor. This fails to add meaning beyond the schema, which is 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 creates an acid house arrangement, specifying the TB-303 bassline and 909 drums. It distinguishes from sibling genre arrangement tools by providing genre-specific characteristics and track details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 use for creating acid house arrangements with specific characteristics. It doesn't explicitly state when not to use it or compare to alternatives, but the genre focus makes selection natural among many genre-specific siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 details output structure (5 tracks) and musical style, but does not disclose side effects (e.g., where tracks are added, any overwrite behavior, or project state dependencies).
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-organized (action, genre context, track breakdown) but includes verbose historical and musical exposition that may not be necessary for tool invocation. Could be trimmed without losing core guidance.
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 7 parameters with 0% schema coverage and no annotations, the description should provide more actionable parameter guidance. It explains the genre and track roles well but lacks details on how to adjust parameters to customize the arrangement. Existence of output schema is noted but not described.
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%, yet the description only clarifies bpm (85 default) and key_root (D minor), and indirectly implies track_index from track descriptions. Parameters like velocity, start_beat, unit_index, and bars are not explained, leaving significant 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 a clear action verb and specific genre ('Create a downtempo/trip-hop arrangement — 85 BPM Bristol sound'), and the detailed characteristics and track list distinguish it from sibling genre tools like create_lofi_arrangement or create_ambient_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 implies usage through genre specification and musical characteristics, but does not explicitly state when not to use (e.g., against other genres) or name alternatives 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description adds some context (instruments, styles, return info) but fails to disclose key behavioral traits such as side effects, required permissions, or whether existing notes are modified.
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 with historical and educational content that, while informative, is not essential for an AI agent. The core purpose is front-loaded, but the lengthy instrument and style explanations could be more 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?
The description covers instruments, styles, and parameters thoroughly. With an output schema present, return values are explained. However, missing prerequisites (e.g., required track setup) and integration context reduce 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 coverage is 0%, but the description includes an 'Args' section with meaningful descriptions for all 11 parameters (e.g., 'bars: Pattern length (4-16, even)', 'style: Style name'). This compensates fully, adding value beyond type 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 clearly states the tool creates a 'New Orleans second line percussion ensemble' with specific instruments and styles. It distinguishes from sibling tools like mcp_opendaw_create_samba_pattern or create_boom_bap by focusing on a unique rhythmic tradition.
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 does not explicitly state when to use this tool versus alternatives. It implies usage for creating second line patterns, but lacks when-not guidance or comparisons to other creation tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'destructiveHint: true' already indicates mutation. The description adds that it deletes a single note and returns the remaining note count. It does not elaborate on side effects (e.g., note removed from region, impact on region structure) or error conditions. 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 extremely concise: one sentence for purpose followed by a bullet-like list of parameter explanations. It is front-loaded with the action and resource. No extraneous 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 complexity (4 parameters, destructive action) and the presence of an output schema, the description covers the purpose, parameter meanings, and return value (remaining note count). It lacks error handling details or behavioral edge cases, but overall is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are absent (0% coverage), but the tool description provides clear explanations for all four parameters: note_index (0-based, from list_notes), unit_index (-1 for all AUs), track_index (within AU), and region_index (0-based). This adds significant meaning beyond the bare schema types and 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 'Delete a single note from a region,' using a specific verb and resource. It distinguishes from sibling tools like 'delete_note_region' (which deletes an entire note region) by specifying it operates on a single note. However, it doesn't explicitly differentiate from all other delete tools, so it's 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 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 such as 'delete_note_region' or other delete tools. There is no mention of prerequisites, fallback tools, or context for usage. The description only explains parameters, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation destructiveHint=true already indicates destructive behavior. The description adds no further behavioral context (e.g., permanence, undo capability, side effects) beyond stating 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?
Extremely concise: one line for the action and one line per parameter. No unnecessary words 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 delete operation, the description covers the core functionality and parameter semantics. However, it omits any mention of return value or error handling, though an output schema exists (not shown).
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 critical parameter details missing from the schema: unit_index can be -1 to search all AUs, track_index is within the AU, region_index is 0-based. Since schema description coverage is 0%, this adds essential meaning.
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 'Delete a note region from the timeline', specifying the exact resource and action. It distinguishes from sibling tools like delete_audio_region and delete_note by using 'note region', but does not elaborate on what constitutes a note region.
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 such as delete_region, delete_note, or delete_audio_region. The agent must infer usage from the tool name alone, which is insufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states 'Remove an audio effect' without disclosing behavioral traits like destructive nature, undoability, or chain shuffling. The parameter descriptions add no 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?
Extremely concise: two sentences plus two parameter lines. Front-loaded with the main purpose. No unnecessary 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?
While the description tells what and how to remove, it lacks context about the effect chain behavior (e.g., effects shift), how to obtain indices (e.g., using list_effects), and differentiation from similar remove tools. The existing output schema may supplement return details, but the description is incomplete for a DAW removal 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 coverage is 0% (no parameter descriptions), but the description adds meaning by specifying that unit_index is 'Audio unit index' and effect_index is 'Effect position to remove (0-based)'. This clarifies indexing and scope beyond the basic integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Remove' and the resource 'audio effect from an audio unit's chain', which distinguishes it from sibling tools like remove_midi_effect (MIDI effects) and remove_audio_bus (buses). The verb and resource are specific.
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 such as remove_midi_effect or remove_audio_bus. No prerequisites or context provided beyond parameter explanations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description explains parameter range and typical values but does not disclose behavioral traits like whether change is global, involves any destructive action, or requires specific 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?
Two concise sentences, no redundant information. Parameter detail follows directly after action statement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 setter, the description covers action and parameter adequately. No output schema, but not necessary. Minor gap: does not specify scope (project-wide).
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% coverage; description adds significant value by explaining amount range (0.0-1.0) and giving typical values (light, moderate, strong triplet). Compensates for schema gaps.
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?
Clearly states set groove/shuffle amount for project. Verb and resource identified. Does not explicitly distinguish from sibling 'apply_swing' but implies project-level setting.
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 vs alternatives. No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Rename a timeline marker.' It lacks disclosure of behavioral traits such as whether the marker must exist, side effects, or success/failure feedback. This is insufficient for a 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 extremely concise with two sentences plus parameter explanations. Every sentence is meaningful, and the key action 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 an output schema (not shown), so return values are covered. However, the description is minimal and does not mention prerequisites or error conditions. It is adequate for a simple rename but lacks deeper 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%, but the description adds significant meaning: it specifies that marker_index is 0-based and derived from list_markers, and that label is new label text. This compensates for 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 'Rename a timeline marker.' which is a specific verb (rename) and resource (timeline marker), distinguishing it from sibling marker tools like add_marker, delete_marker, set_marker_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 on when to use this tool over alternatives. Siblings include add_marker, delete_marker, set_marker_position, but the description does not explain the context for renaming versus other marker operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral context. It only states the action ('set') and valid rate values, but omits side effects, permissions, error conditions, or what happens with invalid 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?
One sentence plus a bullet list; no waste. Front-loads the purpose and then details parameters concisely.
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?
Covers input parameters well but lacks output behavior, error handling, and side effects. With no annotations, more behavioral context would be needed for completeness. Output schema exists but is not provided.
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 coverage, description adds meaningful context: clarifies unit_index, effect_index (must be Tidal), and lists all valid rate strings. Supplements the bare schema effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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), resource (LFO rate on a Tidal effect), and method (using a musical fraction string). Distinct from siblings by specifying a particular 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 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, no prerequisites mentioned (e.g., effect must be Tidal, indices must exist), and no comparison to other setter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must fully convey behavioral traits. It discloses that the tool creates multiple internal boxes (AudioUnitBox, AudioBusBox, TrackBox) and wires them, and notes a specific failure scenario with pointer refer() and deferred pointer update resolution. This adds valuable context about side effects and constraints beyond a simple 'create' call.
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 starts with a clear summary sentence, which is good. However, it then includes a paragraph of internal implementation details that may not be essential for an agent's decision to invoke the tool. This adds length without significantly aiding selection or invocation, making it 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?
Given the presence of an output schema, return values are not needed. The description covers the internal pattern and a known failure case, providing implementation-level completeness. However, it lacks information about idempotency, maximum bus limits, or if the operation can be undone. For a creation tool, some additional context about side effects would improve 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?
With 0% schema description coverage, the description must add meaning. It states 'name: Bus label' which clarifies the purpose of the 'name' parameter beyond the schema's title. However, no additional constraints, format, or usage tips are provided; the explanation is 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 'Create a new audio bus (aux bus) with its own audio unit and track.' It uses a specific verb 'create' and a clear resource 'audio bus', distinguishing it from sibling creation tools like create_audio_track or create_send.
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 on when to use this tool versus alternatives. The description focuses on internal implementation details (e.g., AudioBusFactory pattern, pointer refer() failure) rather than usage context or conditions. It does not explain when creating an audio bus is appropriate or what prerequisites are needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully explain behavior. It details the creation of 4 tracks with specific musical patterns and parameter defaults. However, it fails to mention that the tool likely modifies existing tracks (via track index parameters) and may overwrite existing content. The description implies generative behavior but lacks explicit warnings about destructive actions.
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 summary sentence but contains a lengthy paragraph on future bass characteristics that is interesting but not essential for tool usage. Track descriptions are detailed but could be more compact. Examples are useful. Slightly verbose 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?
Given the complexity (11 parameters, genre-specific), the description covers the main aspects: genre characteristics, track roles, musical patterns, defaults, and examples. It does not describe the output schema or side effects (e.g., overwriting behavior), but for a creative arrangement tool 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.
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 compensates partially. It explains bpm, bars, root, and octave with ranges and defaults, and implicitly connects track parameters to the 4 tracks. However, parameters like velocity, start_beat, and unit_index are not explained. Examples help but coverage is ~45%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Create a full future bass arrangement — 4 tracks' with specific genre characteristics and track roles. The verb 'create' and resource 'future bass arrangement' are precise, and the description distinguishes this tool from the many other genre-specific 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for future bass arrangements but does not explicitly state when to use this tool vs alternatives (e.g., other create_*_arrangement tools). No when-not or alternative guidance is provided, though the genre context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 details the tracks created and their indices but does not explain side effects (e.g., whether existing tracks are overwritten, what happens if track indices clash, or if required instruments are loaded). Some behavioral aspects are implied but not 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 starts with a clear one-line summary, then provides genre characteristics and track details. It is fairly concise, though the genre paragraph is detailed and may be unnecessary for tool invocation. Overall well-structured and 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?
Given the complexity (7 parameters, 0% schema coverage), the description lacks parameter explanations and behavioral details. It covers the musical output but not how parameters affect it. An output schema exists but is not referenced, leaving the agent without knowledge of the return value.
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 should explain parameters. It only implicitly references track_index via track indices. The other 6 parameters (bpm, bars, key_root, velocity, start_beat, unit_index) are not explained. Defaults align with description (e.g., 130 BPM, G minor) but semantics are missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 UK garage arrangement' and specifies the 4 tracks created (drums, bass, chords, lead) with genre-specific details. It distinguishes from many sibling tools that create other genre arrangements (e.g., create_acid_arrangement, 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 tool name and description imply use when a UK garage arrangement is needed. The genre characteristics provide context. However, it does not explicitly state when not to use it or suggest alternatives among the many genre-specific arrangment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 explains the musical output per track and defaults but does not disclose side effects such as whether it overwrites existing tracks, idempotency, or what happens if tracks are already occupied. Missing safety-related 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 with a summary, detailed musical breakdown, parameter list, and examples. It is slightly verbose but effectively organized.
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 complexity (10 params, no annotations, many siblings), the description covers the musical intent and basic usage. However, it lacks guidance on edge cases (e.g., missing tracks, invalid unit_index) and does not fully detail the output format or how it integrates with existing project state.
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 describes most parameters (bpm, bars, root, octave, unit_index, track indices) with brief context, but velocity and start_beat are missing from the description. The output schema is referenced but not detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 house music arrangement with specific tracks (drums, bass, stabs). It distinguishes from sibling arrangement tools by being genre-specific and describing the musical pattern in 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 includes examples showing typical usage but does not explicitly advise when to use this tool over alternative genre-specific arrangements. It lacks 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.
Behavior2/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 mentions creation of an instrument AU, Tape device, and audio track, and connection to output AU, but does not discuss side effects (e.g., overwrite, duplication), preconditions, or permissions. The agent lacks information on whether this operation is safe or 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 four sentences, each serving a distinct purpose: action, necessity, connection details, parameter and return info. No redundant or irrelevant content; well-structured 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?
Given the tool's simplicity (1 parameter) and the existence of an output schema, the description covers the core purpose and return values (unit_index, track_index). However, it does not explain what happens if the name conflicts or whether the Tape device is mandatory, leaving minor gaps in 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?
The input schema has 1 parameter (name) with 0% description coverage. The description adds the default value 'Tape' and clarifies it is a display name, which compensates partially. However, it does not explain constraints like uniqueness or allowed length, limiting full semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 new instrument audio unit with a Tape device and an audio track, specifying the verb (create) and resource. It distinguishes from siblings like create_audio_track (which lacks the instrument AU) by mentioning the Tape device and connection to output AU.
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 audio playback ('required for audio playback'), but does not explicitly state when to use or not use this tool, nor does it compare to alternative creation tools (e.g., create_audio_track, create_synth_track). Usage context is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 mentions return values but omits critical details like overwrite behavior for existing clip at the same slot, whether the track must pre-exist, error handling for invalid indices, and any side effects (e.g., triggering playback). This leaves significant gaps for the agent.
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 concise, using two paragraphs: one for conceptual overview and one for parameter listing. It avoids unnecessary detail but could be more structured (e.g., bullet points). Every sentence 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?
Given 5 parameters and no annotations, the description covers basic parameter meanings and return value but lacks behavioral context (overwrite/error handling, prerequisites). Output schema exists but is not detailed here; the description mentions return value briefly, which is adequate but not comprehensive.
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 effectively explains all 5 parameters with ranges and meanings (e.g., unit_index=-1 searches all AUs, clip_index slot indices, hue auto color). However, it does not address ambiguity when unit_index=-1 and multiple AUs have note tracks, or the relationship between unit_index and track_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 it creates a note clip in the session view (clip launcher), distinguishes it from note regions (arrangement view counterpart), and explains its purpose as containing NoteEventCollection for independent triggering. This differentiates it from sibling tools like create_note 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for session view clip launcher but lacks explicit guidance on when to use this tool versus alternatives like create_note_track or create_audio_clip. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool creates a multi-instrument pattern, describing each instrument's role and output. It states it returns notes and instrument breakdown. It does not disclose whether it overwrites existing notes or appends, but the creation aspect is clear. The description provides good insight into the tool's behavior without contradiction.
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 is overly verbose, devoting large paragraphs to educational content about samba instruments and styles. While informative, this is not structured for efficient agent use. The 'Args' list is redundant with the input schema and adds no new information. Front-loading is present but the bulk of the text could be trimmed significantly.
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 complexity (11 parameters, multi-instrument output), the description lacks explanations for critical positional parameters (unit_index, track_index, start_beat). It vaguely describes output as 'notes created, instrument breakdown, and pattern info' without details. The educational content is thorough but does not cover operational aspects needed for correct invocation. The output schema exists but is not referenced to clarify return structure.
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 description must compensate. It adds meaning for instrument pitches (e.g., surdo_pitch: 'Surdo (bass drum) MIDI pitch (36 = C1)') and style/bars/velocity. However, it fails to explain critical parameters like unit_index, track_index, and start_beat, which are essential for note placement. The 'Args' section merely repeats names without description. Overall, the description adds meaning for only a subset of 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 it creates a Brazilian samba percussion ensemble pattern, distinguishing it from the sibling songo pattern and explicitly contrasting it as a multi-instrument layered groove. The verb 'create' plus resource 'samba pattern' 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 explicitly contrasts samba with songo (single drum-kit pattern), guiding the agent to choose this tool over create_songo_pattern. It also details four distinct styles with characteristics, implying when each is appropriate. However, it does not explicitly state when not to use it or mention prerequisites like required tracks or instrument configurations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes note creation, alternation rate, accent options, and return value, but does not mention side effects (e.g., overwriting existing notes) or prerequisites (e.g., required track setup).
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 moderately concise with a front-loaded purpose, but the parameter list at the end duplicates schema info. Some sentences on genre context are helpful but could be condensed.
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 10 parameters, no annotations, no schema descriptions, and an output schema present, the description covers the concept and most parameter functions. However, it lacks detailed parameter semantics and behavioral transparency, leaving 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?
With 0% schema description coverage, the description must compensate. It lists parameters and defaults but adds little explanation beyond the schema. For example, 'rate' values are listed without explanation of triplet interpretations, and no examples or constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a trill, defines it as rapid alternation between two notes, and provides genre-specific context (classical, jazz, metal, electronic). This distinguishes it from sibling ornament tools like create_mordent or create_turn.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 trills across multiple genres) but does not explicitly state when not to use it or compare with alternatives. The genre mentions help guide appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. However, it only describes the musical concept and parameter effects, omitting behavioral traits such as whether it overwrites existing notes, requires any specific state, or has side effects. The return is mentioned but not detailed. This is insufficient for an agent to understand the tool's operational 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 organized with an introductory definition, musical examples, and a clear parameter list. Each sentence adds value, though the musical examples ('Think Mozart piano concertos...') are slightly verbose. Overall, it is front-loaded with the core concept and well-structured, but could be trimmed without losing essence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 schema descriptions are 0% and an output schema exists (so return details are covered), the description adequately explains the turn ornament and all parameters. However, it does not address error conditions or invalid inputs (e.g., invalid unit_index) which limits completeness for an agent making robust calls. Still, it covers the core creation context well.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, yet the description explains every parameter in detail: main_pitch (default 60=C4), direction (upper/lower), interval (semitones, default 2), duration_beats (range and default), velocity (0-1 default), unit_index, track_index, start_beat. This adds significant meaning beyond the plain schema properties, fully compensating 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 defines 'turn' as a musical ornament with a specific pattern (main→neighbor→main→other neighbor→main) and distinguishes between upper and lower turns. It uses specific verbs ('create a turn') and explicitly names the resource (turn). Even without explicit sibling differentiation, the detailed explanation 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives like create_mordent or create_trill. It explains what a turn is but offers no exclusions or criteria for selection. This lack of usage context makes it harder for an agent to decide between similar ornament tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions creating a ValueClipBox with an empty ValueEventCollectionBox and references ProjectApi.createValueClip, which gives some insight into the internal operation. However, it does not disclose side effects, state changes, or whether the operation is reversible. The description is moderately transparent but lacks depth.
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 statement, followed by a brief note on the underlying API and a parameter list. Every sentence adds value; there is no extraneous information. It is moderately sized and well-structured for an AI agent to parse.
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 output schema exists (though not shown), the description does not need to detail return values beyond 'Returns clip creation details.' It covers the essential scope (creation on automation track) and parameter roles. However, it lacks information on prerequisites (e.g., track must exist) and potential errors (e.g., invalid clip_index). The context is adequate but not exhaustive.
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 each parameter beyond the input schema: unit_index as 'Audio unit index', track_index as 'Automation track index (-1 = first automation track on the unit)', name as 'Clip label', and clip_index as 'Clip slot index (0-based)'. Since the schema has 0% coverage (no descriptions), the description effectively compensates and provides meaningful 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 'Create a value clip (automation clip) on an automation track in session view.' It specifies the action (create), resource (value clip on automation track), and context (session view). Among many 'create_*' siblings, this tool is distinctly targeted at automation tracks, leaving 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 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 like mcp_opendaw_create_automation_event or mcp_opendaw_add_automation. It does not specify prerequisites or contraindications, leaving the agent to infer usage context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It explains the shift calculation (max(position+duration) - min(position)) and what is returned (count and shift). However, it does not disclose side effects, error conditions, or authentication needs. Moderately transparent 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, with three short paragraphs: first defines the action, second explains the shift logic and DAW mirroring, third lists parameters. No redundant sentences. Well-structured 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 presence of an output schema (context signals indicate has output schema: true), the description's note on return values ('count of duplicated notes and shift in beats') is sufficient. For a three-parameter mutation tool, it covers the core behavior and expected output, though it could mention prerequisites like region existence or limits.
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% description coverage, so the description compensates by explaining each parameter: unit_index (including -1 special value), track_index, and region_index. This adds meaning beyond the schema titles. However, the descriptions are brief and do not specify constraints or valid 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 clearly states the action ('Duplicate all notes within a region') and the resource ('notes within a region'), with the specific behavior of shifting them after the last note. It distinguishes itself from sibling duplicate tools by specifying it operates on notes in a region.
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 mentions it mirrors the DAW's 'duplicate notes' feature and lists parameters, but it does not provide explicit guidance on when to use this tool versus alternatives like mcp_opendaw_copy_notes_to_track or mcp_opendaw_duplicate_note_region. No when-to-use or when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark this as read-only. The description adds that it returns play mode details or info for plain playback, which provides some behavioral context beyond the annotation. However, it lacks details on potential error conditions or index conventions.
Agents need to know what a tool does to the world before calling it. Descriptions 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 parameter annotations—no filler, front-loaded with the main purpose. Every word 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 existence of an output schema, the description sufficiently covers the tool's function: it identifies the resource, explains parameters, and notes the fallback case. Minor missing detail: index starting point (0 or 1) is not stated.
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 provides basic parameter explanations (unit_index: AU index, etc.), adding meaning beyond bare property names. However, this is minimal and could be more detailed (e.g., index ranges or 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 retrieves the play mode of an audio region, listing specific attributes (stretch type, playback rate, cents, transient mode). This verb+resource pattern distinguishes it from sibling tools like 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 on when to use this tool versus alternatives (e.g., get_region_info or other region-related tools). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, yet description does not disclose behavioral traits like whether the current session is overwritten, error handling, or file size limits. Minimal transparency beyond the import 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?
Two paragraphs plus Args; purpose is front-loaded. Some extra detail on file format could be trimmed but overall efficient and clear.
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?
Mentions return of track/sample counts (output schema exists), but lacks information on side effects on the session, error conditions, or success criteria. Adequate for a 1-param tool but could be more thorough.
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 coverage, the description adds 'Path to the .dawproject file to import,' providing context beyond the raw schema's type and title. Clearly defines the parameter's 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?
Description clearly states 'Import a .dawproject file into the current session,' specifies the file format and compatible DAWs, and distinguishes from related tools like export_dawproject and import_midi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when needing to load a dawproject file but lacks explicit guidance on when to use this vs. other import tools (e.g., import_midi). No prerequisites or constraints provided beyond 'current session.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description confirms listing behavior and adds context about returned fields. No additional behavioral traits (e.g., performance, error handling) are disclosed, but the read-only nature 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and well-structured: a brief purpose statement, followed by parameter descriptions, then return fields. It is front-loaded and uses clear formatting.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 input schema (2 params) and existence of an output schema, the description covers key aspects: what the tool does, what parameters mean, and what fields are returned. It lacks detail on edge cases or order, but is adequate for typical 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 has 0% description coverage, so the description compensates by explaining both parameters, including the special value -1 for track_index. This adds meaningful context beyond the schema's type 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?
Description clearly states the tool lists audio regions with specific fields. It explains parameters and return values, making the purpose evident. However, it does not explicitly differentiate from sibling list tools like list_clips 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains parameters and the special meaning of track_index=-1 for all tracks. It implies usage for querying audio regions but does not provide when-to-use or when-not-to-use guidance relative to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral detail beyond the readOnlyHint annotation by explaining that file pointers are null until a sample is loaded. This helps the agent understand the state of returned data, which is consistent with the read-only nature declared in 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 concise with two short paragraphs, front-loads the main purpose, and includes no unnecessary words. Every sentence adds value, explaining the function and the structure of returned slots.
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 presence of an output schema and annotations, the description covers output structure but fails to explain input parameters. It is complete for the output but leaves input semantics ambiguous, which is a moderate gap for a tool with three required parameters.
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%, placing the burden on the description to explain parameters. However, the description does not explain what device_type, unit_index, or device_index represent or how they identify the scriptable device, leaving the agent to guess their 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 it lists @sample declaration slots on a scriptable device, specifying the verb 'List' and the resource 'sample declaration slots'. It further describes the structure of each slot (WerkstattSampleBox with label, index, file), distinguishing it from other list tools by focusing on script samples.
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 does not provide explicit guidance on when to use this tool versus alternatives. It implies usage for listing script samples but lacks information about when not to use it or comparisons to sibling tools like list_samples or list_playfield_samples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already set readOnlyHint=true, so the description reinforces it by describing a read-only list operation. It adds context that the tool searches all Value-type tracks and returns region details. No contradictions; behavior is transparent and consistent 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 fairly concise with two short paragraphs: first explains the tool's action and output, second details parameters. Every sentence adds value, but the explanation of parameters could be integrated into a single structured format. 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 output schema exists (as indicated by context), the description does not need to detail return values. Parameters are well-documented, and the tool's scope is clear. Complete enough for an agent to use correctly, though adding a note about the output schema structure would enhance 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?
Schema description coverage is 0%, so the description carries the full burden. Both parameters are explained with their meaning and sentinel values (-1 for all). This adds significant meaning beyond the raw schema, though could be slightly more detailed (e.g., data types implied but not stated).
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 lists automation regions on value/automation tracks, specifying the returned fields (position, duration, loop settings, mute, label). It differentiates itself by focusing on 'ValueRegionBox' and 'value/automation tracks', though it could be more explicit about how it differs from similar list tools like list_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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies usage when you need to list automation regions, but given many sibling list tools, the agent needs clearer decision criteria (e.g., 'Use this instead of list_automation_events when you need region-level data'). Missing when-not-to-use 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.
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 only states the basic removal action without disclosing side effects, authorization needs, or error conditions. For a destructive tool, more context is needed.
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 short and to the point, with two lines separating purpose and parameter explanations. It is efficient but could benefit from a more structured format.
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 basic purpose and parameters, but lacks information on error conditions, return values (though output schema exists), and how to use it in conjunction with list_sends. More completeness would be expected for a removal 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 description coverage is 0%, so the description adds value by explaining both parameters: 'unit_index: Source audio unit index' and 'send_index: Send index to remove (from list_sends)'. The note about list_sends is particularly helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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' and the resource 'aux send from an audio unit'. It distinguishes from sibling tools like 'create_send' and 'list_sends' by specifying the removal 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 hints at a prerequisite by stating 'send_index: Send index to remove (from list_sends)', implying one should use list_sends first, but does not explicitly provide when to use this tool vs alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it sets the label and returns old/new label, but with no annotations, it fails to disclose whether changes are destructive, if there are length limits, or any side effects. 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 concise and front-loaded with the purpose. It lists parameters in a clear, scannable format without unnecessary 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?
The tool is simple with 4 required parameters and an output schema. The description covers the return value (old/new label). It is sufficient for basic usage, though it could mention potential constraints or failure modes.
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 coverage, the description explains each parameter's meaning ('AU index', 'Track index within the AU', etc.), providing essential context beyond the raw schema. This compensates well 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 verb (Set), resource (label of a clip), and context (session view). It distinguishes from sibling tools like set_clip_hue or set_clip_mute by specifying the exact attribute being modified.
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 set_clip_properties or other clip mutation tools. There is no mention of prerequisites, exclusions, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states it sets a parameter and returns success or error, without disclosing side effects, reversibility, or validation behavior. For a mutation tool with zero annotations, more behavioral disclosure is needed.
Agents need to know what a tool does to the world before calling it. Descriptions 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 each parameter listed on its own line for easy scanning. Every sentence adds value; no wasted 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?
While parameters are well explained, the description lacks context on how to obtain the indices (e.g., using list_modular_devices, list_modular_modules) and does not cover error handling or prerequisites. It is adequate for a simple operation but incomplete given the nested 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%, but the description explains all five parameters in detail, including the meaning of au_index, effect_index, module_index, param_name with examples, and value units. This 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 the action ('Set a parameter') and the resource ('module in a Modular device'). It distinguishes from sibling tools like set_effect_parameter by specifying 'modular module', which helps differentiate.
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 vs alternatives, such as set_effect_parameter or set_modular_module. It does not mention prerequisites like having a modular device or obtaining indices via list_modular_devices/list_modular_modules.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states the basic operation (enable/disable) without disclosing side effects, whether changes are immediate, or if it affects playback. The description is too 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 very concise: a single sentence plus parameter definitions. It front-loads the main purpose and presents parameters clearly. Every sentence adds 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 simplicity (3 required parameters, no enums, has output schema), the description is sufficiently complete. It covers the core operation and parameter roles. However, missing output schema details prevent full completeness, but the output schema likely handles that.
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 explains each parameter: sample_index (0-based pad index), enabled (boolean), and unit_index (integer, -1 for auto-detect). This adds meaning beyond the schema's titles, though it lacks details like value ranges or behavior of unit_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 action (Enable/disable) and resource (drum pad on Playfield drum machine). It also briefly explains the parameters, making the purpose unambiguous. The name aligns with the description and distinguishes it from other set_* tools.
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 copy_playfield_sample or list_playfield_samples. The description lacks context for selection, such as prerequisites or when to prefer one tool over another.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains parameters but does not disclose side effects (e.g., overwriting previous position, potential conflicts with other regions), required permissions, or if the operation is undoable. The term 'move' implies mutation but lacks detail on what changes occur beyond position.
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?
Concise two-paragraph structure: purpose sentence followed by parameter explanations. Each parameter gets its own line with clear formatting. Could be slightly more terse, but overall 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?
Covers all parameters and action. Output schema exists (not shown) so return values are not needed. Does not mention how to locate the region (e.g., needing prior list calls), but for a move operation this is acceptable. Minor gap: no explanation of what happens if the target position is occupied.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 clear, actionable semantics for all 5 parameters: explains units for position_beats (e.g., '4.0 = start of bar 2'), enum values for region_type, and the meaning of unit_index (-1 = search all AUs). This adds significant value beyond the raw 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?
Clearly states the action 'Move a region to a new position on the timeline.' The verb 'move' and resource 'region' are explicit, and the description distinguishes this from sibling tools like 'move_region_to_track' or 'set_region_duration' by focusing on timeline positioning.
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 'move_region_to_track' or 'set_region_duration'. Does not mention prerequisites (e.g., region must exist) or context (e.g., undo behavior). This lack of usage direction makes it harder 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear behavioral disclosure. It states the mutation action but does not mention side effects, error conditions, or required permissions. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: one for purpose, then each parameter on its own line. Front-loaded and no redundant 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 an output schema exists, return values need not be described. For a simple setter, the description covers core operation. Could add error handling notes but not essential.
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 adds semantic context by listing parameters with brief explanations (e.g., 'src_unit: Source audio unit index'). However, lacks details like valid ranges 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?
Description clearly states 'Set the send level for an existing aux send', specifying the verb (Set) and resource (send level). It distinguishes from sibling tools like create_send, list_sends, and set_send_pan.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use after send creation (references 'existing aux send' and 'send_index from create_send return'), but lacks explicit when/when-not guidance or alternative tool suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet the description does not disclose behavioral traits such as whether the operation is destructive, requires existing sends, or returns a result. The tool has an output schema, but its content is not mentioned. This is insufficient 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 concise: one sentence for the action followed by a bullet list for parameters. It is front-loaded with the primary purpose and wastes no words.
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 lacks information about prerequisites (e.g., send must exist), potential side effects, and the return value (despite an output schema). Compared to sibling tools like set_send_level, it does not provide enough context for safe and correct 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?
Each parameter is described in plain language: unit_index as source AU index, send_index as index on source AU, and pan with allowed range. This adds meaning beyond the schema's type-only information, though it could specify zero-based indexing and error conditions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 the action ('Set the stereo pan for an aux send') and provides the range of the pan value. It distinguishes itself from sibling tools like set_send_level and set_send_routing by specifying 'pan' and 'stereo pan'.
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 on when to use this tool versus alternatives. While the purpose is clear, there are no when-to-use or when-not-to-use instructions, leaving the agent to infer from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It explains that this sets a transfer function (a mutation) and enumerates equation options with brief descriptions. However, it does not disclose side effects (e.g., whether it replaces the current equation), error conditions (e.g., invalid effect_index), or permission requirements. More transparency is needed.
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 brief first line summarizing purpose, followed by parameter listings and equation details. It is reasonably concise, with each sentence adding value. Minor redundancy (e.g., repeating equation in list) could be trimmed, but overall 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?
Given that an output schema exists, return values are not needed. The description covers the core functionality and parameters but lacks prerequisites (e.g., need a Waveshaper effect added first) and error handling. For a mutation tool among many siblings, additional contextual guidance would improve 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?
Schema description coverage is 0%, so the description must compensate. It provides meaningful explanations for all three parameters: unit_index (AU index), effect_index (must be a Waveshaper), and equation (lists all valid values with descriptions). This adds significant value beyond the raw schema, though it could elaborate on constraints like valid 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 clearly states 'Set the transfer function equation on a Waveshaper effect' with a specific verb and resource. It distinguishes itself from sibling 'set_' tools by explicitly targeting a Waveshaper effect, which is unique among the many set tools listed.
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 requiring effect_index to be a Waveshaper but does not explicitly state when to use this tool versus alternatives. It lacks exclusion criteria or context about prerequisite steps (e.g., adding a Waveshaper first). The equation options are listed but without guidance on selecting based on desired sonic outcome.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the tool creates an automation track, value clip, and value events, and specifies that the parameter must be automatable. However, with no annotations, it misses details on error handling, side effects like overwriting existing automation, and the return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions 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. It efficiently covers the key information in a few sentences without unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (4 required params, no nested objects, output schema exists), the description covers the core functionality and parameter semantics. However, it lacks information on error conditions, prerequisites, and what the output schema returns, making it only partially 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, and the description compensates by explaining each parameter: unit_index, effect_index, parameter_name with examples, and points with format and example. The descriptions are clear and add 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 description clearly states the tool adds parameter automation to an effect on an audio unit, with specific verbs and resources. It distinguishes from sibling tools like add_instrument_automation by specifying '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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites like checking automatable fields with list_automatable_fields, nor does it indicate when to use add_instrument_automation instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It states what is copied and that it returns copied values, but does not address whether it overwrites existing fades, is destructive, or handles errors (e.g., missing Fading object). It provides basic transparency but leaves 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 concise: one line for purpose, one for what is copied, one for parameter grouping, and one for return value. It is front-loaded with the key action and has no redundant sentences.
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 6 parameters, no schema descriptions, no annotations, and an output schema, the description covers parameters briefly and mentions return value. However, it lacks details about preconditions, behavior when source/destination are same or invalid, and whether fades are replaced or merged. It is adequate but not thorough.
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 groups source and destination parameters as 'coordinates' and names specific fields (src_unit, etc.), adding some meaning beyond the schema. However, it does not explain what unit, track, or region indices represent (e.g., integer IDs), leaving interpretation open.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 copies fade in/out settings between audio regions, listing the specific properties (fadeIn, fadeOut, fadeInSlope, fadeOutSlope). It distinguishes itself from sibling tools like set_audio_region_fade (which sets fades) and copy_region_to_track (which copies entire regions), making its purpose highly specific.
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 copying fade settings but does not explicitly state when to use this tool versus alternatives like set_audio_region_fade or copy_region_to_track. It lacks guidance on prerequisites (e.g., regions must exist) or when not to use it, though the purpose is clear enough for an agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 the generated arrangement structure and mentions return values ('Returns notes created per track and total'), but does not clarify side effects like overwriting existing data, prerequisites (e.g., existing tracks), or system interactions beyond note creation.
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 lengthy but well-structured, starting with a concise purpose then detailing tracks and parameters. Some redundancy exists (e.g., repeating tempo adjustments), and the level of detail may be excessive for a simple creation tool, but it remains organized.
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 11-parameter complexity and no annotations, the description covers the musical output thoroughly—track roles, progression, tempo suggestions. However, it omits system-level context (e.g., whether it creates new tracks or modifies existing ones) and does not leverage the existing output schema to explain 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%, so the description carries the full burden. It explains most parameters (bpm, bars, root, octave, track indices) with specific details like range and defaults. However, velocity, start_beat, and unit_index are not explicitly described, leaving some 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 tool's purpose: 'Create a full country arrangement — boom-chick guitar + root-five bass + major pentatonic fiddle lead.' It specifies the genre and instrumentation, effectively distinguishing it from sibling genre-specific arrangement tools like create_rock_arrangement and create_blues_arrangement.
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 through genre details but does not explicitly state when to use this tool over alternatives or provide when-not-to-use guidance. It assumes the agent will infer from the genre focus, but lacks explicit usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 dembow pattern and parameter effects but does not disclose side effects like overwriting existing notes, requiring a track index, or potential destructive behavior. The return value is mentioned but not where the notes are placed.
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 includes a lengthy historical background and cultural references that, while educational, are not essential for tool usage. The parameter listing is well-structured with bullet points, but the overall length could be trimmed. Every sentence does not directly earn its place for an AI agent.
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 8 parameters and no annotations, the description covers the most important aspects but misses key details like where the notes are placed (e.g., track_index is required but not explained), and whether the tool replaces existing content. The output schema is indicated but not described.
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 detailed explanations for dembow_type with 5 variants, and explains bars, kick_pitch, snare_pitch, and velocity with real-world context. However, start_beat, unit_index, and track_index are not documented, leaving some 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 clearly states it creates a dembow rhythm, the foundational beat of reggaeton and Latin dancehall. It explains the pattern origin and structure, and the specific verb 'Create' plus resource 'dembow rhythm' is distinct from sibling tools like create_clave 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 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. It describes the tool's purpose and parameters but lacks guidance on context, prerequisites, or exclusions. The agent must infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It explains the creation of four layers but omits whether it overwrites existing notes, requires specific track types, or has side effects. Details like 'returns notes created' hint at behavior but are insufficient for a mutation tool with zero 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with headers and bullet points, but the educational introduction about Flamenco, while valuable, adds length. Each section serves a purpose, but some redundancy could be trimmed without losing 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 10 parameters, no annotations, and an output schema, the description is fairly complete—explains the rhythmic concept, lists parameters, and mentions return values. However, it lacks guidance on how the compás integrates with existing tracks (track_index, unit_index) and the impact on existing notes, leaving some context 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 coverage is 0%, so the description compensates by listing all parameters with brief descriptions, defaults, and some musical context (e.g., pitch names). However, unit_index and track_index lack clear explanation of their roles, and the description could better clarify parameter interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 Flamenco compás, the rhythmic foundation, and distinguishes it from Western meter. It lists palos with beat patterns, making the purpose highly specific and differentiated from sibling 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides rich context about Flamenco but does not explicitly state when to use this tool vs alternatives (e.g., create_clave, create_samba_pattern). No 'when not to use' guidance, leaving the agent to infer usage from the specialized content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description explains what the tool creates and the rhythmic patterns for each tune type, but does not disclose side effects, permission requirements, or 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 with a clear introduction, a detailed breakdown of tune types, and a parameter list. While lengthy, the information is relevant and front-loaded. Could be slightly more 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?
The description thoroughly covers tune types but lacks parameter-level details. The output schema is mentioned but not described in detail. Given 9 parameters and the complexity of Irish trad, more completeness would be helpful.
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%, meaning the schema provides no descriptions. The tool description ends with a list of parameter names and defaults but does not explain each parameter's meaning beyond their names. This adds minimal value over 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 Irish traditional music accompaniment with bodhrán and feet, specifying the genre and instruments. It distinguishes itself from sibling tools like create_afrobeat_arrangement by being genre-specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 context on when to use the tool (for session tunes) and explains each tune type with meter and feel. However, it does not explicitly say when not to use it or compare with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must rely on itself. It explains the output structure (4 tracks with musical content) and notes that it returns notes per track and total. However, it does not disclose operational details such as whether it creates new tracks, overwrites existing ones, or requires specific permissions.
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 extensive genre background and track details that may be extraneous for a quick understanding. It is front-loaded with the main purpose but would benefit from a more structured format, such as bullet points for 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 gives a good musical overview but lacks operational context (e.g., track creation behavior, conflict handling). With an output schema present, the return value mention is adequate, but the tool's interaction with existing project state is unclear.
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 covers only 4 of 11 parameters (bpm, bars, root, octave) with ranges and defaults. The remaining 7 parameters (e.g., velocity, track numbers) are not described, and the schema provides only titles and defaults. Given the low coverage, the description adds some value but is incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 neurofunk DnB arrangement — 4 tracks: drums + sub-bass + Reese + stabs.' It also provides genre context and differentiates from siblings by focusing on neurofunk, a specific subgenre of drum and 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 about when to use this tool (for neurofunk DnB), including tempo range and key recommendations. However, it does not explicitly state when not to use it or compare it to sibling arrangement tools like create_dnb_arrangement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses the parameter behavior but does not mention side effects, prerequisites, or whether the operation is destructive. Missing behavioral context 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?
Two sentences: first states purpose, second explains parameter. No wasted words, front-loaded. 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?
Given output schema exists, return values are covered. However, the description lacks details on prerequisites, error conditions, and what exactly 'create a new track' entails (e.g., does it always succeed?). Adequate but not thorough.
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 significant meaning to the single parameter unit_index beyond the schema (which has 0% coverage), explaining the default -1 and how to use it for instrument AUs. This compensates for 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 it creates a new note/MIDI track on an audio unit, using specific verbs and resource. It distinguishes from sibling tools like create_instrument_track, create_audio_track, etc., by specifying 'note/MIDI 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 provides context on the unit_index parameter (use -1 for primary, specify instrument AU index) but does not explicitly state when to use this tool vs. other track creation tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the tool creates notes and returns a summary, but does not disclose whether it overwrites existing notes, requires specific track setup, or has performance implications.
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 clear definition, musical context, then parameter details. It is somewhat verbose for the parameter section but remains readable 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 input parameters well but lacks details on output format (beyond a brief mention) and error handling. No output schema is provided, and behavioral gaps (e.g., overlapping notes) remain unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 compensates thoroughly by explaining all 11 parameters with defaults, supported chord types, and behavioral options like retrigger_pedal. This adds significant meaning beyond the schema's bare 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 tool creates a pedal point with a sustained bass tone under changing chords. It provides musical context but does not explicitly differentiate from sibling tools like create_ostinato or create_bassline, so sibling distinction is implicit.
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 context (film scoring, organ preludes, rock ballads) implying when to use it, but lacks explicit guidance on when not to use or alternatives. No mention of prerequisites or compared tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the 4 tracks created and their roles, but does not state if existing content is overwritten, required permissions, or response behavior. Decent 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but well-structured: purpose first, then genre explanation, then track details. Could be slightly more concise, but the information is relevant and 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 complexity (psytrance genre, 4 tracks), the description covers genre, structure, and track details comprehensively. Output schema exists, so return values are likely handled. Adequate for agent 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 coverage is 0%, so description must compensate. It adds context for bpm, bars, key_root, and track_index, but ignores unit_index and start_beat. Partial compensation, not full parameter clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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' and resource 'psytrance arrangement', with specific genre details (BPM, key, track structure). It distinguishes from sibling tools like create_trance_arrangement by focusing on psytrance 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 psytrance generation and details the output, but does not explicitly state when to use this tool versus alternatives (e.g., create_trance_arrangement). No exclusions or when-not guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool generates MIDI notes for four instruments with defined pitches and styles, and returns a breakdown. It lacks details on whether it overwrites or appends to existing notes, but covers key behavioral aspects of the generative process.
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 long and includes historical context that may not be essential for tool usage. While well-structured with instrument, stroke, and style sections, it could be more concise by trimming extraneous cultural background.
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 parameters, no annotations, no schema descriptions), the description provides substantial context on instruments and styles but lacks clarity on how the generation interacts with existing content (e.g., overwrite vs. append) and the exact role of some parameters like unit_index.
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 richly describes styles and pitches (e.g., '35 = B0'), but fails to explain positional parameters like unit_index, track_index, and start_beat. Partial compensation—some parameters are well-documented, others are merely listed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 Japanese taiko ensemble (kumi-daiko) with specific instruments and styles. The purpose is unambiguous and distinct from sibling tools like create_djembe_ensemble or create_korean_percussion.
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 extensive cultural and technical context but lacks explicit guidance on when to use this tool versus alternatives. No 'when to use' or 'when not to use' statements, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that original regions are deleted and replaced, and returns new region info or error. Lacks details on permissions, additional side effects, or constraints beyond deletion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise, front-loaded with purpose, then behavior, then parameter details, then return info. 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 output schema exists, description covers key behaviors and parameters. Mentions return type. Could include prerequisites like region existence, but adequate for a tool with simple inputs.
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 description adds clear explanations for all three parameters, including an example for region_indices. Adds meaning beyond type and requirement.
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 flattens (merges) overlapping note regions on the same track, using specific verbs and resource. It distinguishes from generic 'merge' tools but does not explicitly differentiate from sibling 'merge_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when overlapping regions need to be combined, but does not provide explicit when-to-use or when-not-to-use guidance, nor alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context about the read-only operation and output format, but the readOnlyHint annotation already covers the safety profile. 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?
The description is extremely concise, front-loading the main action, with no extraneous information. 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 presence of an output schema, the description adequately covers the tool's behavior and parameters. Could mention handling of empty results.
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 adds crucial meaning to both parameters (unit_index and track_index), including the special value -1 for track_index.
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 automation events (ValueEventBox) on a unit's automation tracks, specifying the return values. However, it does not explicitly differentiate from sibling tools like list_automation_events_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 when to use the tool (to retrieve automation points) and explains parameter usage but lacks explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the loading method (URL vs base64) based on file location, adding useful behavioral context. However, it does not mention side effects, such as whether it creates tracks or replaces existing audio, leaving some 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.
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 parameter details. There is no unnecessary text, and 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?
For a simple load tool with a known output schema, the description covers the main behavior and parameter semantics. It could be improved by elaborating on what 'load into the DAW project' entails (e.g., track creation, audio pool), but it is otherwise 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?
With 0% schema description coverage, the description compensates by explaining both parameters: file_path with loading behavior and name with a default value. This adds meaningful context 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 it loads audio files (WAV/MP3/FLAC/OGG) into the DAW project. However, it does not explicitly differentiate from similar tools like mcp_opendaw_import_audio_to_tracks, leaving some ambiguity about the exact placement or usage context.
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 file_path behavior and name default but does not provide explicit guidance on when to use this tool versus alternatives. The context for using this tool is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions the underlying method (AudioUnitBoxAdapter.moveTrack) and that it reindexes the track, which gives some behavioral insight. However, it does not disclose side effects like how other tracks' indices shift or whether the change is permanent. The return value is specified as 'new index or error.' This is adequate but lacks depth.
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, using a short opening sentence followed by technical details. It avoids unnecessary words. Each sentence serves a purpose: purpose, implementation mention, parameter explanations, and return. Could be slightly more front-loaded, but overall 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 straightforward move operation, the description covers what, how, parameters, and return. The output schema likely documents the return format fully. It does not mention prerequisites (e.g., existence of unit/track), but these may be inferred. Overall sufficient for 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%, so the description must explain parameters. It does so: 'unit_index: AU index', 'track_index: Track index within AU', 'delta: Relative move (-1 up, +1 down).' This adds meaning beyond the bare integer types, specifying valid values for delta and the roles of 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 the action ('Move a track up or down within an audio unit'). The verb 'move' and resource 'track' are explicit. The context 'within an audio unit' distinguishes it from sibling tools like mcp_opendaw_move_audio_unit (moves the unit itself) and mcp_opendaw_move_notes (moves notes).
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 on when to use this tool versus alternatives like mcp_opendaw_move_audio_unit or other move tools. Sibling tools exist, but the description does not indicate when this tool is appropriate or when to use other tools instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the effect on note positions and the strength parameter, but does not disclose mutation behavior, undoability, or side effects. Adequate but not thorough.
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?
Description is concise with a clear first sentence and bullet-like parameter explanations. Could be more structured with sections, but no wasted 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?
Covers main behavior and return value, but lacks context on error conditions, idempotency, range of index parameters, and whether the operation is reversible. Given no annotations, slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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, description adds full meaning for all 4 parameters: division values, unit_index default, track_index default, and strength interpretation. 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 clearly states the verb 'quantize' and the resource 'note positions', and explains it snaps to a grid. It distinguishes itself from sibling tools like 'quantize_velocities' by focusing on positions.
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 on when to use this tool vs alternatives (e.g., 'apply_swing', 'humanize_notes'). Does not mention prerequisites 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.
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 tool modifies the visual offset and returns old and new values. However, it does not detail side effects, permissions, or whether the change is reversible. The behavioral impact is moderately 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 extremely concise with no fluff: 6 lines covering purpose, parameter list, and return value. Every sentence adds value, with clear grouping and 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?
Given the existence of an output schema and the tool's simplicity, the description adequately explains the set operation, parameter roles, and return value. It does not explain the hierarchy (unit->track->region) but this is inferable from parameter names. It is mostly complete for a straightforward 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?
Schema coverage is 0%, so the description must compensate. It lists parameters with brief labels ('AU index', 'Offset value in seconds') but lacks constraints, ranges, or relationships. This adds basic meaning beyond the schema's titles but is insufficient for precise 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 action: 'Set the waveform display offset of an audio region'. It explains the purpose: 'shifts the visual start of the waveform' and distinguishes itself from sibling tools like set_audio_region_fade or set_audio_region_gain by focusing on waveform offset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an implied usage context ('useful for aligning the waveform display with the actual audio content'), but lacks explicit guidance on when to use this tool versus alternatives or when not to use it. No exclusions or comparisons to sibling tools are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the purpose and effect but omits prerequisites (e.g., event must exist), side effects, error conditions, or reversibility. 'Returns success, or error' is vague.
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?
Well-structured with brief purpose, effect explanation, and parameter list. Each sentence adds value, though 'Returns success, or error' is minimal. Could be slightly more 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?
Covers purpose and parameters adequately, but lacks details on return value structure (though output schema exists), preconditions, and error handling. Missing information needed for safe use without 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?
All 6 parameters are explained with meanings, indices, interpolation options, and conditional dependency. Schema coverage is 0%, so description fully compensates by adding essential 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?
Description clearly states the verb 'Set' and the resource 'interpolation type of an existing automation event', and explains the effect on curve transitions. This distinguishes it from siblings like add_automation or update_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Does not explicitly state when to use this tool versus alternatives like update_automation_event. The context implies it is for modifying an existing event's interpolation, but no when-not-to or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states that it 'sets' the hue, implying a mutation, and discloses that it returns 'old and new hue'. However, it lacks details on side effects (e.g., UI update, error handling for invalid indices or out-of-range hue), which would be expected 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point. The first sentence states the purpose, followed by a compact parameter list, and a final sentence on return values. No extraneous 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 setter tool with all required parameters and a stated return value (old and new hue), the description is fairly complete. It could mention error conditions or indexing conventions, but given the tool's simplicity, it covers the essential 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 0% schema description coverage, the description provides crucial semantics: it explains that unit_index is the 'AU index', track_index is 'Track index within the AU', clip_index is 'Clip index', and hue is 'Color hue 0-360'. This adds significant meaning beyond the schema's bare type 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 the verb 'Set' and the resource 'clip in the session view', with a specific attribute 'color (hue)'. This distinguishes it from sibling tools like set_clip_label or set_clip_mute, which target different clip properties.
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., other set_clip_* tools). The description only explains what it does, not the context or preconditions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It states the tool 'moves' a marker (a mutation) but does not disclose side effects, return value, permissions, or error behavior (e.g., invalid index).
Agents need to know what a tool does to the world before calling it. Descriptions 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: a sentence and two parameter explanations. No unnecessary words, 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 output schema exists (though not shown), the description covers the parameters but lacks error handling, prerequisites (e.g., marker must exist), or behavioral details. It is adequate for a simple setter but not comprehensive.
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 add value. It explains marker_index as 'Index from list_markers (0-based)' and position_beats as 'New position in beats', providing context beyond the schema titles. Could be more precise (e.g., valid range).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Move' and the resource 'timeline marker to a new position'. It distinguishes from sibling tools like set_marker_label or set_marker_repeat by focusing solely on position.
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 hints that marker_index comes from list_markers (0-based), implying a prerequisite, but does not explicitly state when to use this tool versus alternatives like add_marker or delete_marker, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose effects on the project, whether operation is destructive, or if it affects global vs. per-track tuning. Only mentions parameter range.
Agents need to know what a tool does to the world before 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: two lines, no wasted words. Purpose stated first, then parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter and presence of output schema, description is mostly complete. Could mention if tuning affects global or per-project, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning beyond schema: explains frequency unit (Hz), default value (440), and common alternatives with historical context. Schema has 0% coverage, so this is essential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 tool sets the A4 base frequency for concert pitch tuning. Distinct from sibling tools like set_bpm or set_transpose.
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 vs alternatives. It only describes the parameter but doesn't explain contexts where tuning adjustment is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially compensates by documenting valid parameter values and ranges (e.g., waveform enum, volume in dB). However, it does not disclose behavioral aspects like immediate application, undoability, or side effects. The mention of returning old and new values adds some transparency, but the absence of broader behavioral context leaves 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 reasonably concise, with a clear opening sentence followed by a structured list of parameters. The bullet-point format for param_name details is efficient. Minor improvement could be made by separating the parameter list more distinctly, but overall it is well-organized and not verbose.
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 functionality and parameter details adequately for a setter tool. Given that an output schema exists, the mention of return values is helpful. However, it lacks contextual completeness by omitting prerequisites (e.g., Vaporisateur must be in the chain), potential errors, or usage examples. It is minimally viable but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 descriptions on properties), so the description fully compensates. It provides detailed semantics for each parameter: osc_index range, param_name with valid values and their meanings, value with units and range, and unit_index with auto-detect hint. This goes well beyond the schema's bare type 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 the tool's purpose: 'Set a parameter on a Vaporisateur oscillator.' It specifies the exact resource (Vaporisateur oscillator) and action (set parameter), and distinguishes from sibling tools like set_effect_parameter or set_instrument_param by focusing on a specific device. The listing of valid param_names and their meanings further clarifies 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., Vaporisateur must be loaded), when not to use it, or compare with other set_* tools. This lack of contextual usage information makes it harder for an AI 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.
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 explains the 'consolidate' parameter but does not describe side effects (e.g., whether the original clip is modified, where the clone is placed, or permissions required). Important behavioral details are 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 concise with two paragraphs plus parameter list. It front-loads the main action. Parameter descriptions are inline but clear. No unnecessary sentences.
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 has 4 parameters and no annotations, the description covers the basics and explains parameters. However, it lacks details on behavioral impact and precise semantics of 'same track'. Return values are mentioned as success/error, which is sufficient 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 coverage, the description must define parameters. It explains each parameter: unit_index, track_index, clip_index, and consolidate. The meaning of 'consolidate' is clearly explained. However, 'AU index' is not expanded, which could be ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Clone a clip (note or value) on the same track,' using a specific verb and resource. It distinguishes from sibling tools like clone_track, clone_effect_chain, and consolidate_clip by specifying it operates on clips and remains on the same 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 use for cloning clips on the same track, which differentiates it from tools that copy to other tracks or clone tracks/effects. However, it does not explicitly state when not to use it or mention alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the arrangement's structural details: track roles, default BPM/keys/bars, and harmonic approach. It does not cover side effects like project state modifications or prerequisites, but the creation 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but verbose, including a mini-tutorial on ambient music characteristics. While this adds context, it could be more concise for quick agent parsing. The key functionality is front-loaded, but excess text may dilute efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 7 parameters and an output schema, the description covers the arrangement's core behavior and defaults. It lacks explanation for three parameters but otherwise provides a solid mental model. The output schema exists, so return value explanation is unnecessary.
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%, but the description explains several parameters (track_index, bars, key_root, bpm) and their defaults. However, velocity, start_beat, and unit_index are not addressed, leaving gaps. The explanation of track_index plus offsets is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 an ambient arrangement and enumerates the 4 tracks it generates (Pad, Melody, Drums, Bass). It provides specific genre characteristics and default settings, making the purpose immediately clear and distinct from sibling 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 usage for ambient soundscapes but does not explicitly state when to use this tool over other arrangement creation tools. No direct comparisons or exclusions are provided, though the genre-specific naming helps the agent infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden of behavioral disclosure. It states it creates an audio clip and returns UUID and index, but does not mention side effects (e.g., overwriting existing clips), required prerequisites (e.g., sample already loaded), or whether this is destructive. The description is minimal on 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a clear opening sentence stating the purpose, a brief explanation of what audio clips are, and then a list of parameter definitions. Every sentence adds value without unnecessary words. It is front-loaded with the most important 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 has five required parameters and an output schema, the description adequately explains the parameters and confirms return values. It could mention that the clip is added to the session view and not the arrangement view, but overall it provides sufficient context 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?
The description provides meaning for all five parameters beyond the schema's type and title. For example, it explains sample_id as 'The ID returned by mcp_opendaw_load_audio', clip_index as 'Slot index in the clip launcher (0, 1, 2, ...)', and bpm as 'Source BPM of the sample (for warp marker calculation)'. This adds useful 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 'Create an audio clip' and specifies the resource 'in the session view (clip launcher)'. It distinguishes audio clips from audio regions, and among siblings like create_note_clip, it is the only one that creates session-view audio clips. This provides a clear and specific 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 mentions that audio clips are session-view counterparts and can be triggered independently, but it does not explicitly state when to use this tool versus alternatives like create_note_clip or create_audio_track. It provides context but lacks 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behavioral details: it creates melody on track_index and bass on track_index+1, explains modulation types, repeat structure, and section characteristics. It does not cover error cases or prerequisites, but for a creation tool, this 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 well-structured with clear sections, but it is somewhat verbose. It front-loads the core purpose and then provides background. A bit more conciseness would improve it, but it is still organized and 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?
Given the output schema exists (which likely documents return values), the description covers creation aspects adequately but lacks details on prerequisites, error conditions, or how this tool interacts with others. For a 9-parameter tool with no parameter documentation, it is moderately 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?
With 0% schema coverage, the description must compensate. It explains modulation types and repeat in detail, but several parameters like velocity, start_beat, unit_index, bars_per_section, key_root, and scale_name are not described. The description adds some value but not enough to fully compensate for 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 the tool creates a binary form (A|B sections) with optional repeats, distinguishing it from sibling tools like create_ternary_form or create_rondo. It provides a specific verb ('create') and resource ('binary form'), and explains 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides musical context (Baroque, folk, etc.) but does not explicitly state when to use this tool over alternatives. No direct comparisons to other form creation tools or exclusions are given, which limits guidance for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains pattern structure, parameter effects on rhythm, and return values, but lacks details on side effects (e.g., whether existing notes are cleared) and does not fully disclose the behavior for each parameter combination.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and provides structured subtype explanations, but parameter descriptions are embedded in prose rather than listed, making it slightly less scannable. Still efficient for the amount of 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 description covers the main pattern types and parameters, but misses details on start_beat, unit_index, and track_index. It mentions return values partially, and does not address how the tool interacts with existing track content. Adequate but not fully comprehensive.
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%. The description adds meaning for bars, pitches, velocity, and boom_bap_type with examples, but fails to describe start_beat, unit_index, and track_index, leaving these parameters underdefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 boom-bap hip-hop drum pattern', explains the core concept, and distinguishes from sibling tools by focusing on a specific genre pattern with detailed subtype definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 hip-hop drum patterns) and provides context for each subtype, but it does not explicitly state when not to use it or compare it to alternatives like create_trap_arrangement or create_lofi_arrangement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses return values ('notes created, bass type, and pitch info') but lacks information on side effects, permissions, or safety profile. No annotations are provided, so the description partially fulfills the transparency burden.
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, background, parameter details, return info, and examples. It is slightly verbose due to the detailed bass_type descriptions, but those provide valuable 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?
The description covers the purpose and core parameters well, but missing explanations for some schema parameters and lacks guidance on how this tool relates to sibling bass creation tools. An output schema exists but is not analyzed.
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 bass_type parameter is explained in exceptional detail with musical context, but other parameters (bars, root, octave, velocity) receive only brief description, and parameters like start_beat, unit_index, and track_index are not described at all despite being present 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 it creates an electronic bassline pattern, explicitly distinguishes from melodic basslines, and provides genre-specific options that differentiate 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for electronic dance music genres through the bass_type examples, but does not explicitly state when to use this tool versus alternatives or provide when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral transparency burden. It details the four tracks created and their musical roles, key, progression, tempo range, and time signatures. However, it omits side effects like interaction with existing 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?
Front-loaded with main purpose, followed by bullet-pointed track details. Some verbose contextual sentences ('Gospel music — the foundation...'), but overall well-structured and informative.
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 schema descriptions, the description adequately covers the arrangement components and key parameters. However, gaps remain for several parameters (e.g., unit_index, start_beat) that are not explained, affecting agent's ability to use 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%, so the description must compensate. It explains some parameters (bpm, root, tempo range, track numbers) but not all 11 (e.g., unit_index, start_beat, octave details). Partial but insufficient 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 creates a full gospel arrangement with specific instruments (shuffle drums, walking bass, Hammond organ, choir). It distinguishes from sibling genre-specific tools by detailing the gospel style components.
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?
While the description implies usage for traditional gospel arrangements, it lacks explicit when-to-use or when-not-to-use guidance compared to other genre arrangement tools. No alternatives or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains parameters and return values but does not disclose side effects, idempotency, permission requirements, or whether it modifies existing data. The phrase 'returns notes created' implies creation without modification, but this is not explicit.
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 clear one-line summary, followed by contextual information and a parameter list. The musical background paragraph is informative but slightly verbose for a technical tool. Overall, it is well-organized and efficient.
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 8 parameters, no annotations, and an output schema mentioned, the description covers the main aspects but lacks clarity on project-specific terms like 'AU' and 'note tracks'. The return values are summarized but not detailed, which is acceptable since an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides explanations for all 8 parameters, including valid options for split_mode. However, some terms like 'AU index' and 'track index' are not fully elaborated, leaving minor ambiguity for an AI 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 tool creates a hocket, a specific melodic splitting technique. It distinguishes from siblings like create_melody or create_counterpoint by naming the exact compositional technique and providing a definition.
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 hocket technique but does not explicitly state when to use this tool versus alternatives like create_melody or create_counterpoint. No guidance on prerequisites or contexts where the tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 explains that the tool creates notes that ascend or descend through a scale and provides parameter details like velocity patterns. However, it does not disclose side effects (e.g., whether it overwrites existing notes, if there are prerequisites for track_index, or what happens on error). It also doesn't mention the output schema, though one exists. The description is moderately transparent but could be more explicit about behavioral aspects beyond basic functionality.
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 defining the purpose, a brief explanatory paragraph, and a clear parameter list. It is front-loaded with the core concept. While it includes some extra context (musical applications), every sentence adds value. It is not overly verbose given the complexity of the tool, but slightly longer than necessary. Score 4 for good structure and efficiency.
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 parameters, no annotations, has an output schema), the description covers the tool's purpose and parameter details well. However, it omits information about the return value (despite an output schema existing), error conditions, prerequisites for using the tool (e.g., track must exist), and idempotency. The musical context is useful but not essential for correct invocation. The description is adequate but incomplete for a fully autonomous 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 must compensate, and it does so effectively. Each parameter (12 total) is described in a separate line, explaining its purpose, allowed values, defaults, and format (e.g., 'pitches: Comma-separated MIDI pitches' and 'direction: Pitch direction when using scale generation — up/down/alternate'). This adds significant meaning beyond the bare schema. Minor gaps: 'velocity_pattern' enum values are listed but not enumerated in the schema; some defaults are repeated from schema but still helpful. Overall, the param descriptions are thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 polyrhythm — N notes evenly spaced across M beats.' It distinguishes this tool from the sibling 'create_polyrhythm' by specifying it creates a 'melodic polyrhythm rather than just rhythmic hits.' The verb 'create' combined with the resource 'melodic polyrhythm' and the specific explanation of cross-rhythms against a main pulse makes 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about when this tool is appropriate, mentioning jazz cross-rhythm, prog-rock metric modulation, etc. However, it does not explicitly tell the agent when to use this tool versus alternatives like the sibling 'create_polyrhythm' (which is a non-melodic version). No 'when not to use' guidance is given, so the agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 describes what the tool creates (3 tracks, their roles, and style influences) and provides parameter defaults, but does not address side effects (e.g., overwriting tracks), prerequisites, or error handling, which are important for agent decision-making.
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 genre notes, track details, and parameters. It front-loads the purpose. Some detail (e.g., listing all genre characteristics) could be trimmed, but overall it is efficient and informative for its 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?
Given the tool has 10 parameters and no annotations, the description is incomplete. It explains output (3 tracks) but leaves several parameters unexplained (velocity, track indices, start_beat, unit_index). The presence of an output schema reduces the need to describe return values, but the parameter gaps remain significant.
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 four parameters (bpm, bars, root, octave) with examples, but leaves six parameters (velocity, bass_track, drum_track, start_beat, unit_index, cowbell_track) undocumented. This partial coverage is insufficient for a tool with 10 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 'Create a full drift phonk arrangement — 3 tracks: drums + 808 + cowbell lead,' specifying verb, resource, and genre. It distinguishes this tool from sibling arrangement tools by naming a specific genre (drift phonk) and its unique 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 on when to use the tool (for creating a drift phonk arrangement) and lists genre characteristics, but does not explicitly state when not to use it or compare to alternatives. The sibling list includes many other arrangement tools, but the description makes the niche clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does not specify side effects like whether existing notes are overwritten or appended, nor does it clarify the role of parameters like track_index and unit_index in placement. The musical behavior is well-described, but operational transparency is lacking.
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, definition, genre details, parameter list, and examples. It front-loads the purpose. However, the genre sections are somewhat verbose (e.g., artist lists), and some sentences could be condensed. Overall, it efficiently imparts necessary 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?
With an output schema present, the description need not explain return values. It thoroughly covers musical intent and genre-specific behaviors, but it omits operational details like where the riff is placed (track, unit, beat) and fails to describe all parameters. For a 10-parameter tool, this leaves noticeable gaps.
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% parameter descriptions, so the description must compensate. It explains 7 of 10 parameters (riff_type, key_root, scale_type, bars, octave, velocity, seed) with meaningful context (e.g., octave range for guitar). However, start_beat, unit_index, and track_index are not mentioned, leaving critical placement 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 clearly states 'Create a genre-specific riff — catchy repeated melodic fragment.' It then defines a riff in contrast to melody and ostinato, distinguishing it from sibling tools like create_melody or create_ostinato. This precise differentiation and strong verb-resource pairing earn a 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides genre-specific guidance and examples (e.g., rock, funk, metal) and contrasts riff with melody/ostinato, which helps the agent decide when this tool is appropriate. However, it lacks explicit 'when to use' or 'when not to use' directives, such as prerequisites or alternatives, so it does not fully reach a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the pattern structure and variations, but does not disclose whether notes are added or overwritten, authentication needs, or side effects. Output is described as notes, stroke breakdown, and pattern info, but operational details like track setup are missing.
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?
Description is lengthy with a historical paragraph. While educational, it is somewhat verbose for an AI agent. However, it is well-structured with clear variation descriptions and front-loaded 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 (4 variations, 10 parameters, output schema exists), the description covers musical context, variation details, and parameter basics. It mentions output content. Gaps: unit_index, track_index, and start_beat usage not fully explained. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 10 parameters with defaults but no descriptions. Description adds meaning for bars, variation, velocity, and pitches (e.g., '36 = C1'). However, unit_index, track_index, and start_beat are mentioned but not fully explained. Overall 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 songo drum pattern, a specific Cuban drum-kit fusion. It distinguishes songo from other patterns like clave, cascara, and tumbao, which are sibling tools. The purpose is specific 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for songo (Latin music, salsa, timba, Latin jazz) but lacks explicit guidance on when to use this tool versus alternatives like clave or tumbao. It implies usage through musical context but does not state when not to use or list competing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already indicate destructiveHint: true, so the description's mention of 'Delete' is consistent. The description adds value by stating it 'Returns remaining clip count', which is behavioral info not present in annotations. However, it does not disclose other behaviors like whether deletion affects automation, undo stack, or if it shifts remaining clip 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 exceptionally concise: two short sentences. The first sentence states the purpose, and the second lists the parameters with their meanings. Every word contributes to understanding, with no fluff or redundancy. It is optimally sized 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?
Given the tool's simplicity (delete operation, 3 parameters), the description covers the essential aspects: purpose, parameter meanings, and return value. It notes that clip indices are 0-based, which is important. However, it could be more complete by explaining that deleting a clip may shift subsequent clip indices or that the tool operates within the context of a unit and track. An output schema is not provided, but the description compensates by stating the return type.
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 carries the full burden. It provides clear explanations for all three parameters: 'Audio unit index', 'Track index', and 'Clip index to delete (0-based)'. This adds meaningful context beyond the schema titles. A higher score would require additional details like valid ranges or relationships between 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 'Delete a clip from a track (session view)', providing a specific verb ('Delete'), a distinct resource ('clip'), and context ('session view'). This distinguishes it from sibling delete tools like delete_note, delete_region, and delete_audio_unit, which target different resources. 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 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 (e.g., that the clip must exist), when it is appropriate to delete a clip, or what to do before calling this tool (e.g., listing clips to obtain indices). There is no 'when not to use' or comparison with other deletion tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already set destructiveHint=true, so the description adds context about what is removed (notes, audio, automation). It also mentions the return value (remaining region count). Does not fully detail side effects like fades or crossfades.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured: first sentence states purpose, then bullet-style parameter explanations. 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?
With 4 parameters and a simple return value, the description covers most aspects. Explains what gets deleted and what parameters do. Could mention potential errors or prerequisites (e.g., region must exist).
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 explains each parameter meaning: track_index, region_index, unit_index (with default -1), region_type (with allowed values 'note', 'audio', 'value'). This adds significant value beyond the 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 it deletes a region from a track and explains what gets removed depending on region type (notes, audio, automation). It distinguishes from siblings like 'delete_note_region' or 'delete_audio_region' by specifying a broader scope with region_type parameter.
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 does not provide guidance on when to use this tool versus other delete tools (e.g., delete_note_region, delete_audio_region). No explicit when/when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers internal mechanism (OfflineEngineRenderer, per-AU ExportConfiguration) and output (list of stem files). It does not detail side effects like file overwriting, but for a read-like export 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?
Four focused sentences plus a workflow line, no filler. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Describes workflow and return type, but missing parameter semantics limits completeness. Output schema exists but doesn't offset parameter 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?
Schema coverage is 0% and the description adds no detail on filename_prefix format or sample_rate expected range/units. Both required parameters lack semantic clarification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Export'), resource ('each audio unit as a separate stem WAV file'), and differentiates from sibling tools like export_dawproject or export_midi.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description provides a concrete workflow chain (create_instrument_track → load_audio → place_audio_region → add_effect → export_stems), guiding when to use this tool. However, it does not explicitly mention when not to use or alternatives like export_single_stem.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral detail about the return structure, which complements the readOnlyHint annotation. No contradictions, and the description clarifies what the read operation retrieves.
Agents need to know what a tool does to the world before 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, each serving a purpose: first defines the action, second details the return format. No superfluous text, well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with an output schema, the description is adequate but misses details like index base (0-based?), validity conditions, or error cases. Could be more precise.
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 repeats the parameter name with minimal extra meaning ('Audio unit index'), adding little beyond the schema's title. With 0% schema description coverage, the description should provide more context, such as indexing convention or range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 effect chain for an audio unit, and specifies the return format as an ordered list of effects with type, enabled state, and index. This distinguishes it from sibling tools like list_effects or 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this versus similar tools like list_effects or get_effect_state. The description implies its purpose but does not compare or exclude alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint=true. The description adds that the tool returns duration in beats and seconds or an error, but does not disclose additional behavioral aspects like side effects or cost. Given annotations, a score of 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the core purpose and then detail the return format. Every word is necessary, earning 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?
For a simple getter with an output schema and annotations, the description is quite complete. It explains what the duration represents and what units are returned. Could mention edge cases (e.g., no regions) but is otherwise sufficient.
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 zero parameters, and schema_description_coverage is 100%. The description has no need to explain parameters. Baseline score of 3 is correct as no additional meaning is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Get the total project duration — the end position of the last region across all tracks.' It provides a specific verb (Get) and resource (total project duration), and distinguishes from sibling tools like 'get_project_info' by focusing solely on 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 when to use (when total duration is needed) but does not explicitly state usage context or list alternatives. With many sibling 'get_' tools, explicit guidance would improve clarity, but the purpose is self-explanatory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the agent knows it's safe. The description adds the specific return fields (created, bpm, time_signature, etc.), which is useful context beyond annotations. No additional behavioral traits (e.g., performance, side effects) are disclosed, but 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?
The description is very concise: three short sentences that front-load the purpose and return fields. No wasted words, though there is slight redundancy between the first and third sentences. Still, it 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 metadata fetch with zero parameters and an output schema present, the description provides all necessary context: what it returns and that it's a quick overview. No gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description doesn't need to add parameter info. Context notes schema coverage is 100% (trivially) and baseline for 0 params is 4. The description does not add anything beyond what the schema provides, but that's acceptable here.
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 gets project metadata and lists specific fields (creation date, BPM, time signature, AU count, track count). It distinguishes itself as a 'quick overview' but does not explicitly differentiate from siblings like get_project_info or get_full_project_state, thus not 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 for a 'quick overview in one call,' but provides no explicit when-to-use vs alternatives like get_full_project_state or get_project_info. No exclusions or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. Description adds value by listing return contents, but does not disclose additional behavioral traits (e.g., cost, 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?
Single sentence with no unnecessary words; clearly front-loaded with verb and resource; each listed component is 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 zero parameters and existence of output schema, description provides reasonable coverage of what the state includes. Could mention more aspects, but sufficient for a high-level 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?
No parameters; schema coverage is trivially 100%. Baseline of 4 for zero parameters applies; description adds no extra parameter info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 the verb 'Get' and resource 'full project state', listing specific components (BPM, sample rate, playing status, track list, effects chain). It distinguishes from sibling get_* tools by emphasizing comprehensive snapshot.
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 vs alternatives like get_track_info or get_mixer_state. The description does not mention context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses MIDI format support, PPQN conversion, and return values (note count, time range). However, it does not clarify whether importing overwrites existing notes or appends, nor error behavior on invalid files. Moderate transparency, leaving some behavioral 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?
Description is a single paragraph with inline parameter explanations. It front-loads the main purpose and format support. While concise, a more structured layout (e.g., separate sections) could improve readability. 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?
Given an output schema exists, the description adequately covers return values and key conversion details. Lacks mention of error handling or edge cases (e.g., invalid file path, unsupported format). Mostly complete for a file import 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 description must explain parameters. It does so thoroughly: file_path, unit_index (including -1 meaning), track_index, offset_beats (with example). All parameters are clearly defined with practical 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?
Clearly states 'Import a MIDI file and create note events on a note track', specifying verb and resource. Also notes supported MIDI formats. Does not explicitly differentiate from sibling import tools (e.g., mcp_opendaw_import_dawproject) but 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?
Provides basic context (what it does) and parameter explanations, but no explicit guidance on when to use this tool vs alternatives, such as when to search all AUs (unit_index=-1) or how to locate the track_index. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds the scope (audio and MIDI) but does not disclose any additional behavioral traits such as whether the list is sorted, if it includes inactive effects, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions 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, clear sentence with no wasted words. It front-loads the purpose immediately with 'List all available...'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 no parameters and presence of an output schema, the description is sufficient. It could optionally mention the output format, but the output schema covers that. Slightly more context about the nature of the list (e.g., names or IDs) would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%. With no parameters, the description cannot add parameter meaning, but baseline is 4. 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 clearly states the tool lists all available audio and MIDI effect types, with a specific verb and resource. It distinguishes from siblings like 'list_midi_effects' (only MIDI) and 'list_effect_parameters' (parameters of a specific effect).
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 vs alternatives. There is no mention of when not to use it or comparison with querying specific effect lists or filtering options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently indicates a read-only status check with no side effects, listing return values. Since annotations are absent, the description compensates well, though it could explicitly state 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 extremely concise with two short sentences and a return list, all front-loaded. Every part is useful and no space wasted.
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 query tool with an output schema, the description is complete: it explains the purpose and return values. No additional context is required.
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; the description adds no parameter information, but none is needed. Baseline for 0 parameters is 4, and this is met.
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 checks if all audio samples are loaded and ready for playback, and specifies return values. However, it does not distinguish this tool from siblings like get_engine_status or wait_for_condition, leaving potential 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 on when to use this tool versus alternatives. It only states what it does, missing context about when it is appropriate to call or when other tools might be better suited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses that the tool removes an audio unit and cannot remove the primary bus, but does not detail side effects like irreversibility, permissions required, or impact on other routing. This is insufficient for a destructive 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, with a clear first sentence stating purpose, followed by parameter details and a constraint. 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?
Given the tool's simplicity (two parameters, output schema exists), the description covers the key aspects: purpose, identification, and constraint. It could mention the irreversible nature or expected output but is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description provides clear guidance for both parameters: bus_index must be from list_audio_buses and >0, fx_unit_index from create_send. This compensates well 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 it removes an FX audio bus and its associated audio unit, specifies two identification methods (bus_index or fx_unit_index), and includes a constraint (cannot remove primary bus index 0). It distinguishes from sibling tools like create_audio_bus or remove_send by being the only removal tool for 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 explains when to use the tool (to remove an FX audio bus) and how to identify the bus (from list_audio_buses or create_send). However, it does not explicitly state when not to use it or compare to alternatives like remove_send for removing only the routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It describes the pipeline, models, and output format, but does not disclose potential issues like file size limits, processing time, or error handling.
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?
Well-structured with clear sections (purpose, model list, parameters, example). Some redundancy but overall efficient for the detail provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 (not shown but indicated), the description covers functionality well, including model specifics and return structure. Could mention expected file sizes or processing time.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 thoroughly documents all three parameters (input_file, model, output_dir), including model options with specific use-case details and defaults. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it separates audio into stems using SOTA AI models. Lists specific models and their outputs. However, it does not explicitly differentiate from the sibling 'split_stems' tool, which may have a related 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?
Provides model descriptions and use cases (e.g., 'best vocal extraction'), but lacks explicit guidance on when to use this tool versus alternatives like 'split_stems'. No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 bus_index comes from list_audio_buses and that 0=primary output, but does not mention side effects, error behavior, or if muting a bus affects audio routing. Basic 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 extremely concise and front-loaded: first sentence states the purpose, followed by two clear parameter explanations. No extraneous text. Every word 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?
The description is fairly complete for a simple toggle tool: it explains the parameters and indicates that bus_index comes from list_audio_buses. Although it doesn't mention return values (output schema exists), it provides enough context for an agent to use the tool correctly. Minor gaps in error handling.
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 significant meaning beyond the schema: it explains bus_index as derived from list_audio_buses and the meaning of enabled. This compensates for the 0% schema description coverage. Could be more precise about invalid 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 action (enable or mute) and the resource (audio bus), and adds context about FX bus A/B comparison. It effectively distinguishes the tool's purpose from sibling tools like set_bus_color.
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, nor does it mention conditions under which it should or should not be used. It simply states the action without contextual prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description minimally discloses behavior: sets routing mode with two possible values and a default. Does not mention side effects, permissions, or safety implications of changing routing.
Agents need to know what a tool does to the world before 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 plus a concise parameter list. Purpose is front-loaded. No redundant or irrelevant 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?
Adequately covers the tool's operation and parameter meanings for a simple setter. Output schema exists, so return values are not needed in description. Could mention error conditions or prerequisites but not critical.
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 explains each parameter: unit_index as source audio unit, send_index as index on source AU, and routing as 'pre' or 'post' with default. This adds meaning 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 clearly states the verb 'Set' and the resource 'routing mode for an aux send', specifying pre-fader or post-fader. It distinguishes from sibling tools like set_send_level and set_send_pan by focusing on routing mode.
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, or prerequisites (e.g., send must exist). The description lacks context about when pre vs post routing is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It explains parameter meanings but lacks details on side effects, error handling (e.g., if effect_index is not a StereoTool), or whether the change is immediate or reversible. The output is not described, though an output schema 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 concise: one sentence for the purpose followed by three lines for parameters, each on its own line. It is front-loaded with the action and avoids extraneous 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 explains parameter semantics but lacks context on prerequisites (e.g., ensuring the unit has a StereoTool effect on the given effect_index) and error conditions. Given the tool has 3 required parameters and an output schema, the description is minimally adequate but has 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 compensate. It does so by explicitly defining each parameter: unit_index, effect_index, and panning_mixing with possible values (0=linear, 1=equal-power, or other supported values). This adds significant meaning 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 the panning mixing mode') and the resource ('on a StereoTool effect'). It distinguishes this tool from sibling tools like set_track_panning, set_send_pan, etc., by specifying the target effect type.
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 specifying the condition 'must be a StereoTool', but does not explicitly state when to use this tool versus alternatives like set_track_panning or set_send_pan. No 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides moderate transparency by detailing argument types and common settings. However, it does not disclose side effects, persistence, or error handling behaviors.
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 and structured into args and common settings. While the list of common settings is lengthy, it is well-organized and informative.
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 output schema exists, return values are covered. However, the description lacks preconditions (e.g., valid key for category) and postconditions (e.g., immediate effect, persistence). It is adequate but not comprehensive.
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 descriptions (0% coverage), so the description carries the full burden. It explains the 'category' enum, gives example 'key' values, and specifies 'value' format. The list of common settings adds substantial 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 'Set a studio preference setting' with a specific verb and resource. It lists examples of categories and common settings, distinguishing it from the sibling 'get_studio_settings' for reading.
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 (to change settings) but lacks explicit guidance on when not to use or alternatives. It does not mention that 'get_studio_settings' should be used to read current values.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states it sets the time signature, without mentioning side effects (e.g., whether existing notes are moved, if it applies to all tracks, if it requires project to be open). This is insufficient 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 very concise: one introductory sentence followed by two clear parameter explanations. No extra words, front-loaded with the action, and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 required params, no nested objects, output schema exists), the description explains the parameters adequately. However, it omits what the tool returns or any constraints on valid values, but for a straightforward setter, this is almost 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 explains numerator as 'number of beats per bar' and denominator as 'note value per beat' with examples (4=quarter, 8=eighth), adding meaning beyond the integer type and title 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 'Set the project time signature' with concrete examples (4/4, 3/4, 6/8, 7/8), differentiating it from siblings like add_signature_change or create_balkan_meter by focusing on the global project setting. It explicitly defines numerator and denominator roles.
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 sets the overall project time signature, but does not explicitly contrast with siblings like mcp_opendaw_add_signature_change (which likely adds a local change). No guidance on when to use each, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 indicates the tool checks validity and returns issues, implying a non-destructive read operation, but lacks details on side effects, performance, or required context (e.g., project must be loaded). No contradiction with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the core purpose, and includes return value details without extraneous words. Every sentence contributes 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?
Given zero parameters and an existing output schema, the description adequately covers the tool's function. It specifies the key check (overlapping regions) and return type. However, it could be slightly more complete by noting that the project must be active or loaded, though this is implied for most DAW tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description does not add parameter-specific information, but with no parameters, the baseline score is 4, and the description provides no additional 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 the tool validates a project by detecting overlapping regions on the same track, and it specifies return values (valid bool and details). It distinguishes from similar siblings like 'detect_problems' by focusing on a specific check.
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 on when to use this tool versus alternatives. The description does not mention prerequisites, such as requiring a loaded project, nor does it differentiate from potential overlapping validation tools like 'detect_problems'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions polling behavior and the conditions for completion (true or timeout), which adds context beyond the schema. However, it does not disclose potential side effects, error handling, or limitations such as maximum timeout or blocking behavior. Given no annotations, the description carries the full burden but provides only 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences: purpose, behavior, and parameter details. It is well-structured and front-loaded with the core action, wasting no 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 existence of an output schema, the description covers purpose, behavior, and all parameters. It lacks explicit details on timeout behavior (e.g., return value on timeout) but is still fairly complete for a wait utility.
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 all three parameters: condition_js as a JavaScript expression, timeout_ms with default, and poll_interval_ms with default. This adds significant meaning beyond what the schema provides, though it could include more constraints like allowed characters or 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 waits for a JavaScript condition to evaluate to true in the DAW context. It is specific and distinct from sibling tools, which are primarily creation, analysis, or manipulation tools, with no other wait tools present.
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 does not provide any guidance on when to use this tool versus alternatives or when not to use it. There is no mention of prerequisites, scenarios, or exclusions, leaving the agent without context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states constraints on allowed effects but does not disclose side effects, reversibility, or state dependencies. Basic transparency but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions 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 precise sentences: purpose, parameter examples, and constraint. No redundant words; each 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?
Given the output schema exists, the description doesn't need to cover return values. However, it lacks information about prerequisites (e.g., units must exist, effect must already be added). Adequate for a specialized tool but not 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 provides meaningful examples for each parameter (e.g., source unit: drums, target: bass) and explains the sideChain field requirement. This adds significant 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 begins with a clear action verb ('Connect') and identifies the specific resource (sidechain from an audio unit to a Compressor/Gate on another). It distinguishes from siblings like 'mcp_opendaw_apply_sidechain' by specifying direct routing between units.
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 target effect requirement (must have sideChain field) but lacks explicit when-to-use or when-not-to-use guidance relative to alternative sidechain tools. Usage is implied but not directly contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 output (notes, grouping, accents) and the tapan pattern, but does not disclose side effects (e.g., whether existing notes are modified, or the interaction with track/unit indices). Constraints like velocity range (0-1) are mentioned, but error conditions are not.
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: concept overview, meter listing, variations, then parameter list. Front-loaded with purpose. Slightly verbose with extensive meter background, but appropriate for a specialized creative tool. 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?
Given the complexity (11 parameters, output schema exists), the description is fairly complete: it explains the theory, all parameters, and return values. Missing details about DAW state interaction (e.g., whether tracks/units must pre-exist) and validation assumptions, but overall adequate for an informed 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 coverage is 0%, so the description must compensate. Each parameter has a brief description (e.g., meter names, cycles range, pitch roles), adding meaning beyond type/defaults. Some descriptions (like pitches) could be more detailed, but overall the tool's parameters are 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 clearly states the tool creates Balkan additive meter patterns, a specific verb+resource. It distinguishes itself from sibling rhythm tools by focusing on asymmetric time signatures with detailed meter and variation options.
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 description of Balkan meters, but no explicit guidance on when to use this tool versus alternatives like create_cross_rhythm or create_euclidean_rhythm. No when-not-to-use or prerequisite conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the musical output but does not disclose operational behaviors such as whether existing track data is overwritten, what happens with invalid track indices, or if the tool is idempotent. No annotations are provided, so the description carries the full burden, which it partially meets.
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 and includes extensive musical education, which may be informative but could be more concise. The key information is front-loaded, but the later sections repeat concepts (e.g., the 12-bar progression).
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 comprehensively covers the tool's purpose, musical structure, parameter usage, and examples. It provides sufficient context for an AI agent to understand the output and constraints, especially given that an output schema exists (not shown here).
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 most parameters (bpm, bars, root, octave, tracks) and providing examples. However, parameters like 'velocity' and 'start_beat' are not described, leaving some 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 clearly states the tool creates a full blues arrangement with specific instrumentation (drums, bass, chords, lead) and musical details. It distinguishes itself from sibling arrangement tools by focusing on the blues genre and 12-bar form.
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 extensive musical context and parameter usage but lacks explicit guidance on when to use this tool versus sibling arrangement tools. It implies usage through genre specificity but does not directly advise against using it for non-blues styles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It transparently explains that the tool creates call on track_index and response on track_index+1, and details response type behaviors. It omits potential overwrite behavior or permissions, but provides adequate transparency 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with bullet points for response types and parameter explanations. Some information could be condensed, but the musical context justifies the length for an agent.
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 no output schema, the description lacks explanation of return values or output format. It covers key behavioral aspects and many parameters, but misses some parameter explanations and the return value, leaving some gaps for a tool with 12 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?
Schema coverage is 0%, so the description must add value. It provides detailed explanations for call_pattern, call_rhythm, response_interval, response_type, gap_beats, and pairs, including enumeration of response types. It does not explain key_root, velocity, scale_name, start_beat, unit_index, or track_index, though some are 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 clearly states the tool creates call-and-response patterns, with a specific verb ('create') and resource ('call-and-response'). It distinguishes from sibling tools like create_arpeggio, create_bassline, etc., which create different musical structures.
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 call-and-response as a concept and lists response types, implying appropriate contexts. However, it lacks explicit when-to-use or when-not-to-use guidance compared to alternatives. With many sibling tools, more explicit differentiation would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden for behavioral disclosure. It explains the track layout (bass on track_index, chord pads on track_index+1, variation on track_index+2) and variation styles, which adds value. However, it does not discuss safety, idempotency, error conditions, or implications of repeated calls.
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, starting with a clear definition and purpose, then detailing parameter formats and styles, and ending with track layout. It is appropriately sized with minimal redundancy, though slightly verbose in the variation style descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 presence of an output schema (per context signals), the description provides sufficient conceptual and behavioral context. It covers the chaconne structure, parameter semantics, and track placement. Minor gaps exist, such as error handling or validity of inputs, but overall it is complete for a creative 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 explains formats for bass_pattern, bass_rhythm, chord_pattern, and variation_style, adding meaning beyond the schema. However, it leaves repeats, velocity, start_beat, unit_index, and track_index unexplained, covering only about 5 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 clearly defines what a chaconne is, specifies it creates a repeating bass line and chord progression with variations, and explicitly distinguishes it from ground bass and passacaglia. This helps the agent understand the tool's unique purpose 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 provides clear context for when to use a chaconne by defining it and contrasting with ground bass and passacaglia. However, it does not explicitly state when not to use this tool or recommend alternatives, though the sibling tools for ground bass and passacaglia exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Discloses track roles and musical style, but does not mention whether existing content is overwritten, whether tracks are created, or other side effects. 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?
Description is appropriately sized, front-loaded with purpose and track overview. Genre background and examples are helpful but slightly verbose. 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?
Output schema exists, so return value explanation is unnecessary. Description covers core functionality and main parameters, though misses some less-used parameters. Adequate for typical 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?
Schema coverage 0% but description explains 5 key parameters (bpm, bars, root, octave, velocity) with defaults and examples. Six parameters (pad_track, bass_track, etc.) are undocumented, relying solely on schema names. Incomplete 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?
Description clearly states 'Create a full liquid drum & bass arrangement across 4 tracks' with specific track roles. Distinguishes from sibling 'create_dnb_arrangement' by specifying liquid DnB characteristics and references to artists.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Examples show typical usage. Implicitly contrasts with general DnB tool via description of liquid style, but lacks explicit when-not-to-use guidance or comparisons to specific siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 auto-creation of clips and that notes are added to the first clip. However, it does not mention error conditions, what happens with multiple clips, or return 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?
The description is concise and well-structured: purpose first, then parameter list with bullet-like clarity, followed by behavioral notes. Every sentence provides value without 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?
The description lacks information about the return value or output schema, which is listed as existing but not described. For a creation tool, this is a notable gap. Additionally, it does not cover edge cases like invalid parameter 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?
Despite 0% schema coverage, the description explains each parameter with examples (e.g., pitch: 60 = C4) and ranges (velocity: 0.0-1.0). It adds significant meaning beyond the schema's type and name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Create a MIDI note on a note track,' clearly stating the action and resource. This differentiates it from sibling tools like 'create_notes_batch' (batch creation) and 'create_note_clip' (clip creation).
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 parameter details and mentions automatic clip creation, but it does not explicitly state when to use this tool versus alternatives or when not to use it. The context is implied 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full transparency burden. It discloses that all notes go into one region, creates a region if needed, and uses a single editing block. However, it omits details on how 'unit_index' and 'track_index' parameters affect 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 front-loaded with purpose, uses bullet points for clarity, includes an example, and is concise with no extraneous 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 core functionality, usage guidance, and behavioral traits well. However, it omits explanations for two parameters, and doesn't mention error handling or limits on note count. Output schema exists, so return values are not needed.
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?
With 0% schema description coverage, the description must compensate but only details the 'notes' parameter (structure, optional fields, default velocity). It provides an example. The other two parameters ('unit_index', 'track_index') are not explained 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 clearly states the tool creates multiple MIDI notes in a single call, explicitly for batch creation of melodies, chords, and arpeggios. It distinguishes itself from the sibling tool 'create_note' by highlighting efficiency gains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 by contrasting with repeated calls to 'create_note', emphasizing round-trip efficiency. However, it lacks explicit when-not-to-use or alternative sibling tools for specialized patterns.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden, but it only explains basic behavior (creates clip, uses specific play mode) and parameter meanings. It does not disclose side effects, prerequisites, error conditions, or overwrite behavior. The safety profile is not 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 concise with a summary line, a brief explanation, and a parameter list. Every sentence adds value, and the structure is clean and 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 description covers the basics but lacks details on return value, prerequisites (e.g., track must exist), and potential side effects. The output schema exists but is not shown, so completeness is adequate but not thorough.
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's meaning (e.g., sample_id from load_audio, clip_index as slot index). This adds significant value beyond the schema's simple 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 creates a pitch-stretched audio clip in session view, and distinguishes it from the sibling time-stretched version by emphasizing pitch alignment with tempo. The specific verb-resource combination and mention of AudioPitchStretchBox add clarity.
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 maintaining pitch, but does not explicitly state when to use this tool versus the time-stretched alternative (mcp_opendaw_create_time_stretched_clip). No when-not-to-use or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description bears full burden. It describes the action (add) and mentions return values (new pad index and MIDI note). However, it lacks details on side effects, error states, or prerequisites (e.g., if a pad with the same MIDI note exists). Adequate 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?
Two short sentences plus bulleted parameter descriptions. Every sentence provides value, no fluff. Front-loaded with 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?
Has output schema (mentioned but not provided), and description notes return values. Covers purpose and all parameters. Lacks error handling or overwrite behavior, but for a simple creation tool this 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 has 0% description coverage, so description must add meaning. It does so effectively: explains midi_note with examples (36=C1), sample_name, duration_seconds, and unit_index with auto-detect hint. Greatly enhances 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 clearly states 'Add a drum pad to a Playfield drum machine.' This specific verb-resource combination distinguishes it from sibling tools like copy_playfield_sample, list_playfield_samples, and set_playfield_sample_enabled.
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 on when to use this tool versus alternatives (e.g., copy or modify). Agent must infer from the verb 'Add' that it creates a new pad, but no when-not-to-use or contrasting conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses significant behavioral details: sections are created sequentially on specific tracks, degree patterns for each section, and the number of bars per section. It does not mention destructiveness or undo, which is acceptable 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 and front-loaded with the purpose. It provides educational content but is somewhat verbose. Every sentence adds value, though some musical theory could be condensed.
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 9 parameters, lack of output schema, and no annotations, the description provides good context for the rondo structure but fails to explain all parameters. It does not describe the return value or side effects. Adequate but with gaps.
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%. The description explains some parameters (key_root, scale_name, form_type, bars_per_section, track_index) but does not cover velocity, tempo_bpm, start_beat, or unit_index. This leaves several parameters unexplained, requiring the agent to rely on naming 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 clearly states 'Create a rondo' and provides a thorough explanation of what a rondo is, including form types, scale options, and structural details. It distinguishes this from many other create_* tools by focusing on the rondo form.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear and the description implies when to use this tool (when a rondo form is desired). However, it lacks explicit guidance on when not to use it or alternatives. The form type options provide some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully carries the burden. It discloses that the tool creates notes, uses MIDI pitches, and returns a breakdown of notes, type, and strokes. It explains the pattern's structure (open tones, slaps, etc.) and how parameters affect sound. However, it does not mention whether existing notes on the target track are cleared or if there are side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and includes structured parameter explanations and examples. It is somewhat verbose in explaining the musical pattern, but this adds contextual value. Overall, it is well-organized and 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 (9 parameters, no required params, no enums) and absence of annotations, the description provides substantial context about the tool's behavior and output. However, the missing parameter explanations for track_index and unit_index leave gaps. The output schema is mentioned but not detailed, though the description states return values.
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 explain parameters. It covers tumbao_type, bars, low_pitch, open_pitch, slap_pitch, and velocity with contextual meaning. However, it omits explanations for track_index, unit_index, and start_beat, which are critical for placement. This is 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 creates an Afro-Cuban tumbao (conga) pattern, a specific rhythmic foundation. It distinguishes from siblings by focusing on a particular conga pattern with subtypes like salsa, rumba, etc. The verb 'create' and resource 'tumbao' are precise.
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 tumbao types and their musical contexts (salsa, rumba, bolero) but does not explicitly state when to use this tool versus alternatives like create_clave or create_cascara. Usage is implied through musical terminology, but no direct comparison or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details exactly what is copied (instrument, effects, tracks, etc.) but does not mention side effects like whether the original remains unchanged or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions 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 bullet points, front-loaded with purpose, and each sentence adds value. 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?
Since an output schema exists, return values are covered. The description comprehensively lists what is duplicated but could mention that the original audio unit remains unchanged.
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%. The description only says 'unit_index: Source audio unit index to duplicate.' This adds minimal meaning beyond the schema, lacking explanation of range or 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 the tool duplicates an audio unit with all its content, listing specific elements copied. It distinguishes from sibling duplication tools like clone_clip or clone_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?
While the description implies duplication context, it does not explicitly state when to use this tool versus alternatives like duplicate_effect or duplicate_notes. No when-not or contrast is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some behavioral context (ZIP format, automatic extension) but does not state whether the operation is destructive, requires authentication, or has performance implications. The safety profile is 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 concise with three short sections: purpose, format explanation, and parameters. The first sentence is front-loaded. The Args section is slightly redundant but not excessive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 (one parameter) and existence of an output schema, the description covers the essential aspects: output format, parameter details, and return value. Lacks discussion of limitations or defaults, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains the 'filename' parameter meaning and notes the extension is appended automatically, adding clarity beyond the schema's default 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 the tool exports the current project as a .dawproject file, specifying verb, resource, and format. It distinguishes from sibling tools like export_midi and export_stems by highlighting cross-DAW compatibility.
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 interoperability with other DAWs but lacks explicit when-to-use or when-not-to-use guidance. No direct comparison with alternative export tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 library used, time division, and returns the file path. However, it does not state side effects, destructive nature, or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions 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, with a clear introductory statement, library detail, parameter list, and return value. 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?
Covers the essential functionality, parameters, and return value. Could mention error cases or required project state but is adequate for a straightforward export 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 adds clear meaning for all 4 parameters (filename without extension, unit_index, track_index, region_index). Fully compensates for missing schema docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Export a note region's notes as a standard MIDI file (.mid).' This is a specific verb and resource, and it distinguishes from siblings like import_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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives, nor any prerequisites or exclusions. The purpose is implied, but no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 explains the transposition invariance and output fields, but does not explicitly state that the tool is read-only (non-destructive) or describe failure conditions. For a read-only analysis tool, this is adequate but leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: opening verb-object statement, definition, use cases, parameter list, and output summary. Every sentence adds value with no redundancy or off-topic content. 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?
Given the tool has 7 parameters and an output schema (not shown), the description covers input parameters fully and outlines the output structure. It explains the motif concept and use cases. However, it could mention prerequisites (e.g., MIDI region must have notes) or limitations, but overall it is complete for an analysis 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 has 0% description coverage, so the parameter descriptions in the text are essential. Each parameter is explained with purpose and default values (e.g., 'min_motif_length: Minimum notes in a motif'). This adds significant meaning beyond the schema's names and defaults. However, details like the significance ordering of 'max_results' are not 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 clearly states the action ('Extract repeating melodic motifs from a MIDI region') and defines what a motif is via interval contour. It distinguishes from siblings like 'analyze_melody' and 'transcribe_melody' by focusing on patterns. However, it could be more explicit about which sibling to use for broader analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists specific use cases ('Essential for: understanding melodic structure...') that guide when to use the tool. It does not explicitly state when not to use it or compare with alternatives like 'extract_rhythm' or 'analyze_melody', but the use cases are clear enough for an informed decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the offline rendering, caching, playback from cache, and the specific function used. It also lists constraints and return type. It does not mention reversibility or side effects, but overall is informative.
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, starting with a summary, then technical detail, constraints, parameter, and return. It is concise but could trim some technical jargon. Each sentence 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?
Given the simple parameter and existence of an output schema, the description covers the tool's behavior, constraints, parameter, and return. It lacks error handling specifics but is generally 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 coverage is 0%, so the description must compensate. It explains 'unit_index: AU index to freeze.' This adds basic meaning but lacks specifics like range or how to obtain the index. Adequate for a 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 the purpose: 'Freeze an audio unit — pre-render its output offline to save CPU.' It uses a specific verb and resource, and explains the mechanism. The purpose is distinct from sibling tools like unfreeze_audiounit and get_unit_freeze_status.
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 constraints like 'Cannot freeze AUs with sidechain dependents or the Output unit.' However, it does not explicitly state when to use this tool versus alternatives, nor does it provide comprehensive usage context beyond constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds the list of returned fields and states it returns 'error' on failure, but lacks deeper behavioral details like error conditions or performance implications.
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 well-structured, starting with the purpose, then return fields, then parameter explanations. No unnecessary words, though the parameter descriptions are embedded in prose rather than 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 low complexity and presence of an output schema, the description adequately covers parameters, return values, and basic usage. Lacks detail on error handling but sufficient for a simple read 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?
With 0% schema description coverage, the description compensates by explaining all three parameters (unit_index, track_index, region_index) with clear definitions, adding significant 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 'Get metadata about the audio file referenced by an audio region' and lists specific return fields (file name, start/end time, sample loading state), distinguishing it from sibling tools like get_region_info or get_sample_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 mentions 'Useful for inspecting audio regions before processing,' providing some context but no explicit guidance on when to use this tool over 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description confirms read-only behavior. It adds value by specifying return structure, including default base signature, which is 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 concise with a clear first sentence and additional detail on return format. Slightly verbose with the second paragraph, but still 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?
Given no parameters and an output schema, the description fully describes the tool's return structure, including default base signature and event field 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?
No parameters exist, schema coverage is 100%, and the description correctly omits parameter details. No additional meaning 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 tool lists all time signature change events and mentions return fields. However, it does not differentiate from the sibling 'mcp_opendaw_list_signature_changes', which may have similar functionality.
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 'mcp_opendaw_list_signature_changes' or 'mcp_opendaw_change_base_signature'. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already indicates a safe read operation. The description adds no further behavioral context (e.g., error handling, side effects), but 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 extremely concise—two short sentences plus parameter clarifications. It's front-loaded with the main purpose and contains 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?
With an output schema present, the description is not required to detail return values, but it still mentions 'Returns track metadata and region/clip counts.' For a simple getter with two parameters, this 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?
Schema coverage is 0%, but the description explicitly explains both parameters: 'unit_index: AU index. track_index: Track index within the AU.' This adds essential meaning beyond the schema's type and title 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 clearly states 'Get detailed info about a track' and lists the info types (type, regions, clips, enabled state, target). This distinguishes it from sibling 'get' tools like get_region_info or get_audio_file_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 mention of when to use this tool vs alternatives, no prerequisites or exclusions provided. The description only states what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It describes the transformation and return count but does not mention whether the operation is destructive, reversible, or has side effects on 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 concise and well-structured, front-loading the purpose, then the formula, example, parameters, and return values without 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?
The description covers parameters, behavior, and return values well, but omits error conditions, limitations, and prerequisite knowledge (e.g., MIDI note numbers). Since an output schema exists, the return description is not essential but 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?
With 0% schema description coverage, the description fully explains each parameter: unit_index, track_index, region_index (with special -1 meaning), and axis (default 60, pivot pitch) with usage tips, adding significant meaning beyond 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 inverts a melody around a pitch axis via mirror reflection, providing a formula and example that distinguish it from sibling tools like transpose or reverse.
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 each parameter (unit, track, region, axis) and recommends using the first note's pitch for tonal inversion, but it does not explicitly guide when to choose inversion over alternatives or 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds scope (all audio file samples) and output details (UUIDs and metadata) beyond the readOnlyHint annotation. However, for a read-only list tool, the annotation already covers the safety profile, so the description adds modest value. No contradictions 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 two concise sentences, front-loaded with the main purpose. No redundant or extraneous 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 zero parameters and the existence of an output schema, the description adequately covers the tool's functionality. It mentions the return of UUIDs and metadata, which is complete for a list 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?
There are no parameters, and schema description coverage is 100% (empty properties). The description correctly implies no input needed, which is sufficient. Baseline 4 for 0 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 lists all audio file samples in the project and returns UUIDs and metadata. It uses a specific verb ('list') and resource ('audio file samples'), distinguishing it from sibling list tools that target other entities (e.g., list_notes, list_tracks).
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention when not to use it. It simply states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true. The description adds return structure (effects chain, volume, panning, region count) but no deeper behavioral traits like performance or 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?
Two concise sentences. First states action and scope, second details return structure. No wasted words, 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 list tool with output schema, the description sufficiently outlines returned data (audio units, tracks, effects, volume, panning, region count).
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?
No parameters exist, so schema coverage is 100%. Baseline for zero params is 4; description adds no param info but doesn't need 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 clearly states 'List all tracks across all audio units' with specific info returned: type, effects, regions. It distinguishes from other list_* siblings by focusing on tracks across units.
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 list_notes or list_effects. No exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries burden. It mentions full state restoration and engine restart but does not disclose whether loading overwrites unsaved changes or other side effects, leaving gaps.
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?
Description is reasonably concise but mixes purpose, usage, parameter info, and return value in a somewhat scattered order. Could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the return note is acceptable, but missing details on error handling (file not found) and impact on running engine make it less 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?
With 0% schema coverage, the description adds crucial context: filename is just the name (no path) and file is in exports directory. This goes beyond the schema's type/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 loads a previously saved .odaw file and restores the full project state, distinguishing it from create, save, or export tools among many 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?
Explicitly instructs the engine must be restarted after loading and specifies file location (exports directory, no path). Lacks comparison to import tools or warning about data loss, but provides good context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 does not disclose behavior when no operation is available for redo, or any side effects. Transparency is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It is appropriately 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?
Given the tool's simplicity and presence of output schema, the description is complete enough but could elaborate on the redo stack behavior or whether multiple redos are supported.
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?
No parameters exist (0 params), so schema coverage is 100%. Baseline is 4; description adds no param-related meaning, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 redoes the last undone operation. It uses a specific verb ('Redo') and resource ('last undone operation'). Among siblings like mcp_opendaw_undo, it is clearly distinguished.
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 provide explicit guidance on when to use this tool versus alternatives like undo. It implies usage after undo but lacks explicit context or when-not conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions side effect: 'All connections to/from this module are also removed.' No annotations provided, so description carries burden. Doesn't detail error cases, undoability, or impact on other modules.
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?
Concise at 6 lines, front-loading purpose then parameters, return, side effect. Could be more structured (e.g., separate paragraphs), but 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?
Covers purpose, parameters, and a key side effect. Output schema exists (not shown) but description mentions return. Lacks details on failure modes and preconditions, but adequate for a simple removal.
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 description provides brief explanations for all three parameters (au_index, effect_index, module_index), adding meaning beyond bare 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?
Clearly states 'Remove a module from a Modular device.' Uses specific verb (remove) and resource (module from Modular device), distinguishing it from sibling tools like add_modular_module and list_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?
Does not explicitly state when to use or when not to use this tool. Implies usage when removal is desired but lacks alternatives or prerequisites like device existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds the list of parameters reset but does not elaborate on side effects or reversibility. It adds minimal extra 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 sentences, front-loaded with the main action, and efficiently lists parameters. No redundant or extraneous 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 output schema exists, the description doesn't need to explain return values. It adequately covers what the tool does and the required parameters. It could be slightly improved by explicitly stating it resets all playfield parameters of the sample, but it is still 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?
The input schema has 0% description coverage, but the description fully explains both parameters (unit_index and sample_index) with clear purpose. This compensates completely 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 resets all parameters of a Playfield drum sample to defaults and lists the specific parameters affected (mute, solo, etc.). It distinguishes the tool from siblings by specifying the reset action on a sample's playfield.
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 setting individual parameters. The description does not mention when a reset is appropriate or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It notes that effect_index must refer to a Crusher, which is a key constraint. However, it does not disclose behavioral aspects such as permissions, side effects, or whether the change is immediate, leaving some uncertainty about 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.
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 bullet-point parameter explanations. Every sentence is meaningful, with no filler. The purpose is front-loaded, and the parameter details are clearly separated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 parameter setter with an output schema (though unseen), the description is nearly complete. It explains all parameters and the constraint on effect_index. The only minor gap is that it doesn't state the tool modifies state or is a write operation, but this is implicit in 'set'. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to all three parameters beyond the empty schema (0% coverage). It explains unit_index as 'AU index', effect_index as 'Effect index in the audio effect chain (must be a Crusher)', and bits as 'Bit depth (1-16, where 16=no crushing, 1=extreme)'. 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?
Clearly states 'Set the bit depth on a Crusher (bitcrusher) effect.' This is a specific verb+resource combination that correctly identifies a distinct parameter adjustment among many set_ tools, making it easy for an agent to select it for bit depth control.
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 does not provide any guidance on when to use this tool versus alternatives like 'set_crusher_crush' or other effect parameter setters. An agent would have no context about preferences or prerequisites beyond the implicit requirement of a Crusher effect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds useful context: crush is inverted internally, and gives sound quality ranges. However, it does not disclose side effects, undo behavior, or permission requirements, leaving 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 structured with a clear main sentence, bullet points for parameters, and a value mapping. Every sentence is informative with no redundancy or 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 simple parameter-setting nature and existence of an output schema, the description covers parameter semantics and behavioral quirk (inverted crush). It lacks only minor context about return values, but overall is fairly 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 by explaining each parameter: unit_index, effect_index, and the crush mapping from 0.0 to 1.0 with concrete sonic examples. 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 clearly states the tool sets sample-rate reduction (crush) on a Crusher effect, specifying the effect type and the verb 'set' with a clear resource. It distinguishes from siblings like set_crusher_bits by focusing on crush specifically.
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 on when to use this tool versus alternatives. The description provides value mappings but does not discuss prerequisites, when not to use it, or alternative tools for similar effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially explains behavior via parameter details (e.g., 'None = leave unchanged'), but does not disclose whether changes are immediate, reversible, or global vs per-project. It provides some transparency beyond schema but lacks full 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?
Extremely concise: one sentence for purpose, then parameter list. Front-loaded with 'Configure the metronome settings.' No superfluous words or repetition. 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 3 optional parameters and an output schema (not shown), the description covers input semantics thoroughly. It could mention that metronome is a project-level setting, but not essential. The parameter descriptions make the tool usable 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 coverage is 0%, so description fully compensates. Each parameter is explained with type, range, default, and behavior when None. For example, 'gain: Click volume 0.0-1.0 (default 0.5)' and 'beat_subdivision: Beats per click (1=quarter, 2=eighths, ... default 4)'. This 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 clearly states 'Configure the metronome settings' with specific verb and resource. Among sibling tools like set_bpm and set_time_signature, this is distinctly about metronome settings, differentiating it well.
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 on when to use this tool versus alternatives. It does not indicate prerequisites, context (e.g., before playback), or when not to use it. The description only states what it does.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains basic effect (looping, disable with 0) but omits side effects, error conditions, or destructiveness. Adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, with a clear logical flow: purpose, concept explanation, then parameter list. No wasted words, though more structured formatting could improve scannability.
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 exists, so return values are covered. Lacks information on prerequisites (e.g., region must exist), error handling, or success criteria. Adequate for typical use but incomplete for 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?
All 6 parameters are explained with clear examples and constraints (e.g., loop_beats = 0 disables loop, unit_index = -1 searches all AUs). Since schema descriptions are absent, 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?
Clearly states 'Set loop parameters for a note region', distinguishing it from the sibling 'set_loop_region' which likely handles global project loops. The verb+resource is specific.
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 context on looping behavior but lacks explicit when-to-use or when-not-to-use compared to siblings like 'set_loop_region'. No guidance on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially covers behavior: returns count of transposed/skipped notes, scopes via -1 values. However, it omits side effects, authorization, or performance implications. For a mutation tool, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions 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 paragraphs. The first states action, the second lists parameters with one line each. No redundancy, highly 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 4-parameter tool with no annotations and no output schema described, the description covers action, parameters, and return value. It lacks usage guidelines and deeper behavioral context, but is still fairly complete for the given 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?
Despite 0% schema coverage, the description explains all 4 parameters with clear semantics: semitones direction/example, unit_index/track_index/region_index meaning of -1. This adds significant value beyond the schema's bare type 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 'Transpose all notes by a number of semitones,' specifying the verb (transpose) and resource (notes). The sibling tool 'diatonic_transpose_notes' implies this is a chromatic transposition, distinguishing it 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 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 siblings or other transpose tools. It does not mention alternative approaches, when not to use, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 states the tool adds a marker but does not disclose side effects, limits on number of markers, or whether the operation is reversible. The basic additive nature is conveyed, but more detail could be 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 three sentences, front-loaded with the primary action, and no extraneous 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 simplicity of the tool and the presence of an output schema (unseen but declared), the description covers purpose, parameters, and visibility. It lacks project context, but that is common across sibling tools and not critical for this operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), but the description fully explains both parameters: 'position_beats' as position in beats and 'label' with examples. This adds significant 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 'Add a timeline marker at a position' with a specific verb and resource. It explains the purpose of markers (label song structure points) and visibility. Among siblings like set_marker_label and delete_marker, this tool is uniquely 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adding markers but does not explicitly state when to use this tool versus alternatives (e.g., updating or deleting markers). It lacks guidelines on prerequisites such as having a project open.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 it creates a new independent copy when shared, which is good. However, it does not mention undo behavior, performance implications, or whether calling on a non-mirrored clip is safe.
Agents need to know what a tool does to the world before calling it. Descriptions 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 title sentence, a conditional explanation, a parameter list, and a return note. 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.
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 simple parameter structure, the description is mostly complete. It covers the core behavior and parameter roles, but could mention prerequisites (e.g., clip existence) and whether the tool has effect on non-mirrored clips.
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% description coverage, so the description must compensate. It provides brief descriptions for each parameter (unit_index, track_index, clip_index), but they are minimal and assume domain knowledge (e.g., 'AU index' is not explained). More detail would help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 consolidates a clip's event collection to make it unique, not shared/mirrored. It uses a specific verb (consolidate) and resource (clip's event collection). This distinguishes it from sibling tools like clone_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 explains when to use (when clip shares events with others and you want independent edits). It provides clear context but does not explicitly mention when not to use or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states that the sample is duplicated with all listed parameters and returns success or error. However, it does not specify whether overwriting an existing target_index is allowed, whether the target slot must be empty, or any constraints like index bounds. This leaves gaps in understanding the tool's exact 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, starting with the core purpose, then listing duplicated parameters, then parameter explanations. Every sentence provides value without redundancy. It is well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple copy operation with 3 integer parameters, the description covers the essential behavior, parameter meanings, and return type. It lacks details on error cases (e.g., out-of-range indices) but is otherwise complete given the tool's complexity. The presence of an output schema (not shown) reduces the need to describe return values in detail.
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 clearly explains each parameter: unit_index (AU containing Playfield), sample_index (source slot), target_index (destination slot). This adds meaning beyond mere integer types, making it clear what each value represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 copies a Playfield sample to a new index slot, duplicating all parameters. It uses a specific verb (copy) and resource (Playfield sample), distinguishing it from sibling tools like copy_notes_to_track 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 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 duplicate a sample with all its parameters to a new slot, but it does not explicitly state when to use this tool versus alternatives or provide any when-not guidance. Among many copy-related siblings, it relies on the name for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks disclosure of side effects, idempotency, or performance. Only mentions return value, not behavioral traits like whether it is destructive or requires specific permissions.
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?
Well-structured: purpose statement, then parameter details. Slightly verbose but each sentence adds value. Example and lists are clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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, parameters, and return value. Mentions output format briefly. Given no annotations and an output schema exists, the description is sufficiently complete 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?
Detailed explanation of all parameters with valid values, examples, and defaults. Compensates for 0% schema coverage by providing full semantic context for 'chords', 'start_beat', 'unit_index', 'track_index', and 'chord_duration'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 verb+resource: 'Create a chord progression from chord names'. Distinguishes from siblings by emphasizing efficiency: 'one call instead of 15-50 note creations'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 batch advantage over individual note creation. Provides context for when to use, though no direct exclusion or alternative mention beyond the implicit alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It mentions the return value ('notes created, gong layer breakdown, and cycle info') but does not explain side effects such as whether existing notes are modified, which track is affected, or what happens on parameter failure. The description provides useful context but omits important behavioral details.
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, starting with a clear purpose, then background, detailed structure definitions, and a parameter list. Each section earns its place, though it is somewhat lengthy. It is front-loaded with the most important information (purpose and differentiation) and remains focused.
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 10 parameters and no output schema. The description covers return values vaguely ('notes created, gong layer breakdown') but does not specify the exact format or how the tool integrates with the DAW project (e.g., whether it adds to an existing track or creates a new one). It also assumes familiarity with gamelan terminology, which may not be sufficient for all agents.
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' list that adds meaning beyond the schema titles and defaults. For example, it specifies that 'cycles' ranges 1-8, 'octave' 2-5, and defines the allowed structures (slendro, pelog, lancaran, ketawang). This significantly 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 a colotomic structure — interlocking gong layers marking cyclic time,' clearly stating the specific verb and resource. It distinguishes this tool from siblings like 'create_polyrhythm' by explaining how colotomic structures are hierarchical and nested, unlike polyrhythm or additive 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 contrasts colotomic structure with polyrhythm and additive rhythm, helping the agent choose when to use this tool over conceptual alternatives. However, it does not explicitly name sibling tools like 'create_polyrhythm' or 'create_additive_rhythm' as alternatives, leaving the guidance somewhat implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes track behavior, rhythmic structure, and return value (notes per track and total). No annotations provided, so description carries full burden. Discloses half-time feel and pitch modulation but does not mention potential side effects like overwriting existing 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?
Front-loaded purpose, then details, then parameter list, then examples. Some repetition of BPM explanation. Well-organized but slightly verbose.
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?
Covers musical intent and main parameters with examples. Lacks explanation for velocity, start_beat, unit_index. No output schema but describes return value. Adequate for a genre arranger but with gaps.
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 description must compensate. Explains bpm, bars, root, octave, and track indices with musical rationale. Misses velocity, start_beat, unit_index. Provides examples. Partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'Create a full dubstep arrangement' with specific components (half-time drums, wobble bass, lead arp). Distinguishes from sibling genre arrangers by specifying dubstep and half-time feel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 this tool (creating dubstep arrangement with half-time feel). Implicitly contrasts with other electronic arrangements by emphasizing the genre-specific rhythm. Lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool creates MIDI notes on specified tracks with specific patterns, and returns a summary of notes created. It does not mention whether it overwrites existing tracks or layers, nor does it discuss permissions or side effects. Given no annotations, the description provides moderate behavioral context but lacks some details expected for a creative action.
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 the core purpose but becomes verbose with historical references (e.g., Clyde Stubblefield, Larry Graham) and extensive musical explanation. While informative, some sentences could be condensed without losing essential guidance for an AI 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?
Given the tool's complexity (11 parameters, no annotations), the description covers the musical concept, parameter meanings (most), and return value. It lacks descriptions for two parameters and assumes familiarity with DAW conventions. Nevertheless, it is sufficiently complete for an agent to understand and 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 coverage is 0%, so the description bears full responsibility for explaining parameters. It describes most parameters (bpm, bars, root, octave, unit_index, track indices) with constraints and musical meaning (e.g., 'classic funk pocket' for 100 BPM). However, it omits 'velocity' and 'start_beat', leaving their semantics unclear. 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 'Create a full funk arrangement' and details the four tracks (drums, bass, guitar, horns). It distinguishes itself from other arrangement tools by emphasizing the vamp-based approach, contrasting with chord-progression-based styles. The verb 'create' and specific resource 'funk arrangement' make the purpose unambiguous and distinct 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 explains that this tool is for funk arrangements and contrasts it with pop/rock/jazz by stating 'vamp-based, not chord-progression-based'. This implicitly tells the agent when to use this tool (for funk) and when not (for other genres). However, it does not explicitly list exclusion criteria or provide alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It explains that the bass pattern repeats and the melody develops per cycle, and details melody_styles. However, it omits side effects (e.g., overwriting existing notes), error conditions, or required track state. For a creative tool, this is adequate 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured but somewhat verbose, especially the historical background and detailed melody_style descriptions. While informative, it could be more concise for an AI agent. However, it front-loads the purpose and uses clear sectioning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 presence of an output schema, the description covers the main aspects: what it creates, how to use parameters, and what is returned. It does not discuss edge cases or error handling, but it provides sufficient context for typical 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 compensates well. It explains each parameter in the 'Args:' section, including format for bass_pattern and bass_rhythm, range for repeats, and details for melody_style. It adds meaning beyond the schema titles and defaults, though some parameters like unit_index and track_index are only briefly mentioned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ground bass — a repeating ostinato bass line with optional melody.' It specifies the verb-action (create), the resource (ground bass), and distinguishes it from passacaglia by explaining the difference. This allows an agent to understand what the tool does and how it differs from siblings like create_passacaglia.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 a ground bass, provides historical context, and contrasts with passacaglia. It also lists melody_styles with detailed descriptions, guiding the agent's choice. However, it does not explicitly state when not to use this tool or provide alternatives for similar tools like create_ostinato.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Detailed description of musical output per track (drum pattern, bass walking, piano comping, horn melody). Discloses return value (notes per track and total). No annotations provided, so description carries full burden; however, it does not address potential side effects like overwriting existing data 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with track breakdown and parameter list, but verbose with detailed musical descriptions that could be shortened. Front-loaded with main purpose, so overall adequate but not maximally 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?
Given no annotations and low schema coverage, the description covers purpose, behavioral details per track, default settings, return value, and includes examples. Missing some parameter explanations (velocity, start_beat), but otherwise comprehensive for a complex arrangement 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?
Despite 0% schema description coverage, the description provides meaningful defaults and ranges for most parameters (bpm, bars, root, octave, track indices). Misses 'velocity' and 'start_beat', which weakens completeness, but still adds significant 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?
Clearly states it creates a full jazz arrangement with specific instrumentation (swing drums, walking bass, comping piano, horn). Emphasizes unique jazz features (swing feel, ii-V-I harmony) to distinguish from sibling genre-specific 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use (for jazz with swing feel and ii-V-I harmony) and contrasts with other arrangements. Implicitly guides via unique characteristics, but lacks explicit 'when not to use' or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 details per-track behavior per section (e.g., verse sparse, chorus full), BPM range, bar length, default values, and return type. However, it does not disclose whether it clears existing notes or modifies other 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 long but well-organized with bullet points and section breakdowns. It front-loads the purpose and provides high-density information. Slightly verbose but earns its length with musical theory and examples.
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 4-track arrangement with detailed patterns per section, the description is remarkably complete. It covers musical theory (I-V-vi-IV progression), section structure, BPM/bars defaults, and return format. Output schema exists, so return values are already defined.
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%, but the description explains bpm, bars, root, octave, and track indices inline. However, parameters like velocity, start_beat, and unit_index are not described, and schema already has defaults. Description partially compensates but leaves 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 clearly states it creates a full pop arrangement with verse-chorus-bridge structure across 4 tracks (drums, bass, chords, melody). It distinguishes itself from loop-based arrangements and other genre-specific arrangement tools in the sibling list. The verb 'create' and resource 'pop arrangement' 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is 'fundamentally different from all loop-based arrangements' implying use for pop song form, but it does not explicitly contrast with other arrangement tools (e.g., rock, jazz) or state when to use this vs alternatives. No guidance on prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 describes what is created (notes on three tracks) and mentions the return value. However, it doesn't clarify whether existing notes are cleared, prerequisites like track existence, or potential side effects, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured, starting with purpose, then track details, then parameter list, and examples. It is verbose but each sentence adds value, and examples aid understanding.
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 genre and track roles well, and mentions return values. However, it lacks details on prerequisites (e.g., track requirements), side effects, and two parameters are unexplained. With output schema present, return value explanation is not required but still helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds significant value by explaining 8 of 10 parameters (bpm, bars, root, octave, unit_index, track indices) with ranges, defaults, and context. It omits velocity and start_beat, which are minor 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 clearly states 'Create a full techno arrangement' and specifies the three tracks (drums, sub-bass drone, stabs), distinguishing it from siblings like create_house_arrangement by emphasizing techno-specific elements and the 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 provides context on when to use this tool (for techno) and contrasts with house music, offering implicit guidance. However, it doesn't explicitly list alternatives or when not to use it, which is acceptable given many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description confirms destructive behavior ('delete') and adds context about the value region and indices. However, it does not disclose side effects, prerequisites, or undo support, so it adds moderate 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 very concise: four sentences total, with the purpose front-loaded and parameter explanations following. No superfluous 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 action, parameters, and return type (success or error). It does not discuss prerequisites, error conditions, or behavior with invalid indices, but given the output schema exists and the tool is part of a larger set, it is reasonably complete for a delete 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 description coverage is 0%, so the description must compensate. It provides meaningful explanations for all three parameters (unit_index, track_index, event_index), describing their roles and context (e.g., 'Track index within the unit (automation track)'). This adds value beyond the schema 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 clearly states it deletes a single automation event (ValueEventBox). It specifies the exact resource type and action, and the sibling tools include create, update, duplicate, list, and move automation events, so the purpose is well-distinguished.
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 provide explicit guidance on when to use this tool versus alternatives like delete_audio_region or delete_note. Usage is implied by the tool name and context (automation events), but no when-not or comparative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides details beyond the destructiveHint annotation: it clarifies that deletion uses closest match by position and explains the -1 special values for index and position_beats.
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 reasonably concise but contains some redundancy (e.g., the initial line and then parameter explanations). Could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 the two parameter usage, mentions the return value (updated signature event list), and handles the edge case of deleting the last event. Missing error cases, but sufficiently complete for a simple delete 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?
Since the input schema has no parameter descriptions, the tool description adds crucial semantics: it defines position_beats as the position to match and index as 0-based index, including the special -1 case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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' with a specific verb and resource, and it distinctively separates from siblings like add_signature_change or move_signature_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?
It explains two deletion modes (by position or by index) and notes the special case for deleting the last event, but lacks explicit guidance on when to choose one mode over the other or comparison with alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so the description carries full burden. It discloses that it uses PresetEncoder.encodeEffects and returns base64 bytes or error, but does not explicitly state that the operation is non-destructive or read-only. The behavioral transparency is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions 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: three sentences plus parameter explanations, front-loading the purpose. No redundant information; 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 2 parameters, no annotations, and an output schema, the description covers the return value (base64 preset bytes), the internal encoder, and forward reference to import_effect_chain. It omits context about the AU (likely an audio unit/device), but is otherwise 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 unit_index (AU index to export from) and effect_type (audio or MIDI, with default 'audio'). It adds meaning beyond the schema but lacks indexing convention (e.g., 0-based or 1-based).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 an effect chain as a base64 preset. It distinguishes from siblings like export_preset (exports a single preset) and import_effect_chain (imports), specifying audio or MIDI chains.
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 mentions the preset can be imported via import_effect_chain, hinting at a use case. However, it does not explicitly say when to use this over alternatives like clone_effect_chain or export_preset, nor does it provide 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.
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 states that the stem includes the effect chain but does not disclose whether the operation is destructive, requires specific permissions, or any side effects (e.g., file overwrite, format details). 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 front-loaded with the main purpose, followed by a concise sibling comparison, a parameter list, and a final note on the effect chain. Every sentence adds value, and the structure is clean with line breaks.
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 adequately explains input parameters and the effect chain inclusion but lacks details about the output (e.g., bit depth, channels, file location, overwrite behavior). Given that an output schema exists (per context), some of this may be covered there, making the description minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 (must be >0, not output AU), filename (output filename), sample_rate (export sample rate). This adds critical constraints and purpose beyond the schema's type-only 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 the verb 'export', resource 'single audio unit', and format 'stem WAV with its effect chain applied'. It explicitly distinguishes from sibling 'export_stems' by contrasting scope (single vs all) and use case ('faster when you only need a specific stem').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 (when you need one stem) and explicitly contrasts with the sibling 'export_stems'. However, it does not include exclusions or prerequisites, such as whether the AU must be enabled or if the file will be overwritten.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description explains algorithm steps but omits critical behavioral details such as whether the tool overwrites existing notes on the target track, idempotency, or required permissions. Agent cannot assess 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?
Well-structured with summary, parameter breakdown, algorithm steps, and examples. Front-loaded with purpose. Slightly verbose in the algorithm section but each part is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Explains parameters, algorithm, and expected output. Lacks clarity on whether melody is appended or replaces existing notes, and prerequisites (e.g., must have a valid track). Output schema exists but description only lists returned fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero description coverage, but the description fully explains all 11 parameters with musical context (e.g., contour shapes, rhythm styles), algorithm details, and three examples. Adds high value beyond schema 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?
Clearly states 'Generate a melodic line from a scale using contour-guided random selection.' Differentiates from sibling melody tools by emphasizing no chord progression needed and specific contour/rhythm 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?
Explicitly says 'no chord progression needed' and provides musical character for each contour/rhythm option. However, lacks explicit comparison to alternatives like create_melody or create_melody_from_progression, and does not specify when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds value by listing specific return fields (min_pitch, max_pitch, max_duration_beats, note_count) and error possibility, confirming no 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 (3 sentences plus parameter definitions) with a clear structure: action, returns, then parameter list. No redundant information; 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?
Given the tool's low complexity (3 simple parameters, an existing output schema hinted by 'Returns'), the description covers the purpose, return values, and parameter meanings completely. The mention of 'or error' handles edge 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?
With 0% schema description coverage, the description compensates by providing a brief explanation for each of the 3 parameters: unit_index, track_index, region_index. This adds meaning beyond the schema's type-only 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 it gets pitch range and max duration of notes in a note region, specifying return values (min pitch, max pitch, longest note duration) and use cases. It distinguishes from siblings by focusing on range rather than listing all notes or statistics, but 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context for use: 'useful for determining the vocal/instrument range and planning transpose operations.' However, it does not specify when not to use this tool versus similar ones like list_notes or note_stats, nor does it mention prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating a safe read operation. The description adds that it 'account[s] for tempo automation' and returns 'BPM at that position, or error,' which provides some behavioral context beyond annotations but does not cover edge cases or state dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions 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), front-loads the core purpose, and every sentence adds necessary 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?
For a simple getter with one parameter and an output schema, the description covers the essential input and output. It could briefly mention position validity (e.g., within project range) but is otherwise 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?
With 0% schema description coverage, the parameter description ('position_beats: Position in beats (float)') meaningfully adds units and type information that the schema lacks, helping the agent understand the expected input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 action ('Get the BPM at a specific position') and the resource ('BPM'), and distinguishes itself by accounting for tempo automation, which differentiates it from sibling tools like mcp_opendaw_get_project_info or mcp_opendaw_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 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 BPM at a specific position considering automation) but does not explicitly mention alternatives or when not to use it. The context is adequate but lacks clear exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds minimal behavioral context beyond stating it lists connections and returns source/target info. It does not detail permissions, side effects, or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions 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 for parameters and one for output. Every line adds value 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?
Given the simple read-only nature and presence of an output schema, the description covers the core purpose and parameter semantics. It lacks error scenarios or what happens with invalid indices, but is sufficient for basic 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 description must explain parameters. It does: 'au_index: Audio unit index. effect_index: Effect index within the AU.' This adds meaning beyond the bare schema, though it lacks format or boundary 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 'List all connections (patch cables) in a Modular device.' with a specific verb and resource. It distinguishes itself from sibling tools like 'connect_modular_modules' (write) and 'list_modular_devices' (list devices).
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. It implies use for inspecting connections before connecting, but provides no exclusions or context for selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, so the agent knows it's a safe read operation. The description adds detail on the specific fields returned (type, label, x/y, inputs, outputs, parameter values) and known module types, providing behavioral context beyond annotations. 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?
The description is concise and well-structured: a single-sentence purpose, then parameter descriptions, then return fields and types. Every sentence adds value, and key 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?
The tool has an output schema, so return values are documented elsewhere. The description adds context about module types and the kind of data returned. It could mention error cases or prerequisites (e.g., device must be a Modular device), but overall is fairly complete for a listing 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 compensate. It explains 'au_index' as 'Audio unit index' and 'effect_index' as 'Effect index within the AU', adding meaning beyond the schema's generic titles. However, it does not specify how to obtain these indices (e.g., via list_modular_devices).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'List' and resource 'modules in a Modular device'. It specifies what is returned (type, label, x/y position, inputs, outputs, parameter values) and lists module types. This distinguishes it from siblings like 'list_modular_devices' and '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 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 (e.g., 'list_modular_devices', 'add_modular_module'). It does not mention prerequisites or exclusions, leaving the agent to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, confirming safe read. Description adds context about normalized values and mapping, but doesn't disclose potential limitations (e.g., event count, performance). Incremental value beyond annotations is moderate.
Agents need to know what a tool does to the world before 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 precise sentences, front-loaded with action and resource, no redundancy. 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 no parameters and presence of output schema, description provides necessary detail (returned fields, mapping). Could mention ordering or scope (entire project), but sufficient for a simple list 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?
No parameters exist; schema coverage is 100% by default. Description explains output fields and mapping, adding value beyond schema. Baseline 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?
Description clearly states it lists tempo changes on the timeline's tempo track, specifying returned data (position, BPM, interpolation type). Distinguishes from siblings like add_tempo_change (write) and get_tempo_at (single point).
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?
Implicitly indicates usage for retrieving existing tempo events, but no explicit guidance on when to use vs alternatives (e.g., get_tempo_at, list_signature_changes). Lacks when-not-to-use or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals internal details (reads bundle, decodes via PresetDecoder, inserts onto unit), which is helpful. However, it does not specify whether the insertion replaces or appends existing effects, or mention potential side effects like silencing the unit temporarily.
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 core purpose, followed by internal detail and parameter explanations. It is structured logically, though it could be slightly more terse by removing the internal mechanism 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?
Given that an output schema exists (context signals indicate present), the description does not need to detail return values. It covers the essential functionality but could be improved by noting potential error conditions (e.g., invalid file path, incompatible preset format).
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 by explaining both parameters: filepath is 'Path to the .opb preset bundle file' and unit_index is 'Target audio unit index. -1 = primary instrument unit.' This adds meaningful context beyond the schema's type/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 action ('load a .opb preset file' and 'apply it to an audio unit') and the resource (effect preset for audio unit). The tool name itself reinforces this, and the description distinguishes it from siblings by specifying the file format and target.
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 specific usage hint for the unit_index parameter (use -1 for primary unit), but does not explicitly state when to use this tool versus alternatives like import_preset or replace_from_preset. No exclusions or comparative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool moves an event and returns old and new positions, but does not mention reversibility, constraints, or side effects. Basic but sufficient for a simple move 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?
Extremely concise: one sentence for purpose, then bullet-like parameter descriptions. No extraneous text, front-loaded with the 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?
Covers the core purpose, parameters, and return value. With an output schema present, it need not detail return structure. Lacks behavioral depth but adequate for a simple 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 description must compensate. It explains all four parameters (unit_index, track_index, event_index, new_position_beats) with brief descriptions and notes that event_index comes from list_automation_events. Provides enough meaning for an agent to guess 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 action (Move) and resource (automation event) on the timeline. It distinguishes from siblings like move_notes or move_region_content by specifying 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 by referencing list_automation_events that prior listing is needed, but does not explicitly state when to use this tool versus alternatives like move_notes or move_region. No exclusions or alternative guidance provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Does not disclose side effects, state changes, reversibility, or error conditions. Only describes parameters and basic function.
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?
Well-structured with purpose statement, sibling contrast, and parameter block. Distribution mode descriptions are slightly verbose but overall efficient. Front-loaded with key 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 9 parameters, no annotations, and existing output schema, the description covers tool function and parameters well. Missing behavioral context but otherwise complete for parameter and usage understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description provides extensive parameter documentation with explanations, defaults, and examples for variation, distribution, min/max durations, and preserve_total. Fully compensates 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?
Clear verb 'randomize' and resource 'note durations' with explicit differentiation from 'humanize_notes' (which adjusts timing+velocity). Lists 5 distribution modes for musical character, making purpose specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'adds generative variation to note lengths' and contrasts with humanize_notes, providing context for when to use. However, does not mention other sibling tools like randomize_note_chance or explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description outlines the three steps (render, analyze, return) and mentions offline engine, LUFS, spectrum, stereo, dynamics, and suggestions. With no annotations, it partially transparent but lacks disclosure on file persistence, permissions, or side effects of rendering to WAV.
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, numbered list, parameter section, and example. It is front-loaded and clear, though slightly repetitive (e.g., 'feedback loop' appears twice) and could be trimmed.
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 and lack of annotations, the description covers core functionality, parameters, and return structure. It lacks details on file location/persistence, error scenarios, and prerequisites, leaving gaps for an agent to infer.
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 coverage, the description adds meaningful explanations for all three parameters: filename extension, recommended sample rate, and analysis depth options. It does not provide constraints or enums explicitly but compensates well through descriptive text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 that the tool renders the project and runs full audio analysis in one call. It distinguishes itself from siblings by explicitly combining export_audio and analyze_mix, making its purpose as a feedback loop for iterative mixing 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 indicates the tool is the 'ears' tool for verifying mix changes, implying usage after adjustments. It mentions it combines export and analysis, hinting that standalone tools exist for separate tasks. However, it does not provide explicit when-not-to-use scenarios or enumerate alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. It states 'Returns success or error' and describes the action, but does not disclose potential side effects (e.g., overwriting previous label, impact on mixer states). Behavior is not hidden but also not 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 concise (4 lines), front-loaded with the main purpose, and each sentence contributes without redundancy. It efficiently covers the action, parameters, and return behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 essentials: what it does, parameters, and return type. It could mention prerequisites (e.g., bus must exist) but overall is complete given the tool's simplicity. There is an output schema, but the description's mention of 'success or error' suffices.
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 adds significant meaning: it specifies the origin of 'bus_index' (from create_audio_bus) and gives examples for 'label'. This 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 the tool sets the label of an audio bus, using a specific verb ('Set') and resource ('label of audio bus'). It distinguishes from siblings like 'set_bus_color' or 'set_bus_enabled' by focusing on the naming aspect.
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 (to rename a bus) but does not explicitly provide when-not-to-use or alternatives. It assumes the agent knows bus indices from a preceding call to 'create_audio_bus', which is helpful but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description covers the write operation but does not mention error conditions, return value, or prerequisites (e.g., effect existence). With no annotations, more transparency is expected.
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?
Well-structured with a clear opening, parameter list, and examples. Could be slightly more concise but examples are helpful.
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?
Covers input well but does not mention output or error handling. Output schema exists but not described. Lacks discussion of side effects or prerequisites.
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 description explains each parameter meaningfully, including examples and special cases for string values. 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?
Description clearly states 'Set a parameter on an audio effect' and specifies indices and parameter names. Examples differentiate from typed siblings like set_effect_parameter_bool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains parameters, references list_effect_parameters for names, and provides examples. Includes special case for string params via parameter_name='equation'. Could be more explicit about when to use this vs typed variants.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 parameter values and their meanings but omits potential side effects, reversibility, or error conditions. Adequate 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?
Extremely concise: two sentences plus parameter list. Front-loaded with purpose, no filler 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?
For a simple setter with 3 parameters and an output schema, the description is nearly complete. It covers what the tool does, parameter meanings, and accepted values. Minor lack of error handling info.
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 well by explaining each parameter: unit_index, effect_index, and oversampling with value mapping (0=off, 1=2x, 2=4x). Adds significant meaning beyond 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 sets the oversampling level on a Fold (wavefolding) effect, using specific verb+resource. It distinguishes from sibling set_* tools by specifying the effect type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should only be used when the effect is a Fold, but lacks explicit guidance on when to use vs alternatives or when not to use. The constraint 'must be a Fold' provides some direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 tool 'Returns old and new values' and explains the unit_index and param_index behaviors. However, it does not mention side effects, error conditions (e.g., if param_name is invalid), or whether changes are immediate or require rendering. The disclosure 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence stating the purpose, followed by a bullet-style list of parameter explanations. Every sentence adds value, and the structure is front-loaded with the main action. 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 has 4 required parameters and an output schema (not shown), the description explains the purpose, parameter meanings, and that it returns old and new values. It could be more thorough about prerequisites (e.g., requiring an audio unit with an instrument) and error handling, but it is largely complete for common 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 input schema has 0% description coverage (only parameter titles). The description compensates by explaining each parameter: unit_index's special value -1, param_name as field name with examples, value as a number, and param_index as an alternative. It adds meaning beyond the schema, though it does not list all possible param_names or value 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 clearly states the verb 'Set' and the resource 'parameter on the instrument connected to an audio unit.' It lists the parameters with explanations, and distinguishes from sibling tools like set_effect_parameter by specifying 'instrument' and 'audio unit.' The tool name also reinforces 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the unit_index special value -1 for auto-detection and the alternative param_index versus param_name. However, it does not explicitly state when to use this tool versus alternative parameter-setting tools (e.g., set_effect_parameter, set_midi_effect_param). The context is implied but not formally contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 parameter range and that it 'Returns success with old and new values', but does not mention side effects, persistence, or scope (global vs per-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 extremely concise with two sentences. It front-loads the action and includes only essential 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?
For a simple setter tool with an output schema, the description is fairly complete. It explains the parameter and return value. However, it could mention whether the zoom is global or per-track, or if any visual feedback occurs.
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 single parameter 'scale' is fully explained in the description with its range (0.5 to 2.0) and meaning of default and extremes. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Set the piano roll note scale (vertical zoom)'. It uses a specific verb-resource pair and distinguishes from siblings like set_piano_keyboard and set_piano_note_labels.
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 adjusting zoom but does not explicitly state when to use this tool versus alternatives (e.g., other piano roll settings). No exclusion criteria or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description effectively discloses behavior: it sets hue, returns old/new values, and explains parameters including special value for unit_index. Does not mention side effects beyond mutation, but covers core behavior well.
Agents need to know what a tool does to the world before 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 clear paragraphs: purpose/example first, then parameter details. No redundancy, every sentence is informative 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?
Covers input semantics, special values, returns old/new hue. Output schema exists, so last line suffices. Complete for a simple setter 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?
All four parameters are explained with meaning: track_index, region_index (0-based), hue (0-360 with color mapping), unit_index (-1 searches all AUs). Schema has 0% description coverage, so description adds significant value.
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?
Clearly states it sets the hue of a region/clip, explains hue as HSL 0-360, and gives color examples. However, it does not explicitly differentiate from sibling tools like set_clip_hue or set_bus_color, though the name is self-explanatory.
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 usage example ('red for choruses, blue for verses'), but no explicit when-to-use or when-not-to-use guidance, nor alternatives mentioned. Sibling set_clip_hue exists but is not contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 effect_index must point to a Vocoder effect but does not mention immediate effects, reversibility, or return values. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short: two sentences plus a list of three parameters. It is front-loaded with the purpose and contains no unnecessary information. 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?
For a simple setter, it covers purpose, parameters, and typical values. It does not discuss error conditions or validation, but output schema exists so return values are handled. Minor gap: band_count values are not enforced by 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 coverage is 0%, so description compensates well. It explains each parameter: unit_index as AU index, effect_index as effect index (must be Vocoder), and band_count with typical values (8,16,24,32). This adds meaning beyond the integer type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set the band count on a Vocoder effect' and specifies the resource (Vocoder effect) and attribute (band count). It gives a typical range (8-32) and distinguishes from siblings like set_vocoder_modulator_source, which sets a different 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 implies usage by requiring a Vocoder effect but does not explicitly state when to use this tool versus alternatives. It lacks guidance on conditions 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.
Behavior3/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 that extensions are calculated from the chord root and returns pitch info, but lacks details on side effects, reversibility, or error handling. It adds context like potential clashes (11th with 3rd), which is helpful 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: one-line summary, conceptual explanation, detailed extension list with musical character, other parameters, return values, and examples. Every section adds value, though the extension list could be slightly condensed without losing 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 musical complexity and 7 parameters, the description covers purpose, parameter roles, and return values. It includes practical examples and educational content. However, it does not address edge cases like invalid chord_position or missing chord, which would improve 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?
Despite 0% schema description coverage, the description explains the most important parameters (extension, chord_position, octave, velocity) in detail with musical context. The index parameters are self-explanatory. This adds significant 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 it adds tension/extension notes to chords in a jazz harmony context. It uses specific verbs and resources, and the purpose is distinct from sibling tools like add_chord_progression or invert_chord_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 extensive guidance on when to use each extension type (e.g., 'most common jazz extension', 'dark, tense'), and gives examples for Cmaj9 and G7b13. However, it does not explicitly contrast with 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool creates three specific effects (Revamp EQ, Compressor, Maximizer) on the output/master AU and returns effect indices/parameter values. However, it doesn't clarify if it overwrites existing chains or is additive, nor any side effects or dependencies.
Agents need to know what a tool does to the world before calling it. Descriptions 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 begins with a clear action statement, then presents parameters in a readable bulleted list. Every sentence adds 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 presence of an output schema, the description adequately covers purpose, parameters, and result (effect indices and values). It lacks mention of prerequisites or whether the tool is additive, but overall is sufficient for a straightforward tool with two optional parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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. It explains target_lufs with concrete examples (-14, -16, -10) and lists four style options with detailed character descriptions. This adds significant meaning beyond the schema's bare type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Add a ready-made mastering chain to the output bus — EQ + compressor + maximizer in one call.' It uses a specific verb ('Add') and resource ('mastering chain to the output bus'), and distinguishes from sibling tools like add_bass_chain or add_drum_chain by specifying it targets the output bus.
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 naming (mastering chain for output bus) but lacks explicit guidance on when to use this tool versus alternatives like adding individual effects or other chains. No context on prerequisites (e.g., project state) or when not to use it (e.g., if a mastering chain already exists).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully informs behavior. It details per-genre humanization (timing variation, velocity, swing) and notes that it affects tracks (drum, bass, harmony, melody). It mentions returns, but not reversibility. Still, transparency is strong given the informative genre recipes.
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: purpose, context, detailed genre recipes, parameter list, and example. Each section serves a purpose, especially the genre recipes which are essential for correct use. Could be slightly more concise (e.g., table for genres), but overall earns 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?
Given the output schema exists and the description mentions returns, the description is fairly complete. It explains all 7 parameters, provides examples, and gives extensive genre context. Missing some nuance on track indices, but adequate for the tool's 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 lists parameters (genre, unit_index, drum_track, etc.) and explains genre values and their effects. However, it does not fully explain each track index's role beyond name and example, and 'unit_index' is only briefly described. Adding more detail would improve 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 clearly states the tool's purpose: 'Apply genre-aware humanization to arrangement tracks — makes programmed MIDI feel alive.' It uses specific verb (apply) and resource (genre humanization on arrangement tracks). It distinguishes from siblings like 'humanize_notes' by focusing on genre-aware, whole-arrangement humanization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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: after creating an arrangement when notes are 'perfectly quantized — robotic.' It provides genre-specific humanization recipes, implying context. However, it does not explicitly state when not to use or list alternatives among siblings, but the genre-awareness provides clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the iterative process (render, measure, adjust, re-render) and convergence tolerance (±1 LUFS), but lacks details on side effects like whether a Maximizer plugin is required or added, or if the project master is altered. Since no annotations are provided, the description carries the full burden but is somewhat incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions 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 (about 120 words), well-structured with an intro, process explanation, and parameter list. Every sentence adds value, and the purpose 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?
The description covers what the tool does, how it works, parameter details, and return values. It lacks information on prerequisites or side effects, but given the presence of an output schema, the return value listing is sufficient. Minor gaps 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 description individually explains each parameter with examples and defaults (e.g., target_lufs with common values, filename format, sample_rate default 48000, max_iterations default 3). Since schema_description_coverage is 0%, the description fully compensates and adds meaning beyond the schema's 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 purpose: 'Auto-adjust output volume to hit a target LUFS.' It specifies the iterative loop and target loudness standards, effectively distinguishing it from sibling tools like measure_lufs or render_and_analyze.
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 final loudness normalization but does not explicitly state when to use this tool versus alternatives. No exclusions or comparisons to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions that the tool returns file path and size or an error if the engine is not running. However, it does not disclose whether overwriting occurs, any permissions needed, maximum duration, or the source of the recording (e.g., master output). This is adequate but could be more thorough.
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 concise with three short paragraphs. It front-loads the purpose and then provides parameter details and return info. There is no fluff, but the second paragraph could be slightly streamlined as it partially repeats the first line. Overall 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's simplicity (2 parameters, no output schema but return value mentioned), the description covers the main aspects: what it does, prerequisite, parameters, and return. It does not mention potential overwrite behavior or recording source, but it is sufficient for the 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?
The input schema has 0% coverage, but the description explains both parameters: 'duration_seconds: How long to record (float, e.g. 10.0)' and 'filename: Output WAV filename (without extension).' This adds meaning beyond the schema by specifying the type, example, and that the extension should not be included. It could additionally mention allowed characters or default path, but it is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Capture realtime audio output from the DAW engine' with a specific verb and resource. It further explains that it records live audio for a given duration and is useful for capturing playback with effects and automation. This distinguishes it from sibling tools like export functions or 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 explicitly states a prerequisite: 'The engine must be running (call start_engine first).' It also provides context for when to use the tool ('useful for capturing live playback...'). However, it does not explicitly mention when not to use it or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains arpeggio generation, pattern cycling, and return values (chords, total notes, pattern). Does not mention side effects or limitations, but behavior is well-described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose statement, parameter descriptions, and examples. Reasonably concise for the level of detail, though some genre names repeat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 9 parameters, no annotations, and output schema exists, the description covers essential aspects: parameter explanations, examples, sibling differentiation. Return values are mentioned. Lacks details on start_beat and unit_index.
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 description must compensate. Describes key parameters (progression, pattern, octave, velocity, step_duration, track_index) with examples and allowed values. However, start_beat and unit_index are omitted, 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 clearly states the tool creates an arpeggiated chord progression and distinguishes it from create_arpeggio (single chord vs. full progression). Specific verb 'create' and resource 'arpeggiated chord progression' are used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 contrasts with create_arpeggio and gives genre-specific examples (synthwave, trance, house, pop). Provides clear context for when to use, though lacks 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that notes are created, returns notes created, breakbeat type, and stroke breakdown. It details pitch defaults, velocity adjustments per stroke, and examples. However, it does not mention whether it clears existing notes or requires a specific track 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 front-loaded with a clear purpose, then provides musical context, type details, parameter explanations, and examples. While somewhat lengthy, the structure is logical. A minor reduction in historical detail could improve conciseness without losing 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 (10 params, no annotations, output schema exists), the description is comprehensive. It covers breakbeat types, pitches, velocity, and return values. Missing explicit mention of start_beat and unit_index slightly reduces completeness, but overall it is well-rounded.
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 breakbeat_type with extensive details, describes pitch defaults, velocity behavior, and bars. Examples show track_index usage. However, parameters like start_beat and unit_index are not described, leaving some 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 clearly states 'Create a breakbeat pattern' and specifies it's 'the syncopated skeleton of jungle, DnB, big beat, and breakbeat hardcore.' It distinguishes from sibling tools that create other patterns (e.g., create_boom_bap, create_four_on_floor) by focusing on breakbeats and listing detailed 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 what breakbeats are and when they are used (e.g., jungle, DnB, big beat). However, it does not explicitly state when not to use this tool or compare it to alternatives like create_drum_pattern or create_boom_bap. The guidance is implicit through the type descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 high/low stroke pitches are used, velocity adjustments, and return values (notes created, type, direction). It does not mention destructive actions or permissions, but covers key 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 front-loaded with purpose and musical context, then details each parameter and type, ending with examples. It is somewhat lengthy but every sentence adds value. Minor redundancy in explaining the three pillars.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 (8 parameters, musical pattern) and absent schema descriptions, the description is comprehensive about musical intent and parameter effects. It covers return values and includes examples. Missing details on positional parameters like start_beat 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?
Schema coverage is 0%, so the description must compensate. It explains cascara_type, bars, high_pitch, low_pitch, and velocity in detail, including stroke patterns and velocity offsets. However, start_beat, unit_index, and track_index are not described, 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 clearly states it creates an Afro-Cuban cáscara pattern. It explains what cáscara is and its role alongside clave and tumbao, distinguishing it from sibling pattern 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cáscara patterns within Afro-Cuban rhythm sections, mentioning clave and tumbao as counterparts. However, it lacks explicit guidance on when to use this tool versus 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.
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 the tool creates new notes and modifies their arrangement, but doesn't explicitly state whether it modifies existing notes or works non-destructively. The return value is mentioned, but permissions or side effects are not addressed.
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, contextual explanation, and parameter list. It is front-loaded with the main purpose. A few sentences could be trimmed, but overall it is appropriately sized for a complex 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 12 parameters, no annotations, and presence of output schema, the description provides a solid understanding of the tool's functionality, including modes, parameters, and return values. It lacks discussion of prerequisites or error cases, but is sufficient for an agent to use the tool effectively.
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 in detail with musical context (e.g., chop_mode explanations, segment_beats range, stutter_count range). It adds meaning beyond the schema property names, though some parameter details (like exact format for pitches) could be clearer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 chop — slice source pitches into segments and rearrange them.' It uses a specific verb-resource pair and distinguishes this tool from siblings by emphasizing the hip-hop/EDM sampling technique with references to Dilla, Madlib, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 ('quintessential hip-hop/EDM sampling technique') with examples of musical applications. However, it does not explicitly state when not to use it or mention alternative tools (e.g., create_stutter for stutter-only effects).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes algorithm, parameter effects (e.g., velocity accent), and return values. Lacks disclosure of error handling or edge cases, but overall covers main 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and algorithm. Well-structured with examples, parameter list, and return description. Slightly lengthy but information-dense; 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?
Covers algorithm, parameter constraints, return format, and examples. Output schema exists but its content is not detailed here. Missing some parameter descriptions and potential error scenarios, but overall complete for a creation 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 has 0% description coverage. Description explains 7 of 10 parameters (onsets, steps, rotation, bars, pitch, velocity, duration) with ranges. Missing descriptions for start_beat, unit_index, track_index. Provides significant added meaning for most 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?
Description clearly states the tool creates a Euclidean rhythm, explaining the algorithm and listing classic rhythms. It uniquely distinguishes from siblings like create_breakbeat or create_polyrhythm by specifying a precise mathematical method.
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 examples of when to use specific Euclidean patterns but lacks explicit guidance on when to prefer this tool over alternatives like create_samba_pattern or create_breakbeat. Usage context is implied through examples rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 that the tool is deterministic (same axiom+rules+iterations = same melody) and mentions the return value. However, it does not detail side effects (e.g., does it directly modify a track?), error conditions, or behavior for edge cases like invalid rules.
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, explanation of L-systems, comparison to other methods, presets list, custom options, then parameter list. It is slightly lengthy but front-loaded with essential information. 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?
Given 15 parameters and no output schema, the description covers the tool's purpose, how it works, and most parameter meanings. It mentions return value (notes, string length, statistics) but not exact structure. Overall, it is sufficiently complete 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 coverage is 0%, so description must compensate. It provides an 'Args' section explaining each parameter, including preset names, custom JSON formatting for rules and symbol_map, and typical defaults. Basic parameters like track_index are only glossed, but overall the description adds significant meaning beyond the naked 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 a melody using an L-system' and explains the underlying concept. It distinguishes L-systems from Markov chains and random walk by highlighting determinism and self-similarity. Presets and custom options are 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 explicitly contrasts L-systems with stochastic methods (Markov chains, random walk) and lists ideal use cases (self-similar, deterministic generative composition). It does not explicitly state when not to use it, but the differentiation from siblings 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the return value (total notes and pattern info) but does not disclose whether the operation is destructive, requires specific permissions, or has rate limits. Since it creates new content, it is likely nondestructive, but the lack of explicit behavioral details results in a score of 3.
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 of the output, usage context, then a parameter list with examples. It is somewhat lengthy but each sentence adds value. It front-loads the purpose. Could be slightly more concise, but overall 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 9 parameters, 3 required, and an output schema, the description covers the musical concept and key parameters. It does not detail behavior like placement or conflict resolution, but defaults and the return value provide enough context for correct invocation. The description is complete enough for typical 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 explain parameters. It provides clear explanations for required parameters (root, scale, pattern) with examples (e.g., '1 5 3 5' for pattern). It also describes optional parameters like repeats, octave, and velocity. However, it does not explain start_beat, unit_index, or track_index, which are likely technical but have defaults. Overall, good parameter 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 defines the tool's purpose: creating an ostinato, a repeating melodic/rhythmic pattern. It explains what an ostinato is and its musical context. The tool name and description align perfectly, and the description distinguishes this from other create_* tools by specifying the nature of the 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 provides context for when to use this tool: for short repeating patterns as a foundation layer, common in minimalism, electronic, and film music. This helps an agent decide. However, it does not explicitly mention alternative tools (e.g., create_ground_bass, create_passacaglia) or when not to use it, but the guidance is sufficient for most cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that drum notes are created using specific GM percussion pitches (36, 38, 42, 46), details swing range (0.0-0.6), and describes each style's rhythmic feel. However, it does not address behavior with invalid inputs, overwriting, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear lead sentence and bullet-style style definitions. However, it is somewhat lengthy (multiple paragraphs) and includes very detailed BPM ranges for each style that could be streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 8 parameters and no annotations, the description covers the main behavioral aspects: what it creates (drum notes with specific pitches), style choices, and swing. It does not detail output schema (though one exists) or error handling, but it is largely complete for a creative drum pattern generator.
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 add meaning. It explains 'style' with 6 detailed subdescriptions, 'swing' with range and genre guidance, and mentions 'track_index' and GM pitches. However, parameters like 'bars', 'velocity', 'tempo_bpm', 'start_beat', and 'unit_index' are not individually explained beyond 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 it creates reggae percussion patterns across 6 styles, using a specific verb ('create') and resource ('reggae percussion'). It distinguishes itself from siblings like 'create_breakbeat' and 'create_drum_pattern' by narrowing scope to Jamaican reggae.
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 detailed style characterizations that implicitly guide when to use each style (e.g., one_drop for roots reggae, ska for fast upbeat), but lacks explicit when-to-use or when-not-to-use comparisons with alternative tools. No direct mentions of alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It explains that voices are created on consecutive tracks starting at track_index, and details the meaning of melody and rhythm patterns. It does not disclose whether tracks must already exist, what happens to existing data, or any side effects like track creation. This is adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured. It front-loads the definition and usage context, then provides parameter details. Every section adds value, though the parameter list could be condensed into a table. Overall, it is efficient for the 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 has 10 parameters and an output schema, the description explains the input parameters and the effect on tracks well. It does not describe the return value (e.g., created note events), but the output schema likely covers that. It is mostly complete for an agent to understand 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?
With 0% schema description coverage, the description must explain parameters. It clearly explains melody_pattern (scale degrees), rhythm_pattern (durations), key_root, scale_name, voices (2-5), and octave_spread. However, it does not explain velocity, start_beat, unit_index, or track_index. This covers 6 of 10 parameters, adding 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 'Create a soli — ensemble unison passage with octave doublings.' It defines the musical concept, distinguishes it from fugue and canon, and provides technical details about melody/rhythm patterns, scale degrees, and voicing. This leaves no ambiguity about the tool's 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 explains when a soli is common (jazz big band, orchestral tutti, rock/metal riffs) and contrasts it with fugue and canon. However, it does not explicitly state when to avoid this tool or compare it to sibling tools like create_fugue or create_canon, nor does it specify prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 burden. It explains that the tool generates a complete solo line and returns notes and solo characteristics. However, it does not disclose potential side effects (e.g., does it overwrite existing notes on a track?), permissions needed, or constraints (e.g., track must have a chord progression). The behavioral detail is adequate but not thorough.
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, starting with a one-line summary, followed by a bulleted list of genre techniques, parameter list, and examples. It is relatively long but every sentence adds value, especially the detailed genre explanations. The structure aids quick scanning for relevant details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large sibling toolset (including similar tools like generate_melody and create_random_walk), the description clearly differentiates this tool. It mentions an output schema and states it returns 'notes created and solo characteristics,' so return values are covered. The missing parameter details for start_beat, unit_index, and track_index are gaps, but overall the description is complete for the core use case.
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% (no descriptions in the input schema). The description covers 7 of 10 parameters (solo_type, key_root, scale_type, bars, octave, velocity, seed) with details on default values and examples. However, it omits start_beat, unit_index, and track_index, which are crucial for placement. The description adds significant meaning beyond the schema but misses some parameters, so it partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a 'genre-specific melodic solo over a chord progression.' It explicitly distinguishes itself from generate_melody and create_random_walk_melody, specifying that it uses genre-specific soloing techniques. The verb 'create' and resource 'solo' are specific, and the scope is well-defined.
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 generate_melody (contour-guided) or create_random_walk (stepwise), this tool uses genre-specific soloing techniques.' It also lists valid values for solo_type, key_root, scale_type, etc., and provides examples, helping the agent understand the context and prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description details the section format, available presets, optional pipeline steps (mix, humanize, master), and return values. It does not mention potential side effects on existing project state or clarify track usage, but covers the main behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions 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 purpose statement, an exhaustive list of section presets, a compact explanation of flags, a return value summary, and multiple practical examples. Every sentence adds value without 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?
Given 12 parameters, no annotations, and no visible output schema, the description covers the core functionality but omits details for several parameters and does not clarify what tracks are referenced or how the tool integrates with the existing project. The default section string is helpful, but track indices remain unexplained.
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%, and the description compensates by thoroughly explaining the 'sections' parameter, the 'genre' (via examples and support statement), and the three boolean flags. However, parameters like bpm, root, bass_track, drum_track, melody_track, harmony_track, and unit_index are only briefly mentioned in examples or not described, 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?
Description clearly states 'Build a complete song with real musical variations between sections — one call' and distinguishes from 'create_genre_sections' which repeats loops. Specifies that 14 genres are supported. The verb 'create' and resource 'song with variations' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 contrasts with 'create_genre_sections' to guide when to use this tool. Provides default sections and examples for different genres, but does not explicitly state when not to use this tool or list alternatives beyond the one sibling mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 that it creates MIDI notes for kick, snare, and hi-hat with specific patterns, and mentions return value. However, it does not disclose potential side effects like overwriting existing notes, error handling, or behavior with invalid 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 well-organized with a clear introduction, detailed roll_type breakdown, and parameter list. It is somewhat verbose but informative. Minor redundancy could be trimmed, but overall it is structured 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 (9 parameters, no required) and lack of annotations, the description is fairly complete. It explains musical context, roll types, parameter defaults, and return values. It lacks coverage of a few parameters and edge cases, but is still substantial.
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 description must compensate. It elaborates on roll_type with five subtypes and their musical contexts, and covers bars, kick_pitch, snare_pitch, hat_pitch, velocity with defaults. However, it does not explain start_beat, unit_index, or track_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 it creates trap hi-hat roll patterns, a specific resource, with a verb 'create'. It distinguishes from siblings by focusing on a genre-specific pattern, and includes detailed 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 provides extensive guidance on when to use each roll_type with musical examples and references. However, it does not explicitly state when not to use it or directly compare to alternatives like create_boom_bap, though the context is sufficient given sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description explains the concept and parameters, and mentions return values (notes, ratio, timing). However, it does not explicitly state that the tool adds notes to a track or disclose side effects, permissions, or constraints, which would be needed 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with purpose and concept, followed by a structured Args list. It is slightly verbose but each sentence serves a purpose. Could be trimmed slightly but 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?
The description covers the concept, parameter details, common tuplets, and return value. It is complete enough for a creation tool with an output schema. Minor gaps include error conditions and explicit mention of additive behavior to existing 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?
Schema coverage is 0%, but the description provides detailed explanations for key parameters (tuplet_number, span_beats, base_division, rest_positions, etc.) with examples and ranges. Some generic parameters like root, scale, and velocity are not elaborated, but overall adds significant 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 'Create a tuplet group — irrational rhythm subdivision within a time span.' It uses a specific verb and resource, and contrasts with polyrhythm and additive rhythm, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contrasts tuplets with polyrhythm and additive rhythm, and lists common tuplets with usage contexts (jazz swing, Chopin, etc.). It provides clear context but lacks explicit when-not-to-use or alternatives beyond the contrasts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the walking bass algorithm (beat roles: root, chord tone, passing tone, approach note) and what the tool returns (notes created, summary). It does not mention side effects or auth requirements, but the algorithm and output are 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear action, musical context, parameter list, algorithm explanation, and example. It is slightly long but each section adds value. Could be tightened by removing redundancy in the parameter descriptions already in 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?
Given the complexity of walking bass generation and the presence of an output schema (inferred), the description covers input, algorithm, and output. It does not address edge cases (e.g., empty chords) but is otherwise sufficient for 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?
Since schema description coverage is 0%, the description compensates by explaining most parameters: chords format, octave range, velocity range, bars_per_chord meaning, and mentions unit_index and track_index. However, unit_index and track_index are not fully explained beyond 'AU index' and 'Note track index', which is somewhat clear but could be more explicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 walking bass line over a chord progression, specifying the resource (bass line) and action (create). It distinguishes from siblings like create_bassline and create_electronic_bass by the specific walking bass style and algorithm, and ties it to jazz, blues, and swing contexts.
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 jazz/blues/swing and walking bass patterns, but does not explicitly state when to use this tool versus alternatives like create_bassline or create_bass_from_progression. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already provide destructiveHint=true, signaling destructive action. The description adds the method of deletion (by index) but does not elaborate on consequences (e.g., irreversibility, effect on project state). 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?
Two sentences, each essential. Front-loaded with the core purpose. No redundant or extraneous 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 simplicity of the tool (one parameter, straightforward purpose) and the presence of an output schema, the description is nearly complete. It could mention that the deletion is irreversible or what happens if the index is invalid, 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?
The description explains the single parameter 'marker_index' as 'Index from list_markers (0-based)', which adds critical meaning beyond the schema (only type and title). With 0% schema description coverage, this fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a timeline marker by index' with a specific verb (delete) and resource (timeline marker). It distinguishes from sibling tools like add_marker, set_marker_label, and delete_warp_marker.
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 advises to get the index from list_markers, which is a helpful prerequisite. However, it does not explicitly state when to use this tool versus alternatives (e.g., set_marker_label to modify, or other delete tools). Context is implied 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it works with note, audio, and automation regions, preserves content, and returns details. However, it does not mention potential overlapping regions or undo behavior, which 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?
Description is structured with a summary, detailed explanation, parameter list, and examples. It is front-loaded with the core action. Slightly verbose but 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 moderate complexity and no annotations, the description covers the operation, region types, parameter details, and return value. Examples enhance understanding. It is mostly complete 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains all parameters (from_beat, to_beat, target_beat, unit_indices), notes defaults, and provides examples. This adds significant meaning beyond the basic 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 'Duplicate all regions within a beat range to a new position.' It specifies the action (duplicate) and resource (regions within a beat range). The mention of 'arrangement operation producers use constantly' and examples differentiate it from other duplicate tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear examples like 'copy verse 1 to bar 17' and explains when to use (copying sections). However, it does not explicitly state when not to use it versus alternatives like duplicate_region or move_section, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by explaining that it resolves the automation curve, accounting for interpolation, region loops, and multiple overlapping regions. It also states the normalized value range (0.0-1.0). This goes beyond the annotations to clarify 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 concise with a clear first sentence stating the purpose, a second paragraph adding behavioral detail, and a third paragraph listing parameters. It is front-loaded and fairly efficient, though the parameter list could be integrated into a bullet format for even easier 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 read-only get tool with annotations and an output schema, the description covers the essential behavior: resolving the curve, handling interpolation/loops/overlaps, and returning a normalized value. It could mention what happens if the position is out of bounds or the track doesn't exist, 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%, so the description bears the full burden. It briefly explains each parameter: 'unit_index: AU index', 'track_index: Value (automation) track index within the AU', 'position_beats: Position in beats (float)'. This adds meaning beyond the schema's names and types, though could include valid ranges or 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 verb 'get' and the resource 'automation value at a specific position on a value (automation) track'. It explains that it resolves the curve accounting for interpolation, loops, and overlapping regions. This distinguishes it from sibling tools like list_automation_events (which lists events) or set_automation (which writes).
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 reading automation values at a point, but it does not explicitly state when to use this tool versus alternatives like list_automation_events or other get tools. No when-not-to-use guidance 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that it returns specific fields but does not disclose any additional behavioral traits beyond what annotations provide. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions 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 verb and resource, and efficiently lists what is returned. 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?
Given zero parameters and an existing output schema, the description fully explains the tool's purpose and return values. No 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?
There are no parameters, so schema coverage is effectively 100%. The description does not need to add parameter meaning. Baseline for 0 params 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 the tool retrieves piano roll view settings and enumerates the returned fields (keyboard type, time range, note scale, note labels, transpose). It distinguishes itself from sibling set_piano_* tools by being a getter.
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 current piano roll settings are needed, but does not explicitly state when to use versus alternatives or provide any exclusion criteria. Given the presence of set_piano_* siblings, the getter role is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 specifying the returned data structure (code string, header line, code length). No contradictions, and no additional side effects or requirements are disclosed, but the safety profile 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 extremely concise at two sentences, with no filler or redundancy. Every sentence adds value: one states the action, the other the 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?
Given the output schema exists and annotations are present, the description is largely complete. It covers the tool's purpose and return format. However, it does not explain what constitutes a 'scriptable device' or how to interpret the parameters, which is a minor 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% and the description does not explain any of the three parameters (device_type, unit_index, device_index). Although parameter names are somewhat self-explanatory, the description fails to compensate for the lack of schema descriptions, leaving an agent to guess 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 description clearly states the tool reads user JavaScript code from a scriptable device, with a specific verb and resource. It also lists the return fields (full code string, header, code length), distinguishing it from the sibling set_script_device_code 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 implies usage for reading code, and the sibling set_script_device_code is the obvious alternative for writing. However, it lacks explicit 'when to use' or 'when not to use' guidance, and no prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation 'readOnlyHint' already marks the tool as read-only. The description adds behavioral context by noting the return includes 'positions in beats' and 'interpolation details'. No contradiction with annotations; it enriches the agent's understanding of what the tool provides 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 about five sentences, front-loading the purpose and key differentiator. It is clear and without fluff. Every sentence serves a purpose, though it could be slightly 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?
Given that the tool has an output schema (not shown but present) and read-only annotation, the description covers the purpose, a sibling comparison, parameter meanings, and return structure. It is fairly complete for a list tool with two parameters, though it omits details like ordering or result limits (likely covered by output schema).
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% (no descriptions in schema), so the description must compensate. It provides brief explanations: 'unit_index: AU index' and 'track_index: Value (automation) track index'. This adds basic meaning beyond property names but lacks details like valid ranges or format. With 0% coverage, a score of 3 reflects minimal but present 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 clearly states the tool lists automation events on a value track with full detail including position, value, and interpolation. It distinguishes from the sibling 'list_automation_events' by explicitly stating it includes interpolation type and curve slope, 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 provides a clear comparative guideline: 'More detailed than list_automation_events' indicates when to use this tool versus the sibling. It also explains the two required parameters. While it lacks explicit 'when not to use' caveats, the comparative guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, and the description confirms a read-only list operation. No additional behavioral traits (e.g., about scoping or performance) are disclosed. The description is consistent but does not add 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 a single, concise sentence that is front-loaded with the action and resource. Every word is necessary and no filler exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, read-only, output schema exists), the description fully covers what the tool does and what information it returns. It mentions 'positions and labels' which aligns with likely output schema fields.
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 schema coverage is trivially 100%. The description is not required to explain parameters but correctly indicates no inputs needed. Baseline 4 for 0 parameters 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 states 'List all timeline markers with positions and labels' which clearly specifies the action (list), the resource (timeline markers), and the returned data (positions and labels). This distinguishes it from sibling tools like mcp_opendaw_add_marker (writes) and mcp_opendaw_list_transient_markers (lists a different type).
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 mcp_opendaw_add_marker or mcp_opendaw_set_marker_label. Usage is implied for viewing markers, but no guidance on when not to use or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only (readOnlyHint=true). The description adds the return structure and auto-detect behavior, but does not disclose potential errors (e.g., invalid unit index) or performance implications. Beyond annotations, it provides moderate 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 concise, front-loaded with purpose, and uses bullet points for return fields. Every sentence adds value 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?
Given the simple single-parameter schema and the described return structure, the description is fairly complete. It covers purpose, parameter meaning, and output fields. Minor missing details: error handling for auto-detect failure or invalid indices, but overall sufficient for a read 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% for the unit_index parameter. The description fully compensates by explaining its meaning ('Audio unit index (-1 = auto-detect Vaporisateur)'), which is essential for correct tool 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 retrieves the full Vaporisateur synthesizer state, listing included components (oscillators, LFO, noise, main params). It is specific to Vaporisateur and distinguishes itself from sibling tools like set_vaporisateur_osc_param (which sets a parameter) and list_instrument_params (generic).
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 unit_index parameter with auto-detect behavior but does not explicitly state when to use this tool versus siblings or provide when-not guidance. The context implies usage for retrieving Vaporisateur state, but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 for behavioral disclosure. It only states the action 'place' and a prerequisite constraint, but does not explain side effects, what the tool does to the track (e.g., create or overwrite), or what the output schema returns. This is insufficient for a mutative 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 (~100 words) and well-structured: a one-sentence summary, followed by parameter details, then a critical note. No redundant or irrelevant information. Front-loaded with the key 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 complexity of the domain and the number of sibling tools, the description covers prerequisites and parameters but lacks behavioral context (e.g., return value, confirmation, potential errors). An output schema exists but is not mentioned, leaving the agent unaware of what to expect.
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 all four parameters in a list, adds context for sample_id (origin), and states defaults for unit_index and track_index. This adds meaningful information 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 ('Place'), the resource ('previously loaded audio sample'), and the target ('as a region on a track'). It explicitly links to the prerequisite tool (mcp_opendaw_load_audio) and distinguishes from other creation tools by specifying the need for 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 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: after loading an audio sample. It includes a critical note about the required audio unit type (instrument AU with Tape device) and directs to mcp_opendaw_create_instrument_track if absent, effectively telling when not to use and providing an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the basic action (renames instrument, optionally sets icon) and the return value (old and new name/icon). However, it does not reveal potential side effects (e.g., whether it triggers a re-render, requires saved state, or is reversible). Given no annotations, more depth 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a summary sentence, context about instrument AUs, parameter details, and return value. Every sentence adds value without redundancy. The use of bullet-like explanation for parameters is clear 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 simple mutation tool with 3 parameters, the description adequately covers the purpose, constraints, and return value. It lacks discussion of error handling (e.g., invalid unit_index) or prerequisites, but overall is sufficient. The presence of output schema is not an issue since 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 fully compensates. It explains each parameter: unit_index with constraints (must be >=1, not output AU), name and icon with the ability to skip (empty = skip), and provides icon examples. 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 clearly states the tool's purpose: 'Rename an audio unit's instrument and optionally set its icon.' It specifies that the output AU (index 0) has no instrument and cannot be renamed, distinguishing it from other similar tools like set_device_label or set_clip_label. The verb 'rename' and resource 'audio unit's instrument' 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides constraints on usage (unit_index must be >=1 and not the output AU) and explains that name and icon can be empty to skip. However, it does not explicitly guide when to use this tool versus alternatives like set_device_label or other rename tools. The usage context is implied but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 notes that MP3/FLAC conversion uses system ffmpeg and that the tool returns both WAV and converted file paths. However, it does not mention potential side effects, prerequisites (e.g., engine running), or constraints (e.g., project must be fully loaded). Given these gaps, the transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions 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 header, a bullet-like param listing, and a summary line. Every sentence provides necessary information without redundancy. It is front-loaded with the core purpose and structured for easy parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 4 parameters and an output schema, the description covers the key aspects: purpose, parameter semantics, the combined operation, and ffmpeg dependency. It lacks mention of prerequisites (e.g., project state) and error handling, but these might be covered by the output schema. Overall, it is fairly complete for a 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 description coverage is 0%, so the description must fully explain parameters. It does so effectively: clarifies that filename expects no extension, defines default sample_rate (48000), lists format options (wav/mp3/flac) with a note about ffmpeg dependency, and explains that bitrate is ignored for WAV/FLAC. This adds substantial value beyond the schema's default values 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's purpose: 'Render the entire project and convert to MP3 or FLAC in one step.' It specifies a concrete action (render+convert) and the resource (entire project). This distinguishes it from sibling tools like mcp_opendaw_render_full and mcp_opendaw_convert_audio, which handle only part of this workflow.
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 mentions that it combines 'render_full + convert_audio' and lists parameter details, which implicitly guides when to use it (for one-step render and format conversion). However, it does not explicitly state when not to use it (e.g., if only WAV is needed, render_full may be sufficient) or provide alternatives. Guidance is adequate but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states that the tool returns old and new mute state, but does not mention potential side effects (e.g., affecting playback, or if the mute is independent of other muting mechanisms). It does not describe error handling for invalid indices. Transparency is adequate 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 short (3 sentences) and well-structured: first sentence states purpose, second explains parameters, third describes return value. No redundant information. It is appropriately concise for a simple parameter-setting 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 tool has a simple interface and an output schema (not shown), so the description need not explain return values in depth. It mentions returning old and new mute state, which is sufficient. However, it omits error handling, prerequisites (e.g., clip must exist), and context about session vs arrangement view. These gaps are minor for a simple mute toggle but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 must compensate. It clearly defines each parameter: 'unit_index: AU index', 'track_index: Track index within the AU', 'clip_index: Clip index', 'mute: True to mute, false to unmute.' This adds essential meaning beyond the schema 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 clearly states the tool's purpose: 'Mute or unmute a clip in the session view.' It specifies the verb (mute/unmute), the resource (clip), and the context (session view). This distinguishes it from sibling tools like set_clip_hue or set_clip_label, which target other clip properties.
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 provide explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, what happens if indices are invalid, or how this tool relates to other mute controls in the DAW. While the purpose is straightforward, some usage context would improve AI decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 valid range (0=infinite, 1-16=N repeats) but does not disclose side effects (e.g., overwriting existing values, undo capability, or if repeat count resets playback).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with two brief sentences plus parameter details. It front-loads the action and avoids 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?
The tool is simple with 2 required parameters and an output schema exists (not shown). The description covers the functionality well but omits return value information, which is acceptable given the output schema presence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds crucial context beyond the schema: 'marker_index: Index from list_markers (0-based)' and 'repeat_count: 0 = infinite repeat, 1-16 = N repeats'. With 0% schema coverage, this fully compensates by explaining origin 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 'Set the repeat count on a timeline marker.' This verb+resource pattern is unambiguous and distinguishes from sibling tools like set_marker_label or set_marker_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (to set a marker's repeat count) but provides no guidance on when not to use it or alternatives. It lacks exclusion context compared to other marker modification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 tool returns old and new values, which is helpful, but omits any other behavioral traits such as side effects, error handling, 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 short and directly organized as a bullet list of parameters. Every sentence provides necessary 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 the 5 parameters, no schema descriptions, and the existence of an output schema, the description covers parameter semantics and return values well. It lacks prerequisite or error context, but is fairly complete for a setter 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 explicitly lists all 5 parameters with concise explanations, including examples for param_name and the -1 convention for param_index. 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?
Description explicitly states 'Set a parameter on a MIDI effect', which is a clear verb+resource combination. The name and description directly differentiate it from sibling tools like set_effect_parameter (for audio effects) and set_instrument_param.
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 MIDI effects by naming the tool accordingly, but does not provide explicit guidance on when to use it versus alternatives (e.g., set_effect_parameter for audio effects) 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.
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: copies all dependencies, works across audio units, shared resources are not duplicated, optional deletion (move semantics), and expected return value. This provides good transparency beyond basic 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 short paragraph describing the action, followed by a bullet-like list of parameter explanations. Every sentence adds 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 moderate complexity (cross-AU transfer, sharing resources, optional deletion), the description covers the essential aspects. It mentions the return value but could further elaborate on error conditions or prerequisites (e.g., destination track must exist). Still, it 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%, but the description provides clear, concise explanations for all 7 parameters, including details like region_index being 0-based and sorted by position, insert_position in beats, and delete_source controlling move vs copy. 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.
Purpose4/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 a region to another track at a specific position, using a specific verb and resource. It mentions copying dependencies and optional deletion, but does not explicitly differentiate from sibling tools like mcp_opendaw_copy_region_to_track or mcp_opendaw_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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (to transfer/copy a region across audio units) but does not provide explicit guidance on when not to use it or what alternatives exist. The usage context is implied rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the tool adds automation points and returns info, but does not disclose whether it overwrites existing automation, if the parameter must exist, or any side effects. Lacks details on error behavior or prerequisites like instrument presence.
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?
Well-structured with a clear first sentence stating purpose, followed by examples and parameter explanations. Slightly lengthy but front-loaded and every sentence adds value. Could be tightened slightly without losing 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?
Covers parameter details, return value (automation track info and events count), and notes compatibility with various instruments. Lacks mention of error conditions or required project state (e.g., audio unit must exist and be loaded). Overall fairly complete for a 4-parameter tool with 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?
Input schema has 0% description coverage. The description provides detailed meaning for all four parameters: unit_index (audio unit index), parameter_name (field name), points (JSON array with example), and sample_index (explained -1 vs specific index). Adds significant value beyond 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?
Clearly states the tool automates a parameter on an instrument connected to an audio unit. Provides specific examples of instruments and parameters (Vaporisateur cutoff, Playfield mute, etc.), and distinguishes from siblings like 'add_automation' (general) and 'set_instrument_param' (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?
Offers clear context for use: any automatable instrument field with examples. Instructs on when to set sample_index vs -1. Does not explicitly exclude alternative tools or state when not to use this tool, but the context is sufficient for informed selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the created chain (Revamp EQ → Compressor → Reverb → Delay) and mentions return values. However, does not disclose whether existing effects are replaced or added, nor prerequisites (e.g., unit must exist). No annotations provided to compensate.
Agents need to know what a tool does to the world before 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: summary, parameter descriptions, examples. Every sentence adds value without 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?
Explains the chain, parameters, outputs, and provides examples. Could address edge cases (e.g., existing effects), but overall complete 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?
Explains each parameter (unit_index, style with detailed descriptions, reverb_amount, delay_amount) beyond the schema, which has no descriptions. Good coverage for 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a ready-made instrument processing chain (EQ, Compressor, Reverb, optional Delay) for melodic/harmonic instruments. It distinguishes from siblings like add_effect and set_effect_parameter by noting one call replaces 3-4 individual 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?
Provides context (universal chain for melodic/harmonic instruments) and style guidance, but lacks explicit when-not-to-use or alternative tools beyond implied replacement of individual effect calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the algorithmic behavior: it creates a preparatory note, holds it into a strong beat, and resolves to the target note. It explains the structure (preparation -> suspension -> resolution) and how parameters affect the outcome. Since no annotations are provided, the description carries the full burden of disclosure, and it does so well, though it could mention whether the original notes are modified or new notes are added.
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 notably verbose, including a multi-paragraph music theory lesson about suspensions (preparation, suspension, resolution). While informative, this could be shortened for an AI agent that primarily needs functional details. The first sentence is a clear purpose statement, but the length reduces conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 musical effect and the presence of an output schema, the description is fairly complete. It explains the algorithm, parameters, and musical context. It does not mention error conditions or return values, but the output schema likely covers that. It is sufficient for an AI agent to understand 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?
Despite 0% schema description coverage, the description provides clear semantics for each of the 11 parameters in the docstring (e.g., 'unit_index: Audio unit index', 'suspension_offset: Semitone offset of suspension from target'). It explains defaults and typical values. However, some parameter descriptions could be more precise (e.g., root defaults to 'C' but the description only says 'Root note for scale'). Overall, it compensates well 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 verb 'Add suspension-resolutions to existing notes' and provides a detailed explanation of what a suspension is in music theory. It distinguishes itself from sibling tools by being specific about the suspension technique, 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 explains when to use the tool: 'This tool finds notes on strong beats (downbeats) and creates a suspension before them.' It implies the context of adding expressive non-chord tones. However, it does not explicitly state when not to use it or mention alternative tools for similar effects (e.g., anticipation, neighbor tones), which would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 tool applies settings to all audio units, returns applied settings, and can use named presets. However, it does not mention prerequisites (e.g., units must exist), error handling (e.g., invalid preset keys), or side effects (e.g., overwriting existing settings). Given no annotations, this is adequate but not thorough.
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, bullet-like sections, and examples. It is reasonably concise but includes some redundancy (the example repeats the preset format already described). Overall, it earns its space and is front-loaded with the key 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 (applies mix to all units), no annotations, and low schema coverage, the description is quite complete. It covers the action, parameter format, built-in presets, and return value. Minor gaps: it doesn't explain behavior for non-existent units or invalid preset keys. But overall, it provides sufficient context for an AI agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain the 'preset' parameter. It does so in detail: the parameter can be a JSON string with unit indices and settings (volume_db, panning, mute, solo) or a named preset string like 'lofi'. It provides concrete examples and even describes the built-in presets. This exceeds what the schema alone conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Apply a mix preset to all audio units in one call — volume, pan, mute, solo.' This clearly states the verb (apply), resource (mix preset to all audio units), and scope (volume, pan, mute, solo). It explicitly distinguishes from sibling tools like set_track_volume by noting it replaces 10-30 individual 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 provides clear context on when to use this tool: when you want to apply a mix preset to all units and replace many individual set_* calls. It mentions alternatives (named presets vs custom JSON) and gives examples. It does not explicitly 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.
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 effect on durations, mode behavior (scale vs stretch), and return values (counts of augmented and skipped notes). It does not explicitly state that the tool mutates project state, but the mutation is implied. Could be improved with a caution about destructive changes.
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 thorough but verbose, including historical examples and references that may not be essential for an LLM agent. While the first sentence front-loads the purpose, the subsequent paragraphs add context that could be trimmed. Adequate, but could be more 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?
Given no annotations and an empty schema, the description covers all necessary information: tool intent, parameter explanations, mode behavior, and return format. It accounts for the tool's complexity and provides enough context for an agent to use it correctly. The output schema exists but is not needed for 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 coverage is 0%, so the description must compensate fully. It explains factor range (0.25-4.0), default for region_index (-1 = all regions), and mode options with detailed examples of 'scale' (multiply duration and position) vs 'stretch' (duration only). All five parameters are meaningfully described, adding 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 augments or diminishes note durations, positions it as the fourth classical transformation, and differentiates it from siblings like transpose, reverse, invert. Musical examples (Beethoven 5th, Bach fugues) reinforce the purpose and distinguish it from other 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 when to use the tool (for duration changes with factor >1 or <1) and provides mode options. However, it does not explicitly mention when NOT to use it or compare with sibling tools like scale_durations, which also modifies durations. Lacks explicit alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 describes the return output (deviation analysis with suggestions) but does not explicitly state whether the tool is read-only or has side effects. The example gives a sense of output structure.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with a short intro, bullet points for analysis dimensions, parameter documentation, return clarification, and an example. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description provides a good overview of return structure. It covers the main use case, parameter ranges, and an example. However, it does not mention error conditions, file size limits, or prerequisites beyond file path.
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 adds significant value: it documents the 'filename' parameter as a WAV file in exports or absolute path, and lists all valid genres for the 'genre' parameter. This goes 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 compares a mix against a genre profile, listing specific dimensions (LUFS, spectrum, stereo width, dynamics, spectral centroid). It effectively distinguishes from siblings like 'compare_to_reference' which is for comparing to a specific reference 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 when to use: when you need to see deviations from genre standards. It implicitly distinguishes from alternative sibling tools but does not explicitly 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.
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 tool creates a new independent copy and returns success/error, but does not mention side effects, permissions, or reversibility. The description adds value beyond the schema but could be more 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 very concise and well-structured: a one-line purpose, a condition explanation, a parameter list, and a return note. Every sentence earns its place, 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 (3 required integer params, output schema exists, no annotations), the description covers purpose, usage condition, parameters, and return type. It is sufficiently complete for an AI agent to select and invoke the tool correctly, though it could mention idempotency or errors.
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 gives brief but clear explanations: unit_index is 'AU index', track_index is 'Track index within the AU', region_index is 'Region index to consolidate.' This adds meaning and clarifies hierarchy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Consolidate a region's event collection — make it unique (not shared/mirrored).' It clearly names the action and resource, distinguishing it from sibling tools like consolidate_clip and consolidate_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 description explains when to use this tool: when a region shares its event collection with others (mirrored), you can make a copy. It provides clear context but 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions the tool used (ffmpeg), that it's not browser WASM, and returns path/size. It could clarify if the source is modified, but overall discloses key behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions 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 clear opening sentence and bullet-like parameter explanations. Every sentence adds value without redundancy. Very 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 complexity and the presence of an output schema, the description covers inputs, external dependency, and return info. Lacks error scenarios but is fairly complete for a conversion 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%, but the description adds meaning for each parameter: filename (without .wav, in export dir), format (mp3/flac), bitrate (CBR, default 320k, ignored for FLAC), quality (VBR 0-9, -1 for CBR). This 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 'Convert an exported WAV file to MP3 or FLAC using system ffmpeg', specifying the action, source, target formats, and tool. It distinguishes from siblings like export 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 explains the filename must be in the export dir, requires system ffmpeg, and falls back gracefully. It does not explicitly list when not to use, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral transparency burden. It explains the output (notes, grouping, accents, bar layout) and provides examples showing the resulting accent pattern. However, it does not disclose whether the operation is additive/non-destructive or if it modifies 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a conceptual overview, examples, and parameter list. It front-loads the key idea. While a bit lengthy, every section earns its place; minor redundancy 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?
Given the tool's complexity (14 params) and the presence of an output schema, the description adequately explains what the tool does and returns. It could mention how it interacts with the project (e.g., adds to a specific track) but overall covers the essential 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?
Despite 0% schema description coverage, the tool description's Arg section provides complete and detailed explanations for all 14 parameters, including defaults, valid ranges, and behavior. 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 creates an additive rhythm (unequal groupings within a bar) and distinguishes it from other rhythm tools by defining the specific musical technique. The name also 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 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 examples referencing specific composers and genres (Messiaen, Stravinsky, math rock) but does not explicitly compare with sibling tools like create_euclidean_rhythm or create_polyrhythm. No direct 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It details the polyrhythmic interlock and track roles, but does not disclose whether existing notes on those tracks are overwritten, or if track creation is handled. Some behavioral aspects are implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: starts with purpose, then details each track, followed by parameter explanations and examples. Every sentence adds value, and the length is appropriate for the 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 11 parameters, no annotations, and output schema existence, the description covers musical intent, track roles, parameter defaults, and example calls. It lacks details on handling missing tracks or the velocity/start_beat parameters, but is largely complete for the genre-specific arrangement.
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 description compensates. It explains 9 of 11 parameters with musical context, defaults, and examples. However, 'velocity' and 'start_beat' are not mentioned in the parameter descriptions, 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 clearly states 'Create a full afrobeat arrangement' with specific verb and resource, and distinguishes it from sibling tools like create_acid_arrangement or create_ambient_arrangement by specifying the genre and track 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 explains when to use this tool for Fela Kuti-style afrobeat and contrasts with electronic arrangements. It provides defaults and example use cases, but does not explicitly state when not to use it or mention alternative tools for other genres.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 each pattern's rhythmic behavior, MIDI octave range, velocity range, and default values. It does not mention side effects or authorization needs, but for a generative tool, it is sufficiently 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: purpose statement, context (harmonic trio), parameter definitions with examples, and multiple usage examples. It is slightly verbose but every sentence adds value, and the formatting aids readability.
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 no output schema and the generative nature, the description lacks explicit mention of return value (likely success/failure). It provides comprehensive input guidance but omits what the tool returns, which is a minor gap for 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?
Schema coverage is 0%, but the description adds meaning for 6 of 8 parameters: pattern (with detailed pattern definitions), bars_per_chord, octave (with MIDI note reference), velocity (range and default), track_index, and progression. Two parameters (start_beat, unit_index) are not described, but the overall parameter semantics are well-enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 bass line from a chord progression string' and distinguishes itself from siblings like create_bassline by detailing the harmonic trio (chord pads, arpeggiated progression, bass foundation). Examples further clarify the specific 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 clear context for when to use this tool—as part of the harmonic trio for bass foundation—and offers pattern recommendations with genre associations. It does not explicitly state when not to use, but the examples and pattern descriptions serve as adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It details the effect (creates sustained drone chord) and parameters, but does not disclose potential side effects, mutability, or whether it overwrites existing notes. Some behavioral aspects like note creation and retriggering are covered, but safety and idempotency are 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 a clear definition, musical context, and a parameter list. It is somewhat lengthy but each sentence adds value. It could be slightly more concise without losing 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?
The description covers all parameters, distinguishes from sibling tools, and mentions return values. With an output schema present, the return value description is adequate. The musical examples provide rich context, making it complete for agent 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 tool description provides exhaustive explanations for all 10 parameters, including defaults, ranges, and musical semantics. 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 'Create a bordun — continuously sustained drone chord as a textural layer.' It provides a specific verb and resource, and explicitly contrasts with the sibling tool pedal_point, making it easy to differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 what a bordun is and where it is used, and contrasts it with pedal_point. However, it does not explicitly state when to use or not use this tool, nor does it specify alternatives beyond the one contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior fully. It describes that it generates patterns, repeats bars, applies variation, and returns notes. However, it does not mention side effects like whether it overwrites existing notes, prerequisites (e.g., the track must have an audio unit with note tracks), or potential destructive actions. Given no annotations, this is adequate but not thorough.
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 value proposition, then a structural overview, then parameter details. Every sentence adds value; the parameter descriptions are detailed but necessary due to low schema coverage. It is front-loaded with the primary purpose. Minor redundancy is acceptable given the need for 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?
The description explains the tool's core function, all parameters, and the return value. It lacks explicit prerequisites (e.g., the existence of a note track) and does not clarify the behavior of default values like 'unit_index: -1'. However, given the complexity and the presence of an output schema, the description is mostly complete 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema description coverage is 0%, the description carries the full burden for parameter meaning. It provides detailed explanations for all 7 parameters, including the enum-like breakdown of 'break_type' with musical context for each preset, and clear options for 'variation'. Each parameter's role is clearly defined, 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 clear verb and resource: 'Create a classic drum break.' It distinguishes itself from siblings like 'create_drum_pattern' and 'create_breakbeat' by emphasizing it generates patterns from presets with specific iconic break types (amen, think, etc.), making its unique value 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?
The description gives clear context: it's for generating classic drum breaks from presets with optional variation and swing. However, it does not explicitly contrast with alternative tools (e.g., 'create_drum_pattern' for arbitrary patterns), nor does it state when not to use it. The context is clear but lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source for behavioral insight. It details that notes are created, returns notes with type and direction, but does not specify if existing notes are cleared or if there are 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, front-loading the purpose, then providing conceptual context, parameter details, return info, and an example. It is somewhat verbose but efficient for the 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 tool's purpose, parameters, return values, and includes examples. It explains clave direction and types thoroughly. Missing edge cases like invalid track_index, but adequate 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?
With 0% schema description coverage, the description adds substantial value by explaining each parameter, especially clave_type with beat positions. It compensates fully 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 creates an Afro-Cuban clave pattern, distinguishes it from drum patterns, and explains its role as a timeline skeleton. This sets it apart from sibling tools like create_drum_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 when to use the tool (to create clave patterns) and implicitly contrasts with drum patterns. No explicit alternatives are listed, but the unique purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions that the tool 'Generates rhythmic fills... with increasing/decreasing density' and lists fill types with behaviors (e.g., 'build' increases density). It also explains the unit_index default. However, it does not disclose whether existing notes are overwritten or if the tool is purely additive, leaving some 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening, a separate list of fill types, and parameter explanations. It is informative without being overly verbose, though some information (like the bar breakdown) could be integrated more 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?
The description covers the tool's purpose, parameter details, and return value ('Returns notes created per lane and total'). However, it lacks explicit prerequisites (e.g., requiring a drum track or empty note area) and does not fully specify behavior when the target track already contains notes. Given the output schema exists, the description is largely complete but could add more context about the required state of the project.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (only titles), so the description fully compensates by explaining each parameter: fill_type with enumerated options, bars (1-4, each bar = 4 beats = 16 steps), start_beat, density (sparse/medium/dense), unit_index (default -1 finds first AU with note tracks). This provides complete semantic 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 'Create a drum fill or transition pattern' with a specific verb (create) and resource. It explains that one call replaces 10-30 note creations and provides fill types. This distinguishes it from sibling tools like create_drum_pattern and create_break by focusing on fills and transitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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: 'Useful for transitions: verse→chorus, breakdown→drop, outro buildup.' This provides clear context for when to use the tool. However, it does not explicitly state when not to use it or compare to alternatives like create_drum_pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains musical behavior (subject, answer, stretto) and parameter effects but does not disclose operational side effects like whether it overwrites existing notes or requires a pre-existing track. No annotations are 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: purpose first, then musical context, sibling comparison, and parameter details. It is efficient, though slightly lengthy due to parameter explanations, which are necessary given no schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 musical concept, parameters, return values, and alternative tool. However, it omits prerequisites (e.g., need for a note track), error conditions, and example usage. Given the complexity, completeness is good but not full.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 coverage, the description compensates fully by explaining all 14 parameters, including defaults, valid ranges (e.g., velocity: 0-1), and constraints (countersubject must match subject length). 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 clearly states it creates a fugue, a specific polyphonic composition, and contrasts it with create_canon, distinguishing it from a sibling tool. The verb 'create' and resource 'fugue' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 create_canon, explaining when to use a fugue (tonal answers, countersubject) versus strict imitation. However, it does not mention other alternatives or non-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behaviors: section structure, velocity multipliers, and instrumentation per section. It states it transforms loop-based arrangements and returns sections created and energy profile. It does not mention whether it overwrites existing data or requires specific permissions, but the core transformation is well-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 well-structured: purpose statement, section breakdown, parameter explanations, examples. It is front-loaded with essential info and each sentence adds value. 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?
Given the complexity (9 params, no schema descriptions, no annotations), the description covers the main concepts and parameters. It explains the section energy progression, parameter usage, and return values. However, it lacks explanation for track indices and unit_index, which are needed for full integration.
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 explain parameters. It does well for genre, section_lengths, bpm, and root with examples and defaults. However, it does not explain bass_track, drum_track, harmony_track, melody_track, or unit_index, leaving 5 of 9 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 clearly states the tool creates a multi-section electronic track with defined sections (intro, buildup, drop, breakdown, outro). It specifies the action ('transforms loop-based arrangements into song structure') and distinguishes from siblings by limiting to electronic 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 includes usage context: 'For electronic genres only' and lists allowed genres. It provides examples with different section_lengths. However, it does not explicitly compare with sibling genre-specific arrangement tools (e.g., create_dnb_arrangement) or state when to use this generic vs. specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that layers are placed on separate tracks (e.g., pads on track 2, bass on track 1) and details defaults and skipping. However, it does not mention preconditions (e.g., whether tracks must exist) or side effects (e.g., overwriting existing data), 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: it opens with the core benefit, then lists layers, tracks, defaults, parameter definitions, and examples. While lengthy, it earns its length given the tool's complexity and 15 parameters. Minor redundancy 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?
Given the tool's complexity (15 parameters, 5 layers) and the presence of an output schema, the description covers what the tool does, how to use each parameter, and includes practical examples. However, it omits preconditions (e.g., project state) and postconditions (e.g., track creation), slightly reducing 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 must fully explain parameters. It does so comprehensively: for each parameter, it explains purpose, accepted values (e.g., arp patterns: up/down/updown/random/bass, or '' to skip), and defaults. Examples reinforce 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 creates five harmonic layers from one progression string in one call, with a specific verb ('create') and resource ('harmonic arrangement'). It explicitly distinguishes from siblings by noting it replaces five separate calls (chord_pads, arpeggiated_progression, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 it replaces 5 separate calls with a single call, implying when to use it. It provides examples for various use cases (synthwave, jazz, house, full quintet) and shows how to skip layers. However, it does not explicitly state when to prefer the individual tools, though the skip mechanism covers partial use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that it reads notes from an existing region, creates copies, and supports diatonic/chromatic intervals. It mentions default velocity and output to new/existing track. However, it does not disclose potential side effects (e.g., whether original notes are modified, destruction, or idempotency). With zero annotations, 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 brief summary, followed by a clear list of parameters with explanations. It is front-loaded with the main purpose. While it is somewhat lengthy, every sentence contributes value. Minor redundancy could be trimmed (e.g., 'interval: Harmony interval type:' is slightly repetitive), 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?
Given 8 parameters, 0% schema coverage, and an output schema, the description covers all parameters adequately and mentions return values ('Returns source notes read and harmony notes created'). It explains the process and the difference between diatonic and chromatic intervals. The output schema likely details the return structure, so the description is sufficient for an AI 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?
Schema description coverage is 0%, but the description extensively explains each parameter. For interval, it lists all valid values and their meanings (e.g., 'thirds — diatonic third above/below'). It explains velocity default (0.65, slightly quieter) and the purpose of new_unit_index (-1 creates new track). This adds significant meaning beyond the schema names and compensates fully 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's function: 'Generate harmony parts from existing notes'. It lists specific intervals (thirds, fifths, sixths, octaves) and differentiates from similar tools like create_harmony_line by focusing on fixed-interval harmony from existing notes. The verb 'create' and resource 'harmony parts' 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 usage when harmonizing existing notes: 'Reads notes from an existing region and creates harmonized copies at a fixed interval.' It does not explicitly state when not to use or provide alternatives, but the context is clear. Among siblings like create_harmony_line, this tool is for fixed-interval harmony, which is clearly indicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 key behavior (reads melody, writes harmony, stays in key, can auto-create tracks) but does not mention potential side effects like overwriting existing targets or error conditions. It is adequate but not 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 well-structured: purpose, mechanism, interval list with descriptions, use cases, parameter explanations. It is concise without unnecessary words, front-loads the core action, and uses markdown effectively for 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 main behaviors (diatonic intervals, target auto-creation, velocity scaling) and includes musical context. It lacks explicit handling of edge cases (e.g., empty source, rests) but is sufficient for a tool with output schema and clear defaults. Sibling tools are differentiated well.
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 coverage, the description explains the role of key parameters (source/target locations, interval, root_note+scale, direction, velocity_scale) with meaningful context (e.g., interval musical descriptions, default auto-create). It adds significant value 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 clearly states 'Create a harmony line from an existing melody using diatonic intervals', specifying the action, input, and method. It distinguishes from siblings by focusing on parallel diatonic harmony, unlike other harmony 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 explains when to use this tool (e.g., vocal harmonies, string pads) and outlines the intervals, but does not explicitly state when not to use it or provide alternatives. It gives good context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It explains the instrument roles, stylistic patterns, and output (notes, breakdown, style info). It does not disclose potential destructive actions or permissions, but the mutation is well-scoped.
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 instrument descriptions, style definitions, and parameter list. Each section adds value, though minor redundancy 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?
With high parameter count, no annotations, and output schema present, the description covers instruments, styles, and parameter semantics. It could mention time signature assumptions or how bars relate to beat count, 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.
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 11 parameters with detailed explanations (e.g., MIDI pitch mappings, instrument roles). 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 it creates a Korean traditional percussion ensemble (nongak/samul nori). It distinguishes from sibling tools like create_taiko_ensemble by specifying Korean instruments and styles.
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 over alternatives. While the cultural context is clear, no guidance is given on prerequisites or scenarios where other percussion tools 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.
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 fully. It explains what a montuno is, pattern types, rhythm options, and return value data. However, it does not mention side effects (e.g., whether it overwrites existing notes), performance impact, or error conditions. The disclosure 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 lengthy but well-structured with clear sections (definition, comparison, pattern types, rhythm, args). Each sentence adds value; however, some repetition could be trimmed. Overall, the structure aids readability without being 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 (12 parameters, multiple pattern types, rhythm options) and the existence of an output schema, the description covers the key aspects: creation, parameter meanings, return value summary. It could mention default chords or typical use cases more, but 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?
The input schema has 12 parameters with 0% description coverage. The description lists every parameter with its meaning, examples, defaults, and in some cases allowed values (pattern types, rhythm subdivisions). This adds substantial meaning beyond the schema and 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 it creates a montuno pattern, defines what a montuno is, and explicitly distinguishes it from arpeggiators and ostinato patterns. The verb 'create' and resource 'montuno' are specific, and the description differentiates from siblings by focusing on Latin/jazz piano ostinato 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 explains when to use the tool (for Latin/jazz piano patterns) and contrasts with arpeggiators and ostinatos, providing context. However, it does not explicitly state when not to use it or compare with specific sibling tools, though the contrast helps guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 thoroughly explains the musical behavior: rapid single alternation, flick to neighbor, return, duration within one note. It notes the return value but does not address potential side effects (e.g., overwriting existing notes) or authorization needs. Overall, it adds significant context beyond the mute 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 well-structured with paragraphs and bullet-like parameter explanations, but it is longer than necessary. Some sentences (e.g., 'Think Bach two-part inventions, Mozart sonatas') add context but could be trimmed for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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, no annotations, and an output schema (not detailed), the description covers musical behavior and parameter semantics thoroughly. It mentions the return value. However, it lacks information about prerequisites (e.g., existence of a track) and does not leverage any output schema details. Overall, 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 does so excellently, providing clear explanations for all 8 parameters: main_pitch, direction, interval, duration_beats, velocity, unit_index, track_index, start_beat. Each parameter is described with defaults and interpretation, adding meaning 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 clearly states the tool creates a mordent, defines it as a classical ornament, and distinguishes upper from lower mordents. It differentiates from siblings like create_appoggiatura, create_trill, and create_turn by specifying the ornament type and musical behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives stylistic context ('Bach two-part inventions, Mozart sonatas') but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use it or comparisons with related ornament tools, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that notes are created on a single track with two pitches and returns total notes and ratio. However, it does not disclose whether existing notes are overwritten, potential side effects, or required setup, leaving some 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 a definition, concept, parameter list, common polyrhythms table, and an example. It is front-loaded with purpose, though slightly verbose; each sentence 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?
The description covers parameters well and notes that it returns total notes and ratio (output schema exists). It lacks details on interaction with existing notes or performance considerations, but is adequate 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?
Despite zero schema description coverage, the description provides detailed explanations for each parameter, including constraints (e.g., primary_count 2-16), defaults, and examples (e.g., primary_count=3 in a 3:4 polyrhythm). This adds significant 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 'Create a polyrhythm' with a specific verb and resource, and explains the concept of polyrhythm. It differentiates from siblings like create_hemiola and create_cross_rhythm by focusing on two simultaneous subdivisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 and common polyrhythms (3:4, 2:3, etc.), implying usage for cross-rhythms. However, it does not explicitly state when not to use it or compare with similar tools such as create_metric_modulation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 clearly explains the behavioral effect (repeated notes with changing rate), defines subdivision modes, and describes parameters like velocity_decay and pitch_drift. It lacks explicit pre-conditions (e.g., track existence) 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise definition followed by a clear parameter breakdown. It is not overly verbose, but the musical context paragraph could be slightly trimmed. Still, 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's complexity (11 parameters, no annotations), the description covers purpose, all parameters, and return value via output schema mention. It lacks error handling or prerequisites, but is generally 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?
The schema has 0% description coverage, but the description compensates with a detailed 'Args' section explaining every parameter's meaning, defaults, and allowed values (e.g., subdivisions modes, max_subdivisions mapping). This adds significant value 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 clearly states the tool creates a ratchet, defines it as repeated notes with changing subdivision rate, and provides musical context. It distinguishes from sibling tools like create_trap_rolls or create_stutter by focusing on gradual acceleration/deceleration patterns.
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 accelerating or decelerating note sequences in Baroque, electronic, or drum fill contexts. However, it does not explicitly state when to use this tool over alternatives (e.g., create_stutter, create_buildup), nor does it provide when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses that it generates notes with ascending pitch and proportional velocity ramp, and returns created notes and pitch range. However, it does not specify potential side effects like overwriting existing notes or creating new tracks, which 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 one-liner purpose, detailed explanation, bulleted use cases, and parameter list. It is front-loaded and informative, though could be slightly more concise by omitting redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 9 parameters, no required ones, and an output schema (not shown), the description covers purpose, usage, parameters, and return value. It lacks details on error handling or creation behavior (e.g., if it creates a new region), but is largely 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 input schema has 0% description coverage, so the description carries full burden. It explains every parameter: unit_index, track_index, start_beat, length_beats, start_pitch, end_pitch, steps, curve, velocity. It includes defaults, valid ranges (e.g., steps 8-128, curve options), and how they affect the riser, greatly aiding 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 riser — ascending pitch sweep for build-up transitions' using a specific verb ('Create') and resource ('riser'). It distinguishes itself from siblings like 'create_buildup' and 'automation_sweep' by focusing on pitch sweeps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 lists use cases: build-ups before a drop/chorus, transitions, and tension creation. While it does not mention exclusions or alternatives, the provided context is sufficient 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.
Behavior3/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 notes created per track, defaults, and musical details, but lacks clarity on side effects like whether tracks are appended or replaced, or if new tracks are created. This 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, track breakdown, parameter list, and examples. It is informative but slightly verbose for the amount of detail, earning a 4.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 creating a multi-track arrangement, the description covers track roles, defaults, and examples. However, it omits details on track existence requirements, error handling, and exact return structure beyond 'notes created per track and total'.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 purpose, allowed ranges, defaults, and musical context (e.g., bpm range 90-160, root note suggestions). Examples 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 it creates a full rock arrangement with specific instruments (drums, bass, guitar, keys) and distinguishes from sibling tools like create_blues_arrangement by explicitly mentioning rock genre 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 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 a rock arrangement) with BPM and root note suggestions, and examples. However, it does not explicitly say when not to use it or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 core behavior (creating repeated transposed notes) and mentions the return values. However, it does not disclose whether the operation is destructive (e.g., overwrites existing notes) or requires specific track types, 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 a clear opening statement followed by detailed parameter descriptions. It is somewhat lengthy but every sentence adds value. A few parameter descriptions could be slightly more terse without losing 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 10 parameters and moderate complexity, the description covers each parameter thoroughly and explains the return value. It lacks explicit information about prerequisites or side effects, 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%, but the description adds extensive meaning to each parameter: pattern format, transposition ranges and common values, direction options, velocity decay range, etc. This far exceeds the schema's minimal titles and defaults, providing crucial 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 clearly defines the tool as creating a melodic sequence by repeating a pattern at transposed pitch levels. It uses specific verbs ('create', 'repeat', 'transpose') and resource ('melodic sequence'), and distinguishes this from sibling tools by focusing on a fundamental compositional technique with concrete 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 provides context on when to use the tool, citing musical examples (Pachelbel, jazz ii-V-I, film scores, EDM build-ups) and common transposition values. However, it does not explicitly state when not to use it or mention alternative tools among siblings, but the context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 correctly states it creates labeled markers and reduces calls, but does not disclose potential side effects (e.g., overwriting existing markers at the same positions) or required permissions. The behavioral details are adequate 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence stating purpose. It uses structured paragraphs and includes an example. However, the example could be integrated more cleanly, and the description is slightly verbose with 'enabling agents to reason about song form' which is somewhat redundant. Overall 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?
With an output schema (context signal), the description only needs to note return values, which it does ('Returns created markers with positions and total duration'). It covers both parameters adequately. Missing edge cases or error handling, but given the tool's simplicity, 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 description coverage is 0%, so the description compensates well. It explains the 'sections' parameter format (JSON array with name and bars), default bar value (8), and notes names become labels. It also clarifies 'unit_index' as unused but kept for API consistency, which adds 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 verb 'Create' and the resource 'song structure markers for arrangement (intro/verse/chorus/bridge/outro)'. It distinguishes from siblings like mcp_opendaw_add_marker (single marker) and mcp_opendaw_analyze_song_structure (analysis), making the 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?
The description implies usage by stating 'Reduces 5-10 marker calls to one structured call', guiding agents to use this instead of calling add_marker multiple times. However, it lacks explicit conditions for when not to use it (e.g., for single markers). The sibling mcp_opendaw_add_marker exists, creating a clear contrast.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It explains what each track does and the default tempo, but does not disclose side effects like overwriting existing notes, whether tracks must be empty, or error conditions. The return format is briefly mentioned.
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, then details tracks, style, parameters, and examples. It is somewhat verbose with educational asides (e.g., comparing soul to funk), but overall well-structured and 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?
Given 11 parameters, 0% schema coverage, and a complex output, the description thoroughly covers musical context, track roles, parameter constraints, and provides examples. It gives enough information for an AI agent to correctly 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%, and the description compensates by explaining most parameters (bpm range, bars multiple of 4, root, octave, track indices) with musical context. However, it omits 'velocity' and 'start_beat', which are in the schema but 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 clearly states the tool creates a full soul arrangement with specific instruments (gospel drums, melodic bass, Rhodes chords, horn stabs) across 4 tracks. It distinguishes from sibling arrangement tools by explicitly referencing the soul genre and artists like Otis Redding and Aretha Franklin.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 stylistic context for when to use this tool (slow soul groove at 72 BPM, I-IV-vi-V progression) and compares it to funk and pop to differentiate. However, it does not explicitly state when not to use it or mention alternative tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool copies position, value, and interpolation, can offset position, override value, and returns the new event's position and value. This provides sufficient behavioral context, though it does not mention side effects 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear opening, followed by behavioral details, parameter explanations, and return value. It is well-structured and avoids superfluous text, though it could be slightly tighter by combining some lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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, the description explains all parameters and the return value, matching the output schema. It does not address error conditions or prerequisites, but for a duplication tool with an output schema, it 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?
The input schema has 0% description coverage, but the description explains each parameter: coordinates (unit/track/region_index), event_index, position_offset as PPQN offset, value_override with range 0-1 and omission behavior. This adds significant meaning beyond the bare schema 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 clearly states 'Duplicate an automation event within the same region,' specifying the exact action and resource. It further explains that it copies position, value, and interpolation, distinguishing it from sibling tools like create, update, move, or delete.
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 (to duplicate an automation event) but does not explicitly state when not to use it or provide alternatives. While the purpose is clear, explicit usage guidance would help the agent decide between similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that it stops all notes immediately, which is a destructive action. However, it doesn't mention side effects, reversibility, or if it affects engine state beyond stopping notes. Minimal but functional.
Agents need to know what a tool does to the world before 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 action. No filler. 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?
Simple tool with no parameters and output schema present. Description explains core function and use case. Could add more on safety or calling frequency, but sufficient for an emergency stop.
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?
Input schema has zero parameters, so description doesn't need to add parameter info. Baseline score for no parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sends a panic signal to stop all notes immediately. Explicitly mentions use cases like hanging notes and frozen synthesis, and equates to a MIDI panic button. Distinguishes from sibling tools like engine_sleep or engine_wake.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use ('when audio gets stuck'). Lacks explicit when-not-to-use or alternatives like engine_sleep, but the analogy to a MIDI panic button implies emergency use. Clear enough 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions suspending audio processing to save CPU but does not disclose side effects like whether playback stops or state is preserved. Adequate but 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?
Two concise sentences with no wasted words. Purpose is front-loaded, and usage context follows 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?
For a simple no-parameter tool with an output schema, the description covers the essential behavior and use case. Could optionally mention output, but not required per rules.
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?
No parameters exist, and description does not need to add param info. Baseline 4 for 0 parameters; no compensation 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?
Clearly states the action (put to sleep) and resource (audio engine) with a specific verb. Distinguishes from siblings like engine_wake and other audio processing 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?
Explicitly mentions when to use (non-audio operations to save CPU) and the wake() alternative for resuming. Lacks explicit 'when not to use', but the positive use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It explains that notes are moved to the nearest in-scale note, details direction and preserve_octave behavior, and mentions the return value. It does not explicitly state whether the operation is destructive or replaces the region, but the description implies modification. Overall, it provides sufficient transparency 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 concise and well-structured. It opens with the core purpose in a single line, followed by a brief explanation, then parameter details, and finally the return value. Every sentence adds value, and the structure is front-loaded 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?
Given the lack of annotations and the tool's moderate complexity (7 parameters, no nested objects), the description covers the essential behavior and return values. It explains the effect, parameter options, and expected output. The only minor gap is the missing documentation of the indexing parameters, but overall it is complete enough 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.
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 explain parameters. It covers root_note, scale, direction, and preserve_octave with clear explanations. However, it does not describe unit_index, track_index, or region_index, which are present in the schema. This leaves 3 out of 7 parameters undocumented, meaning the description only partially compensates for the lack of 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 purpose: 'Force all notes in a region into a specific scale — harmonic snap.' It explains the action (finds out-of-scale notes and moves them) and compares it to quantize_notes, distinguishing it from siblings like quantize_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?
The description explicitly recommends use cases: 'Useful after audio-to-MIDI transcription, random generation, or importing MIDI from unknown sources.' It also draws an analogy to quantize_notes, helping the agent understand when this tool is appropriate. However, it does not explicitly state when not to use it or list alternatives, leaving a small gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, so the description's role is to add behavioral detail. It states the return values ('bar_start, bar_end, bar_length, and time signature'), which goes beyond the annotation. It does not mention any side effects or contradictions. The description aligns with the read-only nature and adds transparency about the output.
Agents need to know what a tool does to the world before calling it. Descriptions 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 (three sentences) and well-structured: first sentence states the core function, second gives usage context, third details parameter and return. It is front-loaded with the most important information and contains no unnecessary 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 query tool with an output schema, the description covers all necessary aspects: purpose, usage, parameter explanation, and return values. The tool's complexity is low, and the description 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.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'position_ppqn' is explained as 'Position in PPQN', which adds minimal meaning beyond the parameter name. The schema has 0% description coverage, so the description should provide more context, such as expected range or format. Without that, the agent must infer what PPQN values are valid. The description adds little value 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 states the tool's purpose: 'Get the start and end PPQN of the bar containing the given position.' This is a specific verb-resource combination. It also mentions a use case ('snapping regions, clips, and events to bar boundaries'), which differentiates it from sibling tools like mcp_opendaw_get_tempo_at or mcp_opendaw_get_region_info that also provide positional info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 suggests when to use the tool: 'Useful for snapping regions, clips, and events to bar boundaries.' This provides clear context for usage. However, it does not explicitly state when not to use it or mention alternative tools, which would have warranted a 5. The usage guidance is implied rather than exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, confirming the tool is read-only. The description adds value by detailing the output: 'ordered list of MIDI effects with type, enabled state, and index', which goes beyond the structured 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?
The description is extremely concise: two sentences for purpose and a single line for the parameter. Every word is necessary, no redundancy, and it is front-loaded with the core 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?
The tool is simple with one parameter and an output schema exists. The description covers the return content and parameter meaning. It lacks notes on edge cases (empty chain, invalid index), but given the output schema, it is sufficiently complete for an AI agent to use 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 has 0% description coverage, but the description explains 'unit_index: Audio unit index.' This adds essential context beyond the schema's type-only definition, effectively compensating 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 verb 'Get', the resource 'MIDI effect chain', and the context 'for an audio unit'. It distinguishes from siblings like 'get_effect_chain' by specifying 'MIDI', making the purpose precise 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 does not explicitly guide when to use this tool versus alternatives such as 'list_midi_effects' or 'get_effect_chain'. While the name and context imply usage for a specific audio unit's MIDI effects, there is no when-not or comparison to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates read-only. The description adds that it returns an error if the effect is not a NeuralAmp or has no model loaded, and returns empty if no model loaded, providing useful behavioral details 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: purpose, return behavior, parameter definitions. 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?
The tool is simple with two parameters, and the description covers the return value (string or empty) and error cases. With output schema present, 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?
The input schema has no descriptions (0% coverage), but the description briefly defines each parameter ('unit_index: AU index', 'effect_index: Effect index'), adding meaning beyond the bare 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 it gets the NeuralAmp model JSON for a specific effect, using a specific verb and resource. It distinguishes from the sibling tool 'set_neuralamp_model' which modifies the model.
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 retrieving model data, but does not explicitly state when to use this tool versus alternatives. It does mention error conditions (not a NeuralAmp, no model loaded) which provides some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 extraction and application process: 'Extracts the groove template... then applies this template to destination notes — shifting their timing and scaling velocity.' However, it does not specify whether the operation is destructive or reversible, nor does it mention the effect on the source region. The mention of return values (groove template stats) adds some 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, starting with a high-level summary, then detailing the process, and finally listing parameter explanations. While it is somewhat lengthy, every sentence adds value. A slightly more compact format (e.g., table for parameters) could improve conciseness, but it remains clear 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 10 parameters and the presence of an output schema, the description covers all parameters thoroughly and explains the non-obvious concept of groove cycle. It mentions return values. However, it lacks discussion of prerequisites (e.g., must have notes in source region) and edge cases (e.g., groove_length exceeding region length), leaving 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 input schema has 0% description coverage, so the description fully compensates by providing detailed explanations for all 10 parameters. It includes concrete examples (groove_length: '4 = 1 bar of 4/4, 3 = waltz, 2 = half-bar'), ranges (timing_strength: 0-1), and allowed values (grid: '16th' or '8th'). This adds significant meaning 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 clearly states the tool's purpose: 'Transfer groove (timing + velocity feel) from a source region to a destination region.' It distinguishes this from copying notes by explicitly stating 'This is NOT copying notes — it transfers the *feel*.' The example of applying a 1-bar drum groove to a 4-bar pattern further clarifies 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 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 this tool by explaining the concept of groove transfer and contrasting it with note copying. It gives an example scenario (1-bar groove to 4-bar pattern). However, it does not explicitly list alternatives or state when not to use it relative to sibling tools like apply_swing or humanize_notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds that the tool returns current values and provides the return structure (names, values, units, constraints), which is 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 four sentences with no unnecessary words. It frontloads the purpose, then explains parameters, then describes the return. 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 an output schema, the description correctly notes what is returned (names, values, units, constraints). It covers the purpose, parameters, and output, though it could mention prerequisites (e.g., the effect must exist).
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 clear explanations for both required parameters: 'unit_index: Audio unit index.' and 'effect_index: MIDI effect position in the chain (0-based).' This adds 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 clearly states the action ('list all parameters') and the resource ('a MIDI effect with current values'). It distinguishes itself from sibling tools like 'list_effect_parameters' (likely audio effects) and 'list_midi_effects' (list 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the parameters and their roles, but does not provide explicit guidance on when to use this tool vs. sibling list tools. Usage is implied by the tool name and parameter descriptions, but no alternatives 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates no side effects. The description adds value by listing return fields and explaining parameter semantics, 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 concise: one line for purpose, two lines for parameters, one line for return fields. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers action, parameter behavior, and return fields adequately. No missing context given the output schema exists externally.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 both parameters: unit_index as audio unit index with -1 for all, and track_index as note track with -1 for all, providing complete meaning.
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 'List all note regions' with specific data fields (position, duration, note count). It is clear but does not explicitly differentiate from sibling tools like 'list_notes' or 'list_audio_regions'.
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 parameter usage (e.g., -1 for all) but provides no guidance on when to use this tool vs. alternatives, such as 'list_notes' for individual notes or 'list_audio_regions' for audio regions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description confirms a read-only operation. Additionally, it specifies the return fields (send_index, target_bus_name, send_level_db, routing), providing behavioral detail 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 extremely concise: three short lines covering purpose, parameter, and return fields. No redundant information, ideal for quick parsing by an AI.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 a simple read-only operation and one parameter, the description is largely complete. It covers the return format explicitly. No major gaps, though it could mention that the operation is safe (covered by annotation).
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 single parameter `unit_index` is explained as 'Audio unit index to inspect,' adding clear meaning beyond the raw schema (integer type). This helps the agent understand what value to 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 states 'List all aux sends on an audio unit,' clearly specifying the verb (list), resource (aux sends), and scope (on an audio unit). It distinguishes from sibling tools like create_send or remove_send, which are for modification.
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 on when to use this tool vs alternatives. The description implies it is for inspection, but does not mention when not to use or compare to other list tools like list_audio_buses. However, the purpose is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the readOnlyHint annotation, stating it lists markers. It adds value by describing the return format ('array of transient positions (in samples) or empty if none'), providing behavioral insight beyond the annotation alone.
Agents need to know what a tool does to the world before calling it. Descriptions 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 only three sentences plus a parameter explanation. It is front-loaded with the purpose, contains no redundant information, and 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 that an output schema exists, the description adequately covers purpose, parameter meaning, and output format. It mentions the possibility of an empty return. However, it does not address prerequisites like ensuring the region exists, and the sample unit could be clarified.
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% description coverage, so the description must compensate. It explains that 'unit_index/track_index/region_index: Audio region coordinates,' adding meaning to the parameters. However, it does not specify valid ranges or how to obtain these indices, leaving some 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 verb 'List' and the resource 'transient markers for an audio region's audio file'. It explains what transient markers are (auto-detected hit points) and provides use cases (beat slicing, groove extraction), effectively distinguishing this tool from general list_markers 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 mentions the tool is 'Useful for beat slicing and groove extraction,' which implies when to use it. However, it does not explicitly state when not to use it or provide direct alternatives among siblings. The context is clear 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.
Behavior4/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 reveals the algorithm (ITU-R BS.1770-4 simplified), the measurement steps (K-weighting, gating), and the specific return values (LUFS, true peak, max sample, duration). This goes beyond typical descriptions.
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 first sentence stating purpose, followed by algorithm details, parameter explanation, and return values. However, the algorithm details (e.g., K-weighting coefficients, gate threshold) may be excessive for an AI agent and could be streamlined for better 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 low complexity (single parameter, no nested objects, no output schema but return values listed), the description is fully complete. It explains what the tool does, how it works, what input it needs, and what output to expect. No 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?
The input schema has one parameter (filename) with no description. The tool description adds critical context: 'Name of the WAV file in the exports directory (without path).' This clarifies the file location and format, which is not evident from the schema alone. Schema coverage is 0%, so the description 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 measures LUFS (integrated) and true peak of an exported WAV file, with a specific verb ('Measure') and resource ('WAV file'). It distinguishes itself from sibling analysis tools (e.g., analyze_dynamics, analyze_mix) by focusing on loudness metrics per ITU-R standard.
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 algorithm details but does not explicitly state when to use this tool versus alternatives. It lacks guidance on prerequisites (e.g., file must be exported first) or exclusions (e.g., not for real-time monitoring). Usage context is only implied by the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description thoroughly explains the behavioral algorithm: scanning sorted notes, merging based on pitch and gap, and handling the `same_pitch_only` flag. It does not mention whether the operation is destructive or reversible, but given no annotations, the description provides good insight into what the tool does.
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 statement followed by algorithm explanation and parameter details. It is slightly verbose but front-loaded with the most important information, making it easy for an AI agent to understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 and the merge algorithm comprehensively. It does not mention error conditions, preconditions (e.g., notes must exist), or undo behavior. An output schema exists, so missing return value explanation is acceptable. Minor gaps 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?
Despite 0% schema description coverage, the tool's description includes a detailed 'Args:' block that explains each parameter's meaning, including `max_gap_beats` with examples (0.0, 0.25, 1.0) and `velocity_mode` options ('first', 'last', 'max', 'avg'). This adds significant value beyond the JSON 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: 'Merge consecutive notes of the same pitch into single sustained notes.' It explains the scanning logic and distinguishes from sibling tools like merge_note_regions and merge_note_tracks by focusing on same-pitch consecutive 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 description provides context for use: 'Useful for cleaning up repeated hits, converting staccato patterns to sustained notes, or simplifying busy passages.' However, it does not explicitly state when not to use it or compare with alternatives such as merge_note_regions or merge_note_tracks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes returned data comprehensively but does not explicitly state it is read-only or disclose potential side effects. For a read-only analysis tool, this is adequate but not exceptional.
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?
Well-structured: concise summary, bullet list of statistics, practical use cases, parameter details, and example. Some repetition (e.g., 'statistics object' in multiple places) but overall efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and presence of output schema, the description thoroughly covers purpose, returned data, parameter roles, and usage examples. Includes edge case for region_index default. No gaps for agent 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?
Schema description coverage is 0% (no descriptions in schema), but the description adds meaningful explanations for each parameter: 'unit_index: AU index', 'track_index: Note track index', 'region_index: Region (-1 = first region)'. Includes an example call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 specific verb 'Get comprehensive statistics' and resource 'notes in a region'. Clearly distinguishes from sibling analysis tools (e.g., audio analysis tools) by explicitly listing MIDI-specific statistics like pitch class histogram, velocity stats, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 'Useful for' section with concrete scenarios (analyzing imported MIDI, comparing regions, identifying register, detecting robotic velocities). While it doesn't explicitly state when not to use it, the use cases are clear and practical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains chance semantics (0-100%), mode behaviors, and return value (per-track note counts). However, it does not state whether the operation is destructive or reversible, nor if it overwrites or adds to existing chance values.
Agents need to know what a tool does to the world before calling it. Descriptions 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, mode details, parameter list, and examples. Every section adds value without unnecessary repetition. Front-loads the key concept and 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?
Given 7 parameters, no annotations, and an output schema, the description covers the core functionality well. It explains chance, modes, parameters, return value, and provides examples. Missing explanation for index parameters is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (description does not replicate schema), but the description adds detailed meaning for 4 of 7 parameters (mode, min_chance, max_chance, seed) through explanations and examples. It does not explain unit_index, track_index, or region_index, which are common across 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 'Randomize note playback probability (chance) — generative variation' and elaborates with specific use cases (ghost notes, generative melodies, etc.). It distinguishes this tool from siblings like randomize_note_durations by focusing on chance/probability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 lists 'Perfect for:' scenarios (ghost notes, generative melodies, etc.) and details each mode with its intended effect (e.g., 'sparse' for ghost notes). While it lacks an explicit 'when not to use', the guidance is strong and contextual.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses the engine used, the absence of stems configuration, the full project range, and the return value (path and audio metadata). This is reasonably transparent for a render operation, though it does not mention potential side effects or errors.
Agents need to know what a tool does to the world before calling it. Descriptions 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 two short paragraphs. The first sentence clearly states the purpose, followed by parameter explanations and technical details. Every sentence adds value without unnecessary 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 presence of an output schema (has_output_schema: true) and two simple parameters, the description is largely complete. It explains the rendering scope, engine, and return value. Minor details like error handling are absent but not critical for a straightforward render tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by explaining both parameters: filename (without .wav extension) and sample_rate (with default 48000). This adds meaning beyond the schema's titles and defaults, making the tool easier to use 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 renders the entire project as a single stereo WAV file (full mixdown). The verb 'render' and resource 'entire project' are specific, and it distinguishes from siblings like render_and_analyze or render_range by emphasizing full mix without stems.
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 technical approach (OfflineEngineRenderer with Option.None) and the rendering range (beat 0 to end of last region), but does not explicitly state when to use this tool versus alternatives like render_full_song or render_full_format. Usage context 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavior. It explains the swapping action and optional preservation of effects/timeline, but does not detail side effects (e.g., whether the preset is consumed, if the unit is modified in place) or error conditions beyond 'success or error'. The output is not described, though an output schema 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 well-structured: a one-sentence summary, a technical reference, a precondition, and a clean parameter list. It is concise with no wasted words, 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?
Given the tool's complexity (5 parameters, no annotations, many siblings), the description covers the essential: purpose, parameters, precondition. It is sufficient for an agent to invoke the tool correctly. However, it could provide more detail on the return value (though an output schema exists) and error scenarios.
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 does so by providing clear, contextual explanations for each parameter: unit_index ('Target AU index'), preset_b64 ('Base64 preset bytes from export_preset'), and the three boolean keep flags with their effects. This adds meaning 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 action ('Replace an audio unit's instrument/effects/timeline from a preset'), specifies the method (Uses PresetDecoder.replaceAudioUnit), and distinguishes from generic replace tools by emphasizing preset-based replacement. It also notes compatibility constraints (MIDI→MIDI, Audio→Audio).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool: when replacing an audio unit's instrument from a preset while optionally keeping certain elements. It specifies a precondition (compatible instrument type), but does not explicitly mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It explains encoding using PresetEncoder.encodeEffects() but does not disclose side effects, error conditions, or permission requirements. Adequate but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, front-loaded with main action, then encoding detail, usage, and parameter list. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, encoding, usage, and parameters. Lacks info on validation or format requirements (e.g., .opb extension), but output schema exists so return values are covered.
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 description adds one-line explanations for all 5 parameters, clarifying their roles beyond the schema's type 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 clearly states the verb 'Save' and resource 'audio effect chain as .opb preset file'. It distinguishes from sibling tool mcp_opendaw_load_effect_preset which loads presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for usage: sharing, drag-and-drop, or loading via load_effect_preset. Lists required parameters but does not explicitly exclude alternative save tools like export_preset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 controls duration interpretation, changes are reversible by re-setting, and it returns old and new time base. It adds valuable 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 structured with a purpose statement, then detailed explanation of time base modes, followed by parameter list. It is relatively concise with no redundant sentences, though it could be slightly more 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 presence of an output schema (not shown) and the tool's straightforward nature, the description adequately covers purpose, parameters, return value, and semantics. It provides sufficient context for an agent 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.
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 providing clear, concise explanations for each parameter: unit_index, track_index, region_index, and time_base with valid values. 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 clearly states 'Set the time base of an audio region' with specific verb and resource. It explicitly explains the two options and their effects, making it highly distinguishable from sibling tools, many of which are other set_* operations.
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 when to use each time base value ('musical' vs 'seconds') with clear effects. However, it does not provide explicit guidance on when not to use this tool or mention alternatives, relying on implied usage from the parameter descriptions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses the tool modifies clip state, allows skipping parameters, and returns updated values. This is sufficient for a setter, though it doesn't discuss error handling 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 well-structured: an introductory sentence, explanation of ClipPlaybackFields, how to skip parameters, and a parameter list. It is succinct without being overly verbose, though it could be streamlined slightly.
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 mentions returns of updated playback values, which helps with completeness. However, it lacks details on error conditions, such as invalid indices or clip not found. Given the tool has 6 required parameters and no output schema, the context is adequate but not fully robust.
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 coverage (the description does not echo schema titles verbatim), it adds meaning by explaining each parameter: unit_index as audio unit index, clip_index from list_clips, and the meaning of loop, reverse, speed. This goes beyond the schema's minimal 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 sets clip playback parameters (loop, reverse, speed) on a clip, using a specific verb-resource structure. It distinguishes from siblings like set_clip_mute or set_clip_hue by focusing on playback-specific 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?
The description explains how to skip parameters by passing None and defines indices (unit_index, track_index, clip_index). While it doesn't explicitly compare to alternatives like schedule_clip_play, the context is clear enough for an agent to identify 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It explains that it sets boolean parameters but does not disclose side effects, permissions, or immediate audio processing impact. While straightforward, more detail on behavioral implications 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 front-loaded with the main purpose and includes a bullet list of device fields and parameter explanations. It is reasonably concise, though the device list could be slightly condensed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 simplicity of the tool, the description covers purpose, usage, and parameters adequately. It has an output schema (content not shown) so return values are handled. Minor gaps like case-sensitivity of parameter_name, but overall 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 description fully compensates. All 4 parameters are explained with examples, and parameter_name is enriched with a list of valid boolean fields per device type. This provides significant 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 'Set a boolean parameter on an audio effect' and distinguishes from sibling tools by explicitly covering 'device-specific boolean fields not exposed through the generic float setter'. It provides specific examples per device 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 indicates when to use: for boolean fields not covered by the float setter. It implies alternatives (generic float setter) but does not explicitly state when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 tool returns 'old and new minimized state', which is helpful. However, it does not mention any potential side effects (e.g., whether minimizing affects audio processing) or prerequisites (e.g., unit 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 very concise: a one-line purpose, a brief use case, parameter explanations, and return value. Every sentence adds value; 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 has an output schema (not shown) and the description mentions the return values. For a simple toggle operation, this is sufficient. It could mention that the unit must exist, but that is likely implicit.
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 adds meaningful explanations for both parameters: 'unit_index: AU index' and 'minimized: True to minimize, False to expand'. This goes 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 action ('Minimize or expand an audio unit in the mixer view') and the resource (audio unit). It distinguishes from sibling tools like freeze_audiounit or move_audio_unit by focusing on the visual minimized 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 explains when to use this tool ('useful for decluttering when working with many tracks'). It does not explicitly mention alternatives or when not to use, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 shuffle behavior and parameter effects but does not disclose that it modifies the region in place, whether it's undoable, or other side effects. The description adds value but lacks full 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 well-structured with a purpose statement, mode explanations, and an Args list. It is front-loaded and efficient, though the Args section could be slightly more concise by avoiding repetition of defaults. Overall clear 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 (9 parameters, no annotations), the description covers all relevant aspects. It mentions reproducibility and differentiates from a key sibling. The existence of an output schema means return values need not be explained. Could be slightly more complete by noting that the shuffle modifies the region directly.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 compensates thoroughly by explaining all 9 parameters, including mode options and their musical implications, seed reproducibility, and the meaning of shuffle_amount and preserve flags. This exceeds the baseline of 4 for no 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 'Shuffle note data randomly within a region' and contrasts with rotate_notes, making the purpose and differentiation explicit. It uses a specific verb (shuffle) and resource (note data in a region), and distinguishes from a 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 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 different modes (e.g., 'Most musical — generates melodic variations' for pitches) and mentions reproducibility with seeds. However, it does not explicitly state when not to use or compare with other randomization siblings like humanize_notes or randomize_note_chance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains how notes are removed and that musical intent is preserved, but it does not disclose whether the operation is destructive or non-destructive (e.g., if it modifies the original region or creates a new one). With no annotations provided, the description carries the full burden for behavioral transparency, and this gap 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 well-structured with a clear introductory sentence, contextual explanation, strategy breakdown, parameter descriptions, and an example. It is appropriately sized for the complexity. Minor redundancy (e.g., repeating parameter explanations) prevents 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?
The description covers purpose, use cases, strategies, parameters, and return values. It lacks explicit edge case handling (e.g., no notes matching criteria) but otherwise provides a complete picture for an agent to invoke the tool correctly. The presence of a return value description compensates for the lack of an output schema in the input.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 provides extensive, detailed explanations for all 8 parameters, including their purpose, valid ranges, and defaults. It also explains the three strategies in depth, significantly adding 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 the tool's purpose: 'Thin out notes in a region — reduce note density for cleaner patterns.' It provides specific context (after AI generation, transcription, dense arrangement) and outlines three distinct strategies. No sibling tool overlaps with this precise functionality, making it easily distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 (after AI generation, transcription, dense arrangement) and implies the need for a region with too many notes. It does not explicitly state when not to use it, but the context is clear. Given the specificity of the tool, this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details the specific checks, explains the significance of low vs high frequency phase issues, and describes the input parameter, providing rich 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 with a clear opening summary and bullet points, front-loading key information. It is slightly verbose but not excessively so.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 single parameter and existence of an output schema, the description covers input details, analysis specifics, and return type. It is mostly complete but could mention file format restrictions beyond WAV.
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 adds essential meaning by specifying that the filename must be a WAV file in the exports directory or an absolute path, which the schema alone does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs per-band phase analysis, enumerating specific checks (coherence, polarity, delay, mono compatibility) and distinguishes it from sibling analysis tools by focusing on phase and mono issues.
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 diagnosing phase problems and mono compatibility but does not explicitly state when to use this tool over alternatives like analyze_stereo or analyze_spectrum, nor does it provide exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the deterministic nature, how each articulation reshapes durations, and what the tool returns. Missing potential side effects but still thorough.
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, parameter details, and examples. It is appropriately sized for the tool's complexity, with no redundant 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?
Given 5 parameters, no annotations, and output schema present, the description covers all major aspects: parameter meanings, articulation behaviors, and return value. Minor omissions like error handling, but sufficiently complete for an 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 coverage is 0%, so description compensates well. It explains each parameter with defaults, ranges (e.g., amount 0-1), and effects per articulation type. Examples 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 applies articulations (staccato, legato, tenuto, accent) to existing notes, with a specific verb and resource. It distinguishes from siblings like velocity_curve and humanize by explaining it applies deterministic duration ratios.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 this tool, including comparisons with alternatives (velocity_curve, humanize). It gives examples of articulation usage but does not explicitly state when not to use it, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the chain assignment per track and genre-aware style selection, and notes it returns a summary. However, it does not disclose whether existing chains are overwritten or merged, which is a key behavioral detail for a composite operation. With no annotations, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions 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 clear sections, bullet points for genres and track assignments, and an example call. Every sentence adds 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 complexity (4 parameters, composite operation), the description covers the overall purpose, parameters, track mapping, and provides an example. It is mostly complete but lacks information about whether existing chains are cleared or merged.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 all 4 parameters: genre with a list of 15 supported styles, unit_index as target audio unit, num_tracks with track-to-chain mapping, and master_lufs with concrete examples like -14 for Spotify. This provides significant additional 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 it applies a complete mix in one call with genre-aware processing chains on every track plus mastering. It explicitly contrasts with separate chain addition tools like add_drum_chain and add_bass_chain, providing strong purpose differentiation 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 explains that this tool replaces 5-6 separate calls and details when to use it for full mixing. It does not explicitly state when not to use it (e.g., for per-chain adjustments), but the context strongly implies the composite use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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: generates multiple interpolation points, auto-creates automation track, and returns event count and preview. It does not mention potential overwriting of existing automation, but it 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized with a header, parameter descriptions, return info, and an example. While it is somewhat lengthy, all sentences are relevant and the structure aids readability. Minor redundancy could be trimmed, but it remains 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 complexity (8 parameters, output schema exists), the description is complete. It covers all parameters, explains return values ('number of events created and a preview'), and provides an example. The existence of an output schema reduces the need for detailed return value 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%, so the description must compensate. It explains all 8 parameters with details: unit_index, parameter_name, start_beat, end_beat, start_value, end_value, steps (default 16), and curve ('linear', 'exp', 'log'). The example further clarifies usage. This 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 the tool's purpose: 'Create a smooth automation sweep (ramp) between two values over a beat range.' It specifies the verb (create), resource (automation sweep), and differentiates from siblings like add_automation by emphasizing interpolation and multiple 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 provides an example but lacks explicit guidance on when to use this tool versus alternatives like add_automation or create_filter_sweep. Usage is implied through context, but no when-to-use or when-not-to-use instructions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description transparently covers key behaviors: runs three checks per stem, phase analysis for stereo files only, returns a triage report with severity levels. It does not mention side effects or permissions, but for a read-only diagnostic, this is acceptable.
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 first, then steps, output format, parameter details, and an example. It is slightly verbose but 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?
For a complex batch diagnostic tool, the description covers the main functionality, parameters, output triage levels, and stereo-only constraint. It could mention file availability or size limits, but overall it is complete enough.
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 adds critical meaning: filenames accepts JSON array or comma-separated WAV list, genre is optional with examples (pop, rock, lo-fi). An example usage clarifies expected input 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 explicitly states the tool runs a full diagnostic on multiple stems including problem detection, phase analysis, and profile comparison. It clearly distinguishes from sibling tools like detect_problems and analyze_phase by batching these operations 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 tool is a batch equivalent of Phantom's diagnostic, but does not explicitly state when to use this over individual analysis tools. However, the detailed output structure and prioritized triage report implicitly guide usage for comprehensive batch diagnostics.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that existing signature change events are recalculated to preserve approximate absolute positions, and details parameter meanings, but does not mention potential failure modes 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 concise, starting with a clear summary, then providing necessary details and parameter explanations without extraneous 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 mutation tool with two parameters and an output schema, the description covers the main behaviors and parameter usage adequately, though a note on return format could be added.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds explicit meaning to both parameters (nominator and denominator) with examples and valid values, compensating for the 0% schema description coverage effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'change' and resource 'base time signature of the project', and distinguishes from siblings like 'add_signature_change' by specifying it alters the initial signature and recalculates existing 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 explains the effect on existing events and that this changes the base signature, but does not explicitly state when to use this tool versus alternatives such as 'add_signature_change' or 'set_time_signature', leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 underlying API call and states removal of tracks with no regions, but does not detail destructiveness, reversibility, or permissions. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with a blank line separating purpose from parameter explanation. Every sentence adds value; no wasted words. Front-loaded with the primary 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 cleanup tool with one parameter and an output schema, the description provides sufficient context. It explains the operation and parameter meaning. Could mention return details, but output schema likely covers 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?
The schema has no parameter descriptions (0% coverage). The description fully explains the sole parameter: 'unit_index: Audio unit index (-1 = all AUs).' This adds crucial meaning beyond the schema's title, making the tool easy 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?
The description clearly states the verb 'Remove empty tracks' and the resource 'from an audio unit (or all AUs)'. It specifies 'removes tracks with no regions', making the purpose unambiguous and distinct from siblings like 'delete_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 usage context: 'Useful cleanup after deleting regions or editing.' This implies when to use it, though explicit alternatives or when-not-to-use guidance is missing. 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It explains that the copy includes all content (notes, audio, automation events), mentions optional position, and states return values (new position and duration). It doesn't mention side effects or constraints, but for a copy operation, key behaviors 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 lean and well-structured: purpose statement, supported types, parameter list, and return value. Every sentence adds value without redundancy. Front-loaded with the core 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 6 parameters and no annotations, the description adequately covers parameters and return. It doesn't address error handling or preconditions (e.g., region existence), but the output schema documents return values. It is sufficiently complete for a copy 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 has 0% description coverage, so description must compensate. It explains each parameter's role ('src_unit/src_track/src_region: Source region coordinates', 'position: New position in PPQN'), adding crucial semantics beyond 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 clearly states 'Copy a region to a different track (or same track at new position),' specifying action (copy) and resource (region) with target (track). It distinguishes from siblings like 'move_region_to_track' and 'copy_notes_to_track' by implying a full region copy including all content 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 mentions region types (note, audio, automation) implying generality but does not explicitly contrast with alternative tools like 'copy_notes_to_track'. No direct when-to-use or when-not-to-use guidance is provided, leaving inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses upsert behavior, interpolation types, and parameter constraints. It mentions return info/error. However, it omits side effects, undo capability, or permission needs, which would enhance transparency. Nonetheless, it covers the core behavior well.
Agents need to know what a tool does to the world before calling it. Descriptions 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 (6 sentences) with clear front-loading of purpose, then behavior, then parameter explanations. Every sentence adds value; 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 tool's complexity (6 params, output schema present), the description adequately explains behavior and parameters. It mentions return value. It could be more complete by including error scenarios or examples, but it is sufficient 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?
Schema coverage is 0%, so description must document parameters. It explains all 6 parameters: unit_index, track_index, position_beats, value, interpolation (with options), and curve_slope (when used). Defaults and valid values are given, fully compensating for absent 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 action: 'Create a single automation event at a specific position on a value track.' It specifies the resource (automation event) and its location (value track, position). This distinguishes it from siblings like 'add_automation' (likely bulk) and 'update_automation_event' (update only), as it covers both create and update (upsert behavior).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for single-point automation manipulation and mentions upsert, but does not explicitly compare with siblings like 'add_automation' or 'update_automation_event'. No guidance on when to use this tool over alternatives or prerequisites for unit_index/track_index.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains the algorithm, that it reads notes and creates new ones, and returns counts. It does not mention side effects (e.g., non-destructive read) but is otherwise thorough.
Agents need to know what a tool does to the world before calling it. Descriptions 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: concept overview, then parameter list, then return note. It is concise (about 150 words) and front-loaded with 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?
Covers algorithm, parameters, and return values. Missing preconditions (e.g., source track must have notes) and edge cases. Output schema exists but description mentions return structure anyway.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must explain all 7 parameters. It does so with clear explanations (e.g., interval default and usage, velocity quieter, new_unit_index -1 means new track).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 and resource: 'Generate a counter-melody in contrary motion to existing notes.' It explains the concept and distinguishes from siblings like create_canon or create_fugue.
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 wanting contrary motion counterpoint but does not explicitly state when to use this vs 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.
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 discloses the step-sequencer notation format, default unit_index behavior, and return value (notes created per lane). However, it does not state whether it is destructive or additive, or prerequisites like needing a drum 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 with an opening sentence, parameter details, notation legend, and example. It is front-loaded with purpose. Only minor redundancy (the example could be shorter).
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 creating a drum pattern, the description covers all essential aspects: input format, notation, unit_index, and output. The output schema exists and the description mentions return value sufficient for the 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?
Schema description coverage is 0%, but the description fully explains the pattern parameter (JSON object, lanes, step characters) and unit_index parameter (default -1, finds first AU with note tracks). This adds significant meaning beyond the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('create') and resource ('drum pattern') with unique compact notation. It clearly states it replaces 10-20 note creations, distinguishing it from siblings like create_drum_fill or create_boom_bap.
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 efficient drum pattern creation but does not explicitly state when to use this tool versus alternatives such as create_drum_fill or create_four_on_floor. No when-not or alternative guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses creation of a track with synth, beat, mix and indicates return values (AU indices, note counts, suggested next steps). However, it does not explicitly state that a new track is added to the project, 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, a bullet-like list of genres, a line for bpm, and a returns note. It is concise with no unnecessary 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?
The description mentions return values, which is good given an output schema exists. However, it could be improved by explicitly stating that a new track is added to the project. Overall, it is complete for a simple creation tool but has 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?
The schema provides only 'string' and 'number' types, but the description adds detailed genre definitions with musical content for each option and clarifies bpm as an override with default per genre. With 0% schema coverage, the description fully compensates and adds significant 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 'Create a genre-specific starting track with synth, beat, and basic mix — one call builds a full section.' It uses a specific verb+resource and distinguishes itself from siblings like create_genre_sections and create_full_genre_pipeline by emphasizing the one-call full section creation.
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 on what genres are available and bpm override but lacks explicit guidance on when to use this tool versus alternatives like create_genre_sections or create_full_genre_pipeline. It does not state prerequisites or exclusions, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the musical behavior (what notes are created on each track, patterns, scales). It notes return value ('notes created per track and total'). However, it does not specify whether existing notes on those tracks are overwritten or if the operation is additive, nor does it mention 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 well-structured with bullet points for tracks, clear parameter explanations, and examples. It is slightly verbose but every sentence adds value. It is front-loaded with purpose and provides a mix of technical and musical 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 complexity (11 parameters, 0% schema coverage, no annotations), the description covers the arrangement structure, track roles, scale theory, tempo implications, and parameter constraints (e.g., bars must be multiple of 4). It provides examples. Missing is explicit documentation of error cases or idempotency, but the output schema likely covers return details.
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 description must compensate. It explains musical purpose for key parameters (bpm, bars, root, octave, track indices) and provides scale theory. However, parameters like velocity, start_beat, and unit_index are mentioned but not explained in musical context. The example usage partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a full metal arrangement' and lists specific components (double kick drums, palm-muted riffs, power chords, shred lead). It distinguishes this tool from other genre-specific arrangement creators among siblings (e.g., create_rock_arrangement, create_blues_arrangement) by its focus on metal and detailed musical characteristics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 explaining how BPM ranges map to metal subgenres (thrash, traditional, extreme) and gives examples. However, it does not explicitly state when to use this tool versus other arrangement tools or provide '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.
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 pitch-stretch preserves timing, uses warp markers, and returns position/duration. However, it does not mention side effects, prerequisites, or what happens if parameters are 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 front-loaded with the purpose, followed by a concise explanation, then a parameter list, and ends with return info. Every sentence contributes value, and there is 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?
Given the tool has 5 required parameters and no nested objects, the description fully explains each parameter and the return type. The presence of an output schema (mentioned) further supports completeness. The description is adequate 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 schema has 0% coverage (no parameter descriptions), but the tool description explains all 5 parameters, including their roles and defaults (e.g., 'sample_id: The ID returned by mcp_opendaw_load_audio', 'bpm: Source BPM of the sample (for warp marker calculation)'). 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 clearly states the verb and resource ('Place a pitch-stretched audio region on a track') and distinguishes it from time-stretched alternatives by explaining that pitch-stretch preserves timing. This differentiates it from sibling tools like '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 explicit guidance: 'Use this when you want to tune audio to project key without changing its duration.' It does not explicitly state when not to use or list alternatives, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the tool creates notes across 4 tracks with specific patterns, default tempo, parameter ranges, and return value. It lacks explicit mention of side effects (e.g., overwriting existing tracks) but 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with intro, track breakdown, context, parameter list, and examples. It is informative but slightly repetitive on one-drop explanation. Length is justified by genre 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 presence of an output schema and the tool's clear role among many arrangement siblings, the description covers purpose, parameters, behavior, and examples. It omits error handling and prerequisites but is otherwise thorough.
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 explains 7 of 11 parameters (bpm, bars, root, octave, track indices) while velocity, start_beat, unit_index remain undocumented. With 0% schema coverage, it compensates partially but not fully, as some parameters lack meaning beyond 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 it creates a full reggae arrangement with specific track roles (one-drop drums, melodic bass, skank guitar, organ) and explicitly contrasts with other arrangements (rock, funk), distinguishing it from sibling tools like mcp_opendaw_create_funk_arrangement.
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 details when to use the tool: for roots reggae arrangements with one-drop feel. It provides explicit guidance on genre-specific differences and includes example calls (create_reggae_arrangement(bpm=80, root='A', bars=8)), effectively guiding 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.
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 states what is created (synth + note track) but does not disclose potential side effects, authorization needs, or error conditions. Adequate but not 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 concise but could be more structured. It uses clear sentences and a list for synth types, but the comparison paragraph is slightly verbose. Overall good.
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 output schema exists, and the description correctly mentions the return values (unit_index, track_index) and their purpose. It also provides enough context about what the tool does relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description provides all meaning. It explains the 'name' parameter as the display name and describes each synth_type option in detail, even though the schema lacks enums.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 synthesizer device and note track, and explicitly distinguishes it from create_instrument_track (which creates a Tape device). The different synth types are enumerated, making purpose very 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 contrasts with create_instrument_track, telling the agent when to use this tool vs an alternative. It also explains the synth_type options and notes that the output indices are for use with create_note, guiding subsequent usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It provides extensive detail on each track's role, the chord progression (i-VI-III-VII), tempo range (90-130 BPM, default 110), key (A minor), and the driving 16th-note arpeggio pattern. It does not disclose potential performance impacts or error handling, but the level of detail is high.
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 bullet points for each track and a clear parameter summary. It front-loads the purpose, then details each track's role, chord progression, and tempo. Every sentence adds value, though it could be slightly 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?
Given the complexity (11 parameters, no annotations, with output schema), the description is highly complete. It explains the genre, arrangement structure, chord progression, parameter constraints, and provides examples. It does not cover error conditions or return format (output schema exists), but overall very thorough.
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 bpm (range 90-130), bars (4-16, multiple of 4), root (default A), octave (default 2), and the track indices (drum_track, bass_track, etc.) including defaults. Some parameters like velocity and start_beat are only mentioned in passing, but most are 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 'Create a full synthwave arrangement' and details the four tracks with specific characteristics (retro drums, arpeggiated bass, dreamy pads, nostalgic lead). It distinguishes from sibling genre arrangement tools by explicitly contrasting synthwave's arpeggiated bass with house off-beat stabs and techno sub-drones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 creating a synthwave-style arrangement) and contrasts it with other electronic genres (house, techno, reggae) by highlighting the unique arpeggiated bass. It does not explicitly state when not to use it, but the comparisons serve as implicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses per-track patterns, default values, and output summary (notes per track and total). However, it does not clarify whether existing track content is overwritten or appended, missing a key behavioral aspect. Overall, very detailed but leaves some edge cases unaddressed.
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: purpose first, then track-by-track details, genre contrasts, parameter list, examples. Some redundancy in contrasting with other genres, but each sentence adds value. Could be slightly tighter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 output schema present, the description covers genre-specific context thoroughly, differentiates from siblings, and provides examples. Missing parameter explanations for velocity/start_beat/unit_index and no mention of existing track handling. Complete for the core use case but not fully exhaustive.
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 description must explain parameters. It explains 8 of 11 parameters (bpm, bars, root, octave, drum_track, bass_track, arp_track, lead_track) with meaningful context (e.g., 'root: Root note (F is a classic trance key — Fm)'). Missing descriptions for velocity, start_beat, and unit_index. Good overall coverage but not exhaustive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 trance arrangement with specific track roles (drums, bass, supersaw arp, pluck lead). It explicitly differentiates trance from sibling genres (house, techno, synthwave) by contrasting musical characteristics like bass pattern and energy, making the purpose distinct among many genre-specific 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 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 (uplifting trance) and specifies parameters (bpm 128-145, bars multiple of 4, root note F). Implicitly contrasts with other genre tools. Does not explicitly state when not to use, but sibling differentiation is strong enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral transparency. It details the voice-leading algorithm step-by-step, explains constraints like voice_range, and describes the return value (chord voicings, voice movements, total notes). However, it does not explicitly mention side effects (e.g., overwriting existing notes) or any prerequisites.
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, comparison, parameter list, and algorithm explanation. It is somewhat verbose, but every section adds value, especially the algorithm details. Almost no redundant 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 tool's behavior thoroughly, including the algorithm and parameter explanations. With 9 parameters and no required ones, it provides sufficient context. It does not discuss error handling or edge cases, and the output schema is present (so return format not needed). Slightly incomplete but good overall.
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 parameters. It does so for all major parameters: progression (with examples), bars_per_chord, octave, velocity, note_duration, voice_range. Unit_index and track_index are mentioned but not deeply explained (though they are common). Overall, the description adds significant 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 purpose: creating chord pads with smooth voice leading. It uses the specific verb 'create' and resource 'chord pads with smooth voice leading'. It distinguishes itself from the sibling tool 'create_chord_pads' by explicitly contrasting its behavior (minimal movement) with root-position voicing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 compares to 'create_chord_pads', stating when to use this tool (when smooth voice leading is desired) and when to use the alternative (root-position chords). It does not provide explicit 'when not to use' guidance, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already indicates destructiveHint: true, so the description does not need to reiterate destructiveness. It adds valuable context: proper cleanup of all connected boxes and the constraint that index 0 cannot be deleted. 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 two sentences plus a parameter note. It is front-loaded with the action and key constraints, with zero wasted words. Every sentence 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 one-parameter destructive tool, the description covers the function, safety constraint, and cleanup behavior. An output schema exists, so not describing the return value is acceptable. Minor gap: could mention that all child elements are recursively deleted, but the phrase 'all its tracks, effects, and sends' addresses this.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 unit_index as an integer with no description. The description adds critical meaning: the unit index must be >= 1 because index 0 is the master and cannot be deleted. 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 it deletes an entire audio unit with all its tracks, effects, and sends. It also specifies that the primary output AU (index 0) cannot be deleted, which distinguishes it from other delete tools like delete_track that operate on individual tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions using ProjectApi.deleteAudioUnit() for proper cleanup and notes that index 0 is forbidden. However, it does not explicitly compare this tool to alternatives like delete_track or remove_effect, leaving the agent to infer when to use this versus other deletion tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 region's notes are copied to offset_beats after the original and that it returns a new region index. However, it does not discuss potential side effects (e.g., whether the original region is modified, if there are constraints on offset_beats, or if the operation is reversible). Given the lack of annotations, the disclosure is decent but could be more thorough.
Agents need to know what a tool does to the world before calling it. Descriptions 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: 8 sentences, no fluff. It front-loads the purpose, then includes usage context, then lists parameters with examples. 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?
The description covers what the tool does, when to use it, and how to use it with parameter details. It mentions the return value ('Returns new region index'). For a duplication tool, this is largely complete. However, missing details like whether it can duplicate across tracks or what happens if region_index is invalid would improve 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 0% description coverage (no parameter descriptions in the JSON schema). The description compensates by explaining each parameter: unit_index (-1 = search all AUs), track_index (note track index within AU), region_index (0-based), and offset_beats (in beats, with example 4.0 = next bar in 4/4). This adds significant 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 action ('Duplicate a note region to a new position') and the resource ('note region'). It distinguishes itself from siblings like 'duplicate_region' and 'duplicate_note_event' by specifying it duplicates a note region (not audio region or individual note events). 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 a concrete use case example ('e.g. duplicate 1-bar loop to bar 2') and states it is 'Useful for repeating patterns'. While it does not explicitly mention when not to use or list alternative tools, the context of use is clear and sufficient for typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description effectively discloses the placement behavior (after original or on free space on any track) and that it returns the new region's position and index. It does not mention side effects or permissions, but the core behavior is well 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 concise and well-structured: a clear purpose sentence, followed by high-level behavior explanation, then parameter list. No redundant or irrelevant 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?
Considering the tool's complexity and the presence of many sibling duplicate tools, the description is fairly complete for the tool itself. However, it lacks comparative guidance to help an agent select this tool over similar ones, slightly reducing contextual 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 schema has 0% description coverage, so the description fully explains all four parameters: unit_index (with -1 meaning search all AUs), track_index, region_index (0-based), and find_free_space (with clear behavior for True/False). This adds essential 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 duplicates any region (audio, note, or value) using the duplicateRegion API. It specifies the action and resource type, and distinguishes from sibling duplicate tools by focusing on regions rather than other entities.
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 modes based on find_free_space parameter, providing guidance within the tool. However, it does not guide when to choose this tool over other duplicate tools (e.g., duplicate_note_region, duplicate_notes) from the sibling set, lacking explicit selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the tool wakes the engine and resumes processing, but does not disclose potential side effects or idempotency. For a simple wake operation, this is adequate but lacks extra 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 extremely concise, with two short sentences. The first sentence states the purpose, and the second provides usage guidance. 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?
Given the tool's simplicity (0 params, no complex behavior), the description is complete. It explains what it does, when to use it, and an output schema exists (though not detailed). No further information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100%. The description adds value by explaining the tool's purpose and usage, which goes beyond the empty schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Wake' and clearly identifies the resource as 'the audio engine'. It states the action of resuming audio processing, which is distinct from the sibling tool 'mcp_opendaw_engine_sleep'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 this tool: 'Use after sleep() when audio playback is needed again'. This provides clear context, though it could be more explicit about not using it when the engine is already awake.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must stand alone. Describes two-step process (export_stems + ffmpeg conversion) but lacks details on error handling, temporary file behavior, 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?
Extremely concise: one line per parameter, one sentence describing the process. 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?
Covers purpose, parameters, and process. Could mention return value or file output details, but output schema exists. Minor gap: does not specify if it works on current project stems or requires prior export.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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; description lists each parameter with type, default, and meaning (e.g., bitrate default '320k', format options). Fully compensates 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?
Clear verb ('export stems' + 'convert') and specific resource. Distinguishes from siblings like export_stems (which likely exports WAV only) by explicitly adding format 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?
Implies when to use: when you need stems in MP3/FLAC rather than WAV. Mentions it runs export_stems first, hinting at relationship. No explicit 'when not to use' but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description's read-only nature is consistent. It adds behavioral context: it's a single call that returns arrays for instrument, audio effects, and MIDI effects. No additional disclosures about performance, errors, or edge cases are provided.
Agents need to know what a tool does to the world before calling it. Descriptions 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: four short sentences that front-load the purpose, detail the output, explain the parameter, and state the return structure. 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?
Given an output schema exists, the description does not need to detail return values exhaustively. It lists the key components (instrument info, audio_effect array, midi_effect array) and the attributes per effect. The sole parameter is fully explained, making the tool description 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?
The schema has 0% description coverage for parameters, so the description carries the full burden. It explains that 'unit_index' is the AU index, adding meaning beyond the schema's 'Unit Index' title. This helps the agent understand what value to 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 clearly states it retrieves detailed info about all devices on an AU, covering instrument, audio effects, and MIDI effects. It lists specific returned fields (labels, enabled state, minimized state, parameter counts), distinguishing it from siblings like get_effect_chain or get_midi_effect_chain that focus on a subset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 it—when you need the full device chain in one call. It doesn't explicitly mention alternatives or when not to use it, but the context is clear. Siblings like get_effect_chain exist, but no exclusionary guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already declares this as a read-only operation. The description adds minimal behavioral context beyond confirming it's a 'quick overview'. 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, no wasted words. The essential information is front-loaded and presented clearly.
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 that an output schema exists, the description appropriately focuses on the input and behavior. It mentions the key data fields returned, which is comprehensive for a project info 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?
No parameters, so schema coverage is 100% by default. The description does not need to add parameter information; the baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it provides a quick project overview including BPM, time signature, track/AU/effect counts, and total duration. It also distinguishes from get_project_state by noting it's lighter and lacks per-track detail, which helps differentiate 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?
Clearly indicates when to use this tool (for a quick overview) and compares it to get_project_state, providing a clear alternative. Does not explicitly state when not to use, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds context: returns metadata or error if not found, using SampleManager. No contradictions; clarifies behavior 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 concise with no wasted sentences. Each sentence adds value: purpose, implementation detail, parameter hint, and return behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter and output schema, the description covers purpose, parameter source, return fields, and error case. It is 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 description must compensate. It explains sample_uuid is a UUID from list_samples, adding meaningful context beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed info about an audio sample by UUID' with specific return fields (sample rate, channels, frames, loading state), distinguishing it from siblings like get_audio_file_info by focusing on sample metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the sample_uuid comes from list_samples, guiding the user on parameter source, but does not explicitly discuss when to use this tool versus alternatives or provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds limited behavioral context beyond stating it returns all categories and values. No mention of side effects, auth, or rate 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?
Two concise sentences, front-loaded with categories, 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 get-all tool with output schema and readOnlyHint annotation, the description covers the essential purpose and return scope completely.
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?
No parameters exist; baseline is 4. Description adds no parameter info, but the category list in description provides context on what the function returns, which is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 specific verb 'Get' and resource 'all studio preferences/settings', with explicit category list distinguishing it from modify 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly implies use for reading all settings, but lacks explicit when-not-to-use or comparison with the sibling set_studio_setting. Agent can infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, but the description adds context about freeze meaning pre-rendered audio and sidechain restrictions. This provides behavioral depth 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?
Description is four sentences, front-loaded with purpose, and contains no extraneous information. 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?
Given the existence of an output schema (inferred from return description), the tool fully describes what it returns and the meaning of each boolean field. It also explains why can_freeze might be false. No gaps.
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 description must compensate. It briefly describes unit_index as 'AU index', which is minimal but sufficient given the simple integer parameter. Could add more context on finding 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 the tool checks if an audio unit is frozen and whether it can be frozen, distinguishing it from sibling like freeze_audiounit. It also explains the freeze concept and restriction about sidechain dependents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 the tool checks freeze status and can_freeze, implying it should be used before freezing. However, it does not explicitly state when not to use it or compare to other get_* status tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that it modifies notes non-destructively (applies random deviations), and specifies the return value ('per-track note counts and total notes humanized'). It does not mention prerequisites or potential side effects, but the behavioral description 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-line summary, then general behavior, then parameter details. It is front-loaded with purpose. While lengthy, the detail is necessary for parameter clarity; no superfluous 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?
Given the tool's complexity (7 parameters, no annotations, but an output schema exists), the description covers all necessary aspects: purpose, parameter semantics, behavior, and return value. 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?
Schema description coverage is 0%, but the description fully compensates with detailed explanations for all 7 parameters, including value ranges, examples (e.g., '0.05 = subtle, 0.15 = natural'), and behavioral impact (e.g., 'Shifts every other 16th note later by swing * 1/3 of a 16th'). This 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 description clearly states the tool's purpose: 'Add human-like variation to existing notes — velocity, timing, duration, and swing.' It uses a specific verb ('Add') and resource ('notes') and distinguishes from siblings like humanize_pitch by enumerating the dimensions of variation.
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 scope ('all notes in specified track(s)/unit(s), or globally with unit_index=-1') but does not explicitly guide when to use this tool over alternatives like apply_swing or humanize_pitch. It lacks when-not and alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool deserializes the preset into the current project, creating a new AU with all dependencies, and returns index, type, label, or error. This is transparent about the effect and return value, though it could mention error handling or destructive potential.
Agents need to know what a tool does to the world before calling it. Descriptions 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 includes necessary details without unnecessary words. Each sentence serves a clear 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 complexity (importing a preset with dependencies) and the presence of an output schema, the description covers input, process, and output adequately. No obvious 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?
With 0% schema coverage, the description adds significant meaning by specifying the parameter format (base64-encoded) and its origin (from export_preset). This goes beyond the schema's plain string type, but could include constraints like maximum size.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 imports a base64-encoded preset and creates a new audio unit with all dependencies. This is a specific verb-resource pair that distinguishes it from other import tools like import_midi or import_audio_to_tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions preset_b64 comes from export_preset, which provides a clear usage hint. However, it does not explicitly state when not to use this tool or compare to alternatives, leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by specifying that it lists both primary output and FX buses and returns bus index, name, enabled state, and associated audio unit index. This provides clear insight into the tool's output and 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?
Two concise sentences: the first states the purpose, the second lists the return values. No redundant or wasteful language. Every sentence is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (not shown) and no parameters, the description is complete. It enumerates the main return fields (index, name, enabled state, audio unit index), which is sufficient for an agent to understand the tool's functionality.
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 schema coverage is 100%. The description does not need to add parameter information. The baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all audio buses in the project (primary output + FX buses).' It specifies the verb 'List', the resource 'audio buses', and the scope (project, including primary output and FX buses), effectively differentiating from sibling tools that modify or create 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 does not explicitly state when to use this tool versus alternatives like create_audio_bus or set_bus_enabled. While the context of sibling tools implies it is a read-only listing tool for gaining an overview, no explicit when/when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. The description adds context about MIDI effects processing note data and being on the au.midiEffects chain, providing useful behavioral insight 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?
Three concise sentences with no wasted words. The main action is front-loaded, and the additional sentences provide essential context 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 has an output schema (unseen), the description need not detail return values. It fully explains what the tool lists and the role of MIDI effects, making it complete for a discovery 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?
With no parameters and 100% schema coverage, the description correctly has no parameter info. It compensates by explaining the tool's purpose and context, which is sufficient for a parameterless list 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 'List all available MIDI effect types' with specific verb and resource, and distinguishes from similar tools like 'list_effects' by specifying these are MIDI effects that process note data before the instrument.
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 discovering MIDI effect types and mentions where they are inserted, but does not explicitly state when to use this tool versus alternatives like 'list_effects' or 'get_midi_effect_chain'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds value by listing the specific return fields (id, label, delayInMs, sendTransportMessages) and clarifying that these are hardware MIDI outputs, providing context 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?
Description is two sentences, front-loaded with purpose and concise listing of return fields. Every sentence is necessary and 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 zero-parameter list tool with output schema and annotations, the description is complete. It states what is listed and the fields returned, covering all needed 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?
No parameters exist, so schema coverage is 100%. Description adds no parameter info, but none is needed. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List all MIDI output devices' with specific verb and resource. It also specifies 'hardware MIDI outputs' and lists return fields, distinguishing it from other list tools like list_audio_buses or list_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?
Description does not explicitly provide when-to-use or when-not-to-use guidance. However, the name and description are self-explanatory for a simple list operation, so it is adequate but lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 specifying the output fields (AU index, label, module/connection counts). No contradictions. Could mention if the list is always available given project state, but not necessary.
Agents need to know what a tool does to the world before calling it. Descriptions 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 primary action, followed by output details and a definition of 'Modular'. Every sentence adds meaning 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 has no parameters, read-only annotations, and an output schema (exists), the description provides sufficient context: what it lists, return fields, and domain definition. No 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?
There are no parameters, so baseline 4 applies. No parameter information needed. The schema coverage is 100% (empty), and the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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) and the resource (modular audio effect devices). It distinguishes from sibling tools like list_modular_connections and list_modular_modules by focusing on devices themselves. The additional context explaining 'Modular' clarifies the domain.
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 provide when-to-use or when-not-to-use guidance. However, for a simple listing tool with no parameters, usage is straightforward. No alternatives are mentioned, but the description is self-explanatory.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations include readOnlyHint=true, so the description does not repeat that. It adds behavioral context: notes are sorted by position, and unit_index=-1 searches all AUs. No contradictions 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 concise: one sentence for purpose, then return fields, then parameter explanations, then sorting. No unnecessary 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 simplicity (3 parameters, no nested objects) and the presence of an output schema, the description covers all necessary information: purpose, parameters, output fields, and sorting 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 explains each parameter: unit_index (-1 searches all), track_index (within AU), region_index (0-based). This adds meaning 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 explicitly states 'List all note events within a region', clearly specifying the action and resource. It distinguishes itself from sibling list tools (e.g., list_tracks, list_clips) by focusing on note events within a 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?
No explicit when-to-use or when-not-to-use guidance is provided. While the name is self-explanatory, the description does not mention alternatives or prerequisites, which would help an agent choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: preserves chord qualities, interval relationships, and that direction affects octave placement. Also states return value includes modulation string and per-chord mapping. No annotations provided, so description carries full burden.
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?
Well-structured with clear sections, examples, and parameter details. Could be slightly more concise but overall 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 input, behavior, common use cases, and output. With output schema present, description is sufficiently complete for a transformation 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%, but description adds essential meaning to each parameter with examples and defaults, compensating effectively.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 transposes a chord progression to a new key, with specific examples and common modulation patterns. It distinguishes itself from siblings by focusing on modulation vs. reharmonization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 modulation (e.g., for chorus, bridge) with examples, but does not explicitly exclude cases where alternatives like reharmonization are better.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description adds value by explaining internal method (AudioUnitBoxAdapter.move), delta semantics, and return type. Does not explicitly state that it modifies project state (destructive), but move operations are inherently modifying.
Agents need to know what a tool does to the world before 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 purposeful sentences plus parameter definitions. Front-loaded purpose, efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 core behavior, parameter constraints, and return value. Simple tool with output schema present. Could mention mutability but not necessary for 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 has 0% coverage, but description explains both parameters: unit_index as current index and delta as relative move with allowed values -1/+1. This provides crucial meaning beyond 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?
Clearly states verb 'move' and resource 'audio unit' in mixer order, distinguishing from sibling move tools like move_effect and move_track. Also provides implementation detail and group 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?
Purpose is clear but no explicit guidance on when to use vs alternatives like rename or delete. Only implied usage for reordering within type groups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a key behavior: 'Automatically recalculates relative positions of subsequent events.' This adds value beyond the simple action of moving a single event, as it informs the agent of side effects. It also mentions the return type 'success or error'. However, it does not describe reversibility, error conditions, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions 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 for the purpose and effect, then a clear parameter list. Every sentence adds essential information without redundancy. The key action 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?
Given that an output schema exists (implying return values are documented elsewhere), the description adequately covers the main action, parameter meanings, and a behavioral note. It is complete enough for an agent to use the tool correctly, though it could mention prerequisites (e.g., the event must exist) 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?
Since the input schema has no descriptions for the parameters (0% coverage), the description compensates by explicitly defining both parameters: 'event_index' is described as 'Index of the signature event (from add_signature_change list)' and 'target_ppqn' as 'New position in PPQN.' This adds crucial context about the source of the index and the unit of the position.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'Move a time signature change event to a new PPQN position.' The verb 'Move' is specific, and it distinguishes this tool from related siblings like add_signature_change, delete_signature_change, and list_signature_changes by focusing on repositioning 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The description implies that this tool should be used when you need to reposition a signature event and want automatic recalculation of subsequent events, but it does not mention alternatives (e.g., delete and re-add) or conditions under which the tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 mentions that the conversion accounts for time signature changes, implying state dependency, and lists return values. However, it does not explicitly state it is a read-only operation or disclose 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a clear action statement, a brief use-case, parameter description, and return values. Every sentence contributes meaning 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 conversion tool with one parameter and an existing output schema, the description covers the purpose, parameter, and return values adequately. 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?
The input schema has 0% description coverage, so the description's parameter explanation adds value. It gives the unit ('960 = 1 quarter note'), which provides crucial context beyond the schema's type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it converts PPQN position to musical parts (bars, beats, semiquavers, ticks), with a specific verb and resource. It distinguishes itself from the sibling tool mcp_opendaw_ppqn_to_seconds, which converts to seconds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 it is useful for understanding where a position falls in the musical grid, accounting for time signature changes. This implies when to use, but does not explicitly exclude alternatives or provide 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.
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 explains that the tool accounts for tempo automation and integrates over tempo change events, and notes the return type (float or error). However, it does not mention side effects, authorization needs, or edge cases, which is adequate for a simple read-only conversion 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 (5 sentences) with a clear structure: purpose, behavior, unit definition, parameter explanation, and return value. 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 simple single-parameter conversion tool and the presence of an output schema (per context signals), the description covers all necessary aspects: operation, input, account for tempo map, and return type. 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 input schema provides only the parameter name and type; the description adds meaning by specifying the unit (beats), example value (4.0), and context (position in beats). This goes beyond 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 specifies the tool's purpose: converting a position in beats (PPQN units) to seconds using the project's tempo map. It defines the unit (1 beat = 960 pulses) and distinguishes the tool from siblings like 'seconds_to_beats' and 'ppqn_to_parts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 conversion accounts for tempo automation and integrates over tempo changes. It does not explicitly state when not to use it or list alternatives, but the context is clear enough for an agent to decide appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It details transformation logic for each mode and mentions return values ('Returns count of notes modified, original and new duration stats'). However, it does not disclose if the operation is destructive or reversible, nor any prerequisites like region existence.
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 headings and examples, front-loading the purpose. While it is relatively long, every sentence adds necessary detail for a complex tool. Minor redundancy could be trimmed, but overall 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?
Given 8 parameters, 0% schema coverage, and no annotations, the description is remarkably comprehensive. It covers all parameter semantics, modes, and includes examples. The output schema exists and description mentions the return value, so no 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 has 0% parameter description coverage, so the description must compensate. It thoroughly explains all 8 parameters, including modes with 5 options, value semantics per mode, region_index, min/max_duration, quantize grid, and provides clear examples. 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 the tool's purpose: 'Scale the duration of all notes in a region — MIDI note length control.' It explicitly distinguishes from sibling tool scale_velocity by stating 'Like scale_velocity but for note durations,' making the action specific and differentiating it from nearby 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 context on when to use the tool: 'Useful for changing articulation globally — make all notes shorter (staccato feel), longer (legato feel), or snap to a grid.' It doesn't explicitly state when not to use it, but the comparative mention with scale_velocity implies alternatives for velocity scaling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral transparency. It discloses the skip behavior, slope range, and return of updated fade values. It does not mention prerequisites (e.g., region existence) or confirm if it overwrites existing fades, which would be beneficial but not critical.
Agents need to know what a tool does to the world before calling it. Descriptions 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 header sentence, a paragraph explaining the Fading object and skip value, then a bullet-like list of parameters with brief descriptions, and a sentence about the return. 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?
Given 7 required parameters and an output schema, the description covers parameter details and return value. It lacks explicit error handling or prerequisites, but output schema exists to describe return structure. Adequately complete 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 description coverage is 0%, so the description compensates fully. It explains each parameter: unit_index, track_index, region_index, fade_in/out (seconds, -1 to skip), in_slope/out_slope (0-1 curve). This adds significant meaning beyond the 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 'Set fade in/out on an audio region' and explains the Fading object's four parameters, distinguishing it from other region operations like gain or time base. It 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?
The description explains how to skip parameters with -1.0 and the slope curve values, but does not explicitly state when to use this tool versus alternatives (e.g., copy_region_fades or set_audio_region_gain). Usage context is implied but not guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description explains gain control type and return value, but lacks details on error handling, permissions, or side effects. Adequate 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?
Five focused sentences with no redundancy. Front-loads purpose, then use case, then parameter details. Efficient 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?
Covers all required parameters and use case. Mentions return value. Lacks potential error scenarios, but sufficient for a straightforward setter with 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 has 0% description coverage. Description adds full parameter meanings, including unit indices and gain_db examples, significantly aiding agent 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 clearly states the verb 'Set gain' on a specific resource 'audio region'. It provides examples of gain values and distinguishes from siblings by specifying gain control 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?
Explicitly states use cases: 'trim automation or balancing clips within a track.' Does not list alternatives or when-not-to-use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavioral details: skip values for each parameter (empty string, -1, None) and that it returns updated clip properties. This adds value beyond the schema, though it could mention that it modifies the clip in place.
Agents need to know what a tool does to the world before calling it. Descriptions 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, skip conventions, parameter list, and return statement. 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?
The description covers purpose, parameter meanings, skip behavior, and return value. It is complete for a compound setter, though it could note that this is an alternative to individual setters or mention that all parameters are required but skippable.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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's meaning and skip conventions. For example, 'clip_index: Clip index (from list_clips)' and skip values are clearly documented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 properties on a clip (session view): label, color, mute, duration' and lists all parameters. It distinguishes from sibling tools by being a compound setter, and the title 'mcp_opendaw_set_clip_properties' aligns with this.
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 multiple clip properties at once, but it does not explicitly state when to use this tool versus the individual set_clip_hue, set_clip_label, etc. For example, it could say 'Use this to set multiple properties in one call instead of individual setters.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool applies specific cent offsets, describes modes, and mentions the cent range (-100 to +100). It also notes that it returns 'notes modified, per-mode details, and average cents applied'. However, it does not disclose potential side effects or destructive actions.
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 lengthy but well-structured with bullet points for modes and dashes for examples. It front-loads the core purpose and differentiates from siblings. However, some redundancy exists (e.g., repeating allowed values in the examples could be trimmed). Still, it earns 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?
Given 11 parameters, no annotations, and an output schema existing (so return values need not be described in detail), the description is quite complete. It covers the main behavior, all modes, and parameter explanations. The examples provide rich context for usage. Minor gaps: no description of error conditions or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains 8 out of 11 parameters in detail (mode, cents, target_pitch, beat_positions, note_indices, direction, scale, root_note), providing examples and context. The remaining three (unit_index, track_index, region_index) are briefly mentioned with defaults. This 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 the tool's purpose: setting deterministic cent offsets on notes for microtonal pitch control. It distinguishes itself from the sibling tool 'humanize_pitch' by explicitly contrasting random vs deterministic behavior. The verb+resource is specific: 'Set detune (cents) on 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 for when to use this tool, explicitly contrasting with humanize_pitch (random cents). It lists multiple modes and example use cases, helping the agent understand applicability. However, it does not explicitly state when NOT to use it or provide alternative tools beyond humanize_pitch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 skip behavior (-1) but does not disclose side effects, undo capability, or permissions. For a mutation tool, more behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key usage tip and prerequisite, followed by a structured parameter list. 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.
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, the description covers core usage, parameter semantics, and output. It does not address error conditions or validation, but output schema likely fills gaps. Overall complete 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?
Since schema description coverage is 0%, the description fully compensates by listing each parameter with its meaning, valid range (e.g., pitch 0-127), and behavior (-1 skip). This adds significant value beyond the schema's type-only 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 uses a specific verb ('Edit') and clearly identifies the resource ('properties of a single note within a region'). It distinguishes from sibling tools like mcp_opendaw_set_note_cents by focusing on multiple properties at once.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 guidance: passing -1 to skip parameters and using list_notes first to find the note_index. It lacks explicit when-not-to-use or alternatives, but the prerequisite tip is valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adequately discloses that the tool is a setter and returns success along with old and new values. This adds necessary behavioral context, though it could mention any side effects on the displayed keyboard range.
Agents need to know what a tool does to the world before calling it. Descriptions 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 crisp sentences: purpose, parameter mapping, and return info. Every sentence adds value with no redundancy. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers the essential aspects. It could be improved by mentioning that this affects the visual keyboard range in the piano roll, but it 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?
The input schema has 0% description coverage, but the description fully enumerates the allowed integer values and their meanings ('88 (full piano)', etc.), which significantly compensates and allows correct parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: setting the piano roll keyboard type. It lists the allowed integer values with descriptive labels (88='full piano', etc.), which is precise and distinct from sibling set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to change keyboard type), but does not explicitly contrast it with alternatives like set_piano_note_labels or set_piano_note_scale. No guidance on when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It details compilation steps (parsing, validation, worklet registration, writing code). It does not mention destructive side effects or permissions, but 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 moderately lengthy but well-structured with a clear core purpose and bullet-pointed steps. It is front-loaded and each sentence adds value, though could be slightly 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?
Given an output schema exists (not shown), description covers main aspects: purpose, compilation process, device types, and code syntax. It lacks prerequisites or error conditions, but is largely complete for a 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%, but description adds significant meaning for 'code' (syntax with @param/@sample) and 'device_type' (lists exact values). It does not detail 'unit_index' or 'device_index', but overall compensates well for the low 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 sets user JavaScript code on a scriptable device, specifying the verb 'Set', the resource 'script device code', and the scope (Apparat/Werkstatt/Spielwerk). It distinguishes from siblings like get_script_device_code and other set_* 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 explains the compilation process and lists device types with their roles, implying usage when programming a scriptable device. It lacks explicit when-to-use or alternatives but is clear enough for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description fully covers behavior: value validation against declaration's range, snapping/clamping per type (bool, int, linear/exp/unipolar), and response includes clamped flag and range info. This is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with the purpose at the start, followed by necessary details on validation. It is slightly lengthy but each sentence serves a purpose; 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 lack of schema descriptions and annotations, the description covers the core behavior and response content ('clamped flag and range info'). It does not explain all parameters but 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning no parameter explanations in the schema. The description adds value by explaining the value parameter's validation rules, but does not explain device_type, unit_index, device_index, or param_label. It partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 resource 'parameter value on a scriptable device by label'. It is specific and distinguishes from other set_* tools by focusing on 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the parameter must exist from a @param declaration and details validation behavior per type. However, it does not explicitly state when not to use this tool or provide direct comparisons to alternatives, though the context implies it is for scriptable devices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 traits. It discloses that the tool sets pitch shift with clamping, returns new playback rate and cents or error, and only works on specific regions. It does not explicitly mention that it modifies the region's playback rate (implied by return value) or discuss side effects, undo capability, or authorization needs, but is still 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using short paragraphs and bullet-style lines for parameters. The first line clearly states the tool's purpose. Every sentence adds value: range, prerequisite, parameter explanations, return value. 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 an output schema likely exists and the description mentions return values, it covers the essential behavior. It could mention that the region must exist or error scenarios, but for a simple setter, 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 description coverage is 0%, so the description must explain each parameter. It does so for all four parameters: unit_index, track_index, region_index, and cents, including the range and meaning of cents. 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.
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 pitch shift in cents on a time-stretched audio region, specifying the action ('set'), the domain ('time-stretched audio region'), and the unit ('cents'). It implicitly distinguishes from sibling tools like set_note_cents (MIDI) or set_transpose (general) by focusing on time-stretched regions, but does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the prerequisite: 'Only works on time-stretched regions (created with create_time_stretched_region).' This tells the agent when not to use it. It also provides the valid range and clamping behavior. However, it does not mention alternative tools for non-time-stretched regions, but the sibling list provides context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses the partial update behavior, valid value ranges (0.0-1.0 for value and curve_slope), interpolation options ('none', 'linear', 'curve'), condition for skipping fields (-1 or empty string), and that it returns success with updated values. It does not mention error handling or side effects, but overall is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: first sentence gives the core purpose, followed by a note on partial updates, then a clear list of parameters. It could be slightly more concise by avoiding repetition of the skip conditions already implied in the parameter notes, but overall it is efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains all 6 parameters with their types and skip conditions, given the context of an update operation. It mentions that the tool returns success with updated values (consistent with an output schema). For a tool of this complexity (optional fields, partial update), the description is complete and leaves no 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 coverage is 0%, meaning parameter titles provide no meaningful descriptions. The description compensates fully by explaining each parameter: unit_index (AU index), track_index (value track index), event_index (event index), value (0.0-1.0, skip if -1), interpolation (none/linear/curve, skip if empty), curve_slope (0.0-1.0, skip if -1). This adds critical meaning 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 action ('Update') and the resource ('existing automation event'), and specifies the modifiable aspects ('value and/or interpolation'). It distinguishes itself from sibling tools like create_automation_event, delete_automation_event, and list_automation_events by focusing on updating existing 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 mentions that only provided parameters (value >= 0, non-empty interpolation, curve_slope >= 0) are updated, but it does not give explicit guidance on when to use this tool versus alternatives (e.g., creating a new event or deleting one). The 'Only updates parameters that are provided' note is helpful but lacks comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states that the tool 'Returns updated marker values' but does not disclose side effects, prerequisites, error handling, or the impact of modification on other markers. It adequately describes the basic behavior but lacks depth 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. It begins with the main purpose, provides a critical usage tip, and then lists parameters. Every sentence is informative 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?
Given that an output schema exists (context signals indicate 'Has output schema: true'), the description does not need to explain the return format. It covers all input parameters and the -1 leave-unchanged pattern. However, it could mention that the marker must exist and what happens if indices are invalid.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 adds significant value by defining each parameter (unit_index, track_index, region_index, marker_index, position_beats, seconds) and explaining the special -1 default for unchanged values. Without this, an agent would have no semantic understanding 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 clearly states 'Update a warp marker's position and/or seconds value.' It specifies the verb 'Update', the resource 'warp marker', and the attributes (position and seconds). It distinguishes from sibling tools like create_warp_marker and delete_warp_marker by implying a modification 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 provides guidance on how to update selectively with 'Pass -1.0 for either parameter to leave it unchanged.' It does not explicitly state when to use this tool versus alternatives, but the purpose is clear enough that an agent can infer it is for modifying existing warp markers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description clearly explains how accent strength is determined (downbeats strong, off-beats weak) and the interpolation for notes between beats. It also mentions the return value (count of notes accented and per-level breakdown), providing transparency 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-organized with sections for main functionality, differentiation, accent patterns, use cases, parameter list, and an example. Every sentence adds value, and the structure 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?
With 7 parameters and no output schema, the description covers both parameter semantics and return value ('Returns count of notes accented and per-level breakdown'). It is complete enough for an agent to understand what the tool does and what it outputs.
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 fully compensates by listing each parameter with a brief explanation (e.g., 'strong_velocity: Velocity for strong beats (0-1)'). While not exhaustive, it adds sufficient meaning beyond the schema's bare types and 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 uses a specific verb ('apply') and resource ('beat-aware velocity accents to notes'), clearly stating the tool's purpose. It distinguishes itself from the sibling 'apply_velocity_pattern' by explaining the difference in accent determination (beat position vs note index).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 'apply_velocity_pattern' and provides concrete use cases (e.g., making drum patterns groovy, adding natural dynamics to basslines). It does not explicitly state when not to use it, but the differentiation and use cases offer adequate guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 created effects (Revamp EQ, Compressor, optional Waveshaper) and says it returns effect indices and parameter values. However, it does not mention if it overwrites existing effects, whether changes are reversible, or any required 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: purpose, benefit, parameter details, output comment, and examples. Every sentence is informative, and the overall length is appropriate 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 3 parameters (none required), no annotations, and an output schema (not provided but described). The description covers the effect chain, parameter details, use cases, and examples, making it complete 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?
Schema description coverage is 0%, so the description fully documents all three parameters: `unit_index` (target audio unit), `style` (with detailed preset descriptions for deep, round, driven, clean, tight), and `drive_amount` (range 0-1, default 0, usage advice). Examples show typical values. This adds significant 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 'Add a ready-made bass processing chain to an audio unit' and specifies the exact effect chain (EQ → Compressor → optional Waveshaper). It distinguishes this tool from siblings like `add_effect` by noting it replaces multiple individual 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 explains that the tool replaces 2-3 individual `add_effect` and `set_effect_parameter` calls and is designed for bass tracks but works on any low-frequency content. It provides examples but does not explicitly state when to avoid using it (e.g., for custom chains).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the effects created (Gate → EQ → Compressor → optional Reverb) and mentions returning effect indices and values. However, it does not clarify whether existing effects are preserved or overwritten, nor does it mention any 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 well-structured: a one-line summary, a benefit statement, a parameter list with clear headings and descriptions, and a multi-line example section. Every sentence adds value, and the formatting aids 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 three parameters, no required ones, absence of schema descriptions, and presence of an output schema, the description fully covers purpose, usage context, parameter meanings, expected output (effect indices and values), and includes practical examples. 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description provides detailed semantics for all three parameters: unit_index (target as 'the drum track'), style (five named options with descriptions), and reverb_amount (range and typical usage). This adds significant value beyond the minimal 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 ('Add a ready-made drum processing chain') and the resource ('audio unit'), with a specific sequence of effects. It distinguishes from sibling tools like add_bass_chain and add_vocal_chain by explicitly targeting drums and rhythmic 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 explains the tool is designed for drum tracks but works on any rhythmic content, and notes it replaces multiple individual effect calls. It provides clear context for use, though it does not explicitly state when not to use it (e.g., for non-rhythmic content).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses the effect chain order (Revamp EQ → Compressor → Reverb → Delay), that it returns effect indices and parameter values, and the effect of each parameter. This provides sufficient behavioral context for safe usage.
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: summary, then parameter details, then examples. All parts are valuable, though it could be slightly more streamlined. The example section is particularly 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?
With 4 parameters fully described, an output schema present, and clear explanation of the effect chain created, the description covers essential context. It doesn't need to detail return values due to output schema. Minor gaps: no mention of prerequisites or error conditions, but 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 description must compensate fully. It explains each parameter: unit_index (target audio unit), style (five presets with descriptions), reverb_amount (wet/dry, default 0.25), delay_amount (optional, default 0). Examples illustrate usage. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states clearly: 'Add a ready-made vocal processing chain to an audio unit — EQ + compressor + reverb (+ optional delay).' It specifies the verb (add), resource (vocal chain), and distinguishes from siblings like add_effect and add_bass_chain by noting it replaces multiple 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 includes: 'One call replaces 3-4 individual add_effect + set_effect_parameter calls. Designed for vocal tracks but works on any melodic content.' This gives explicit guidance on when to use it and suggests the alternative of individual calls, though it lacks explicit 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint: true, and the description is fully consistent, describing the tool as 'Measures the dynamic character' (read operation). The description goes beyond annotations by explaining each metric's meaning (e.g., crest_factor_db, transient_density) and providing contextual semantics (e.g., 'high crest_factor = very dynamic'). This rich behavioral detail aids the agent in understanding what the tool does and how to interpret outputs.
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 summary line, a list of metrics with explanations, compression guidance, argument description, and a return statement. It is front-loaded with the core purpose. While informative, it could be slightly more concise by reducing redundant phrasing (e.g., 'Measures the dynamic character of a track' could be merged with the first line). Every sentence earns its place, but the length is appropriate for the detail provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 an output schema (context signal), the description adequately covers the main return values (dynamics descriptors, 10-segment RMS contour, compression suggestions) and their meanings. However, it lacks information about file format constraints (e.g., sample rate, bit depth) or performance considerations. Overall, it is sufficiently complete 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single filename parameter has 0% schema description coverage. The description compensates fully by explaining how to specify the file: 'Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.' This adds essential context not present in the schema, making the parameter's usage 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 purpose as 'Dynamics analysis' and lists specific metrics (crest factor, loudness range, etc.). It distinguishes itself from sibling analysis tools (e.g., analyze_harmonic_rhythm, analyze_spectrum) by focusing on dynamic character. The verb 'analyze' paired with 'dynamics' makes the action and resource explicit.
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 guidance on interpreting results for compression decisions, which helps the agent decide if dynamics analysis is needed. However, it does not explicitly state when to use this tool over other analysis tools or when not to use it. There are no exclusions or alternatives mentioned, leaving the agent to infer intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and description agrees (no mutation implied). Description adds rich behavioral detail: what analysis components are returned (contour profile, interval histogram, etc.) and example usage. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured: summary line, bullet-point list of analysis outputs, 'Useful for' list, parameter explanations, and example. Front-loaded with key info. Slightly lengthy but earns its space with comprehensive 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 complexity of a melodic analysis tool, the description covers all necessary aspects: inputs, outputs (via bullet list), use cases, and parameter details. Output schema exists, so return values are adequately specified 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%, but description provides clear explanations for all parameters (unit_index: AU index, track_index: Note track index, region_index: Region (-1 = first region)). This compensates well 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?
Description clearly states 'Analyze melodic content' with a specific verb and resource, and lists detailed outputs (contour, intervals, climax, etc.). It distinguishes from sibling analysis tools by focusing exclusively on melody, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a 'Useful for' section with clear contexts (e.g., understanding a melody before variation, comparing melodies, feeding to create_motif_variations). While it doesn't explicitly list when not to use or alternatives, the guidance is sufficient for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the description adds value by detailing behavioral aspects (returns metrics, per-region width, mix suggestions) and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, metric details, mix guidance, and args list. While somewhat long, every section adds unique value; a slight trim could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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, the description appropriately covers parameter usage and metric interpretation, though it could mention prerequisites like file existence. Overall, it is comprehensive for a read-only 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?
With 0% schema description coverage, the description fully explains the filename parameter, including valid paths and constraints ('Name of the WAV file in the exports directory (without path), or absolute path to any WAV file'), adding essential 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 explicitly states 'Stereo analysis of audio — width, L/R balance, mono compatibility, mid/side energy' and lists specific metrics, clearly distinguishing this tool from sibling analysis tools like analyze_phase and analyze_dynamics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 'Mix decision guidance' explaining when to use based on metric thresholds (e.g., stereo_width < 0.1 → narrow mix), but does not explicitly compare with sibling tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, and the description adds value by explaining it is a composite tool that runs multiple analysis functions, lists all return fields, and shows example output. No contradiction exists.
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 sentence, explanation of composition, pipeline context, parameter description, list of returns, and an example. It is slightly long but every section adds value and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, the description sufficiently explains return fields and shows an example. The pipeline context and parameter semantics make it complete for a single-parameter analysis 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 single parameter 'filename' is explained in the description: 'Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.' This adds meaningful context beyond the schema's type definition, especially since schema coverage is 0%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'full audio analysis in one call' including BPM, key, LUFS, duration, and dynamic range. It explicitly characterizes itself as a composite tool replacing three separate calls (detect_bpm, detect_key, measure_lufs), 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific pipeline example for the Suno remix workflow and notes that it eliminates three separate calls. While it does not explicitly list when not to use it or alternative tools, the context is clear and helpful for 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides good transparency: it creates volume automation events on the target track's volume parameter, and details return info (total events, ducking pattern). It lacks mention of whether existing automation is overwritten.
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 purpose line, context, parameter list, return info, and example. It is slightly lengthy but each 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's complexity (8 params, 1 required, output schema present), the description covers most aspects: how it works, parameter roles, return values, and example. Minor gap: no mention of prerequisites (e.g., need an existing kick track).
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 explained with definitions, example values, and ranges, compensating for the 0% schema description coverage. For instance, depth: '0.6 = volume drops to 40% on each kick, 0.8 = drops to 20%'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 sidechain ducking via volume automation, specifying the classic pumping/breathing effect. It distinguishes from sibling tools like mcp_opendaw_connect_sidechain by focusing on simulation via 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?
The description explains when to use the tool (for house, techno, EDM, pop) and how it works, but does not explicitly state when not to use it or alternative tools like actual sidechain compression via connect_sidechain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description clearly states the tool is deterministic, reversible, and does not change velocity or duration. It does not mention potential side effects or limitations, but the stated properties give good behavioral context for an AI agent.
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 brief summary sentence, then an explanation of the effect, sibling differentiation, parameter details, and an example. It is slightly verbose in the parameter section but front-loaded with the main purpose. 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?
All four parameters are explained, the behavior is described, and a usage example is given. The return value is briefly mentioned ('Returns per-track note counts shifted'), which is sufficient given the presence of an output schema. The tool is non-destructive and reversible, so no additional safety context 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?
Schema coverage is 0%, so the description fully compensates by explaining each parameter in detail: unit_index, track_index, swing_amount (with specific ranges), and grid (valid values). It also provides an example usage. This adds significant meaning beyond the 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 clearly states it applies swing feel to existing notes without changing velocity or duration, and distinguishes itself from the sibling tool 'humanize_notes' which couples swing with random changes. The verb 'apply' and resource 'swing feel to notes' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 compares to 'humanize_notes' and states this tool applies pure, deterministic, reversible swing. It provides guidance on swing_amount values (e.g., 0.55-0.66 for hip-hop/lofi). However, it does not explicitly state when not to use this tool or when to prefer alternatives beyond that single comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full responsibility. It discloses destructive modification of notes, provides the velocity calculation formula, and explains modes. It could mention irreversibility 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear first sentence, conceptual paragraph, parameter explanations, and examples. It could be slightly more concise with bullet points for 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?
Covers purpose, parameters, behavior, and examples. Lacks discussion of error handling or edge cases like empty patterns, but sufficient 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?
All 6 parameters are explained in the description, including patterns, modes, defaults, and the effect of base_velocity. This compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'apply' and resource 'cyclic velocity pattern to existing notes in a region', distinguishing it from linear ramps or other velocity tools. It uses specific examples to reinforce 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 explains the tool's role as an accent pattern tool and contrasts with linear ramps, but does not explicitly state when to avoid this tool in favor of alternatives like random or LFO-based velocity changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 describes the output as 'per-dimension comparison + actionable deltas' and gives an example return structure. It implies a read-only comparison but does not explicitly state that no files are modified or mention constraints like sample rate compatibility.
Agents need to know what a tool does to the world before calling it. Descriptions 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 bold title, bullet points of dimensions, parameter explanations, and an example usage. Every sentence adds value without redundancy. It is concise yet informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 (mix comparison) and lack of annotations, the description covers the what, why, and how effectively. It includes an example return shape and explains both parameters. However, it could mention prerequisites like matching sample rates or lengths of the two files.
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 descriptions (0% coverage), but the description adds meaning: 'filename: Your mix WAV (exports dir or absolute path)' and 'reference: Reference track WAV (exports dir or absolute path).' This compensates well for the schema gap, though it could specify supported file formats beyond WAV.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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: 'A/B compare your mix against a reference track across all dimensions.' It lists specific comparison dimensions (LUFS, spectral curve, stereo width, dynamic range, spectral centroid) and differentiates from siblings like 'compare_to_profile' by focusing on reference tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use: 'This is how you learn how pros mix your genre. Drop in a reference track you admire.' However, it does not explicitly mention when not to use or compare with the sibling 'compare_to_profile', which could be a potential alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It explains the sequential nature (approach note first, then resolution), the ratio affecting tension, and the effect of approach direction. It also mentions return value. Lacks details on permissions or side effects, but the 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured: a concise one-line summary, followed by contextual paragraphs, then individual parameter descriptions. Front-loaded with key information. Could be slightly more concise, but appropriate for a complex ornament.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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, behavior, parameters, and output. An output schema exists, so the description doesn't need to detail return values beyond mentioning 'notes created, pitches used'. For a music notation tool with moderate complexity, 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?
Despite 0% schema description coverage, the description provides detailed explanations for all eight parameters: default values, ranges, musical meaning (e.g., 'approach_pitch: The grace note played first (default 62 = D4). Can be above or below main.'). This 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 the tool creates an appoggiatura, defines it as a leaning grace note resolving to main note, and explicitly differentiates it from mordent (quick flick) and other baroque ornaments like trill and turn. It uses specific verbs and musical context, 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 guidance on when to use (expressive ornament) and contrasts with mordent ('unlike a mordent'). It gives examples of above/below approach and adjustable ratio, but does not explicitly state when not to use or name alternative tools beyond ornaments. Still clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses behavioral traits: applies independent transformations to drums, bass, melody, and harmony; explains the effect of parameters like drum_density, bass_octave_shift, and melody_transform; and states that it returns 'notes per track and transformations applied.' This provides good transparency 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 fairly long but well-structured. It starts with a clear purpose statement, then breaks down transformations per track, lists parameters with explanations, and provides two usage examples. Every sentence adds value, and the examples help illustrate usage. Could be slightly more concise, but it earns 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?
Given the tool's complexity (19 parameters, 1 required) and the existence of an output schema, the description adequately covers the main parameters, explains transformations, and provides examples. It mentions return values. It doesn't cover all edge cases, but for a creative music tool, it is complete enough to guide 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%, but the description compensates exceptionally. It explains each parameter with concrete examples: drum_density ('0.3 = sparse, 1.0 = normal, 1.5 = busy'), bass_octave_shift ('0 = normal, +1 = octave up'), melody_transform lists allowed values, and include_* booleans. 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 immediately states the tool creates 'a musically varied section — not a repeat, a real variation.' It explicitly contrasts with sibling tool create_genre_sections (which repeats loops at different velocities), clearly distinguishing the tool's unique capability. The verb 'create' and resource 'arrangement variation' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 build a song where each section has real musical variation, not just energy changes.' It differentiates from create_genre_sections and provides concrete examples (breakdown, bridge). It does not explicitly state when not to use it, but the contrast with the sibling and the detailed parameter guidance imply appropriate contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers what the tool creates, the parameters, and the return value. It does not fully disclose whether it modifies existing tracks or creates new ones, but the parameter names suggest it operates on existing 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 well-structured with clear headings and a concise first line. However, it includes historical context that may be extraneous for an AI agent, making it slightly longer than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 params, no schema descriptions), the description covers all parameters and return info. It lacks explicit context on how the created notes integrate into the project (e.g., whether a new clip is created or notes are added to an existing 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 description provides detailed explanations for all 13 parameters, including default behavior (e.g., pedal_pitch -1 uses root at octave). This 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 first sentence clearly states 'Create a bariolage' and explains the technique. It distinguishes from siblings by explicitly contrasting with arpeggiator and montuno, making the purpose 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 contrasts with arpeggiator and montuno, giving context for when to use this technique (Baroque string). However, it does not explicitly list alternative tools or provide a decision tree for 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.
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 that the tool creates notes for riser and snare roll, details style-specific behaviors, and explains the meaning of each parameter. It does not mention whether it appends or overwrites existing notes, but overall is transparent about 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a brief intro, bullet points for style options, and parameter list. While it is longer than needed, every sentence adds value 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?
Given the output schema exists, the description provides sufficient information about return values. It covers all parameters, styles, and usage context. It could mention alternative tools like create_riser or create_section_transition, but is otherwise 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%, yet the description provides detailed explanations and default values for all 6 parameters. For the 'style' parameter, it explicitly lists all possible values and their musical effects, which 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 that the tool creates a complete build-up combining a riser and snare roll, specifying it is for use before a drop/chorus. It distinguishes itself from siblings like create_riser and create_trap_rolls by being a combined call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 (before a drop/chorus) and includes a usage example with create_impact. It does not explicitly state when not to use or list alternative tools, but the example and style options give clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that the tool places the counter-melody on track 4 by default to avoid clashing with melody, that velocity should be lower than melody, and describes five contrapuntal patterns. It does not mention return values, but the output schema exists. Overall, good behavioral disclosure 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 with a definition, explanation of patterns, parameter descriptions, and examples. It is front-loaded with purpose and uses bullet-like formatting for patterns. Every sentence adds value; no redundancy. Concise yet comprehensive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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, and a large sibling list), the description provides sufficient context. It explains the musical role, track placement, pattern variations, and parameter usage. The output schema exists but is not described, which is acceptable. The description is complete for an agent to understand 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 compensates by explaining the pattern options in detail, providing defaults and ranges for velocity, octave, bars_per_chord, and track_index. However, parameters start_beat and unit_index are not mentioned in the description. The examples illustrate usage for progression. Strong coverage for most 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 it creates a counter-melody from a chord progression. It distinguishes itself from similar tools by placing it in a quintet of harmonic tools and specifying track placement to avoid clashes with melody. The verb 'create' and resource 'counter_melody' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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: as part of a harmonic quintet and on a specific track. It explains the role of the counter-melody relative to melody and bass. However, it does not explicitly state when not to use or list alternatives, but the quintet positioning and pattern descriptions imply usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explains that the tool modifies velocities across all notes in a region, gradually from start to end, and returns the number of notes modified and velocity range. This is transparent about the effect. It does not mention potential side effects like overwriting existing velocities or undo behavior, but given no annotations, it provides reasonable 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?
Description is around 120 words, front-loaded with purpose and use case, then lists parameters succinctly. No redundant sentences. Slightly longer than minimal, but still efficient. Could be tighter, but 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?
Description covers the main behavior, parameters, and return values. It lacks discussion of error conditions or prerequisites (e.g., region must exist). Given the complexity (6 params, output schema), it is fairly complete but could mention edge cases. Still well above average.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 each parameter's meaning, valid ranges (e.g., velocities 0-1), and interpretation of special values (e.g., region_index -1). It also describes the curve options and their behavior. This adds essential 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?
Description clearly states verb 'apply crescendo or decrescendo' and resource 'existing notes in a region'. It explains the gradual velocity change and contrasts with other velocity tools by focusing on contour. While it doesn't explicitly differentiate from every sibling, the 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?
Description provides context for use: 'building tension or fading out'. This implies when to use but does not explicitly exclude alternatives or provide when-not-to-use guidance. Could be improved with reference to other velocity tools like apply_velocity_curve, but still helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 exhaustively explains the generated output: tracks, rhythmic patterns, chord progression, tempo, and expected note densities. It also mentions the return format (notes created per track and total).
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 headers and bullet points. It is informative and avoids fluff, though some repetition (e.g., tempo reference appears twice) could be trimmed.
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 (11 parameters, no annotations), the description is remarkably thorough. It covers the arrangement's musical content, parameter roles, and output format. The existence 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates for many parameters (bpm, bars, root, octave, track indices) but leaves out velocity, start_beat, and unit_index. Partial coverage prevents a higher 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 clearly states the tool creates a full disco arrangement with four specific tracks, chord progression, and tempo. It distinguishes itself from other arrangement tools by detailing unique disco characteristics and contrasting with house and 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 implicitly guides usage by detailing when to create a disco arrangement versus house or other styles, with explicit comparisons. However, it lacks a succinct statement like 'Use this tool to generate a classic 70s disco arrangement.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 generation process (subject, answer, countersubject, episode) and answer modes (real/tonal). It does not mention prerequisites (e.g., whether a track must exist) or side effects, but covers the core behavior 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 well-structured, starting with a definition, then a differentiation, followed by a clear parameter list. It is somewhat lengthy but appropriate for a complex tool; 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 16 parameters, no schema descriptions, and an output schema, the description covers the output (notes, preview, structure). It lacks information about error handling, prerequisites, or track setup, but overall is fairly complete for a creative 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 compensates thoroughly. It explains every parameter in detail, including types, defaults, an example for subject_notes, and the meaning of answer modes. This adds significant value 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 that the tool creates a 'fugato' and defines it as a fugal passage with subject entries and imitation. It distinguishes itself from a sibling tool (create_voice_exchange) by noting that fugato generates entirely new texture rather than transforming existing 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 explicitly contrasts with create_voice_exchange, providing clear context on when to use this tool. However, it does not explicitly state when not to use it or list alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 notes are created on a single track, both groups span the same total duration, and returns 'total notes created and hemiola ratio'. It does not disclose prerequisites, destructiveness, or undo capabilities, but the core behavior is transparent enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured: it starts with a clear purpose, then gives musical background, pattern explanation, parameter list, return info, and an example. It could be slightly more concise, but 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 complexity (10 parameters, 1 required, no output schema in structured data), the description adequately covers all parameters, explains the output, and includes an example. It is mostly complete, though it could specify whether the track must already exist or if the tool creates 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% (no descriptions in input schema), so the description must compensate fully. It provides a comprehensive list of all 10 parameters with their meanings, default values, and range constraints (e.g., bars 1-4, velocity 0-1). This goes well beyond what the schema alone offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 hemiola, a 3:2 rhythmic displacement, and provides a detailed explanation of the concept. It distinguishes itself from sibling tools like create_polyrhythm by specifically naming the pattern types (3:2 and 2:3) and the 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 explains the musical purpose and provides pattern options (3:2 and 2:3), giving clear guidance on when to use the tool. However, it does not explicitly tell when not to use it or compare with alternative tools like create_polyrhythm, which could have overlapping functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description details each variation type, non-destructive creation in a new region, and return value. It omits error handling but 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 well-organized with sections for purpose, variation types, and parameters. It is slightly verbose but each part 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 (12 parameters) and existence of output schema, the description covers core functionality, use cases, and parameter details adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Since schema coverage is 0%, the description fully explains all 12 parameters with clear meanings, including variation-specific ones like sequence_shift, augmentation_factor, and fragment_count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it extracts a motif and creates a variation in a new region. It uses specific verbs and distinguishes from sibling tools like extract_motifs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 it closes the analysis→creation loop and positions itself after extract_motifs. It also lists use cases but lacks 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes creation of a second copy, placement on parallel/cross-track, gradual drift per bar, direction, and parameter effects. Does not explicitly state side effects (e.g., track creation implications) or permission needs, but sufficiently transparent for a non-destructive 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?
Well-structured: starts with title sentence, then explanation of effect, historical context, sibling contrast, then detailed parameter list. Each sentence adds value. Slightly verbose but not wasteful; could be trimmed slightly but 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?
Given the tool complexity (8 parameters, specific phasing technique), the description covers concept, parameters, and sibling differentiation well. Output schema exists, so return values not needed. Missing edge cases like error handling or restrictions, but overall adequate for an AI 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?
Schema description coverage is 0%, so the description fully explains all 8 parameters with ranges, defaults, examples, and recommended values. Adds meaning beyond the schema's titles and types, covering unit_index, track_index, region_index, shift_per_bar, bars, direction, cross_track, and velocity_scale.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 phase-shifted copy using Steve Reich phasing, with a specific verb 'Create' and resource 'phase-shifted copy of a region'. It explicitly distinguishes itself from the sibling 'displace_rhythm' by contrasting single fixed offset versus gradually drifting copy.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 this tool (for gradual phase shifting) and explicitly contrasts with 'displace_rhythm' as an alternative. Includes recommendations for the cross_track parameter. However, no explicit 'when not to use' or list of scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description details what each transition type does (filter sweeps, volume fades, mute automation, impacts). Mentions return value (summary of automation). Does not mention if it overwrites existing automation, 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 relatively long but well-structured with header, parameter list, and examples. Every sentence adds value. Could be slightly more concise, but the detail is justified for a complex composite 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 complexity, annotations missing, and output schema present, the description covers purpose, all parameters, examples, and return value. It lacks error conditions or prerequisites (e.g., must have sections), but overall 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 coverage is 0%, but the description fully documents all parameters: transition_type with all options, start_beat, duration_beats, unit_indices with conventions. The description fully compensates 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 clearly states it creates a complete section transition combining multiple automation tools. It distinguishes from sibling tools by noting it replaces 3-5 individual calls. Each transition type is described with specific effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it's for moving between sections (verse->chorus, etc.) and that it replaces multiple calls. Provides examples but does not explicitly state when not to use it. Context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already show readOnlyHint, so description adds value by detailing algorithm steps (FFT, chroma, correlation) and return structure. No contradiction. Lacks error or performance notes but sufficient.
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?
Well-structured with clear sections: purpose, algorithm, use case, parameter, return values, example. Front-loaded. Slightly verbose on algorithm details but still 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?
Covers purpose, algorithm, input/output, integration pipeline, and example. Output schema not shown but described in full. Comprehensive for a single-param analysis 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 has 0% coverage for filename parameter; description compensates by explaining it can be a relative name (without path) or absolute path, and clarifies it's a WAV file. Adds significant 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?
Clearly states 'Detect musical key and mode of a WAV file' with specific algorithm references. Distinguishes from siblings like detect_bpm and detect_scale_from_notes by targeting key/mode detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes use case in Suno integration and remix pipeline, showing when to use this tool. Lacks explicit when-not-to-use vs alternatives but context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the mechanics (moves notes by scale steps, preserves scale), gives examples, and states the return value. It does not explicitly mention that the operation modifies notes in place, but the behavior is implied and 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient, starting with a clear verb and contrasting with siblings. The 'Essential for' section adds valuable context without being excessively verbose. Minor redundancy (e.g., examples already implied by parameter descriptions) keeps it from 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?
Given the tool's complexity, 0% schema coverage, and presence of an output schema, the description adequately covers purpose, parameters, behavior, and use cases. It distinguishes from a key sibling. It could mention the scope (all notes in specified region/unit/track) more explicitly upfront, but parameter descriptions 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 explain all parameters. It does so thoroughly: for 'steps' it gives examples (+1 up, -1 down, +3 third), for 'root_note' it lists all notes, for 'scale' it lists all scale names. Every parameter is well-documented beyond the schema's minimal 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 clearly states the tool transposes notes by scale steps (diatonic) and explicitly contrasts with the sibling tool transpose_notes (chromatic). It provides concrete examples like C→D and E→F, 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 includes an 'Essential for:' list of use cases (e.g., creating variations that stay in key, modal interchange) and contrasts with chromatic transposition, guiding when to use this tool. However, it does not explicitly 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and the description adds details: script wrapping in async arrow, access to DAW globals. No contradiction. Benefits from annotation coverage for 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, no fluff. Main action in first sentence, context in second, usage in third, parameter in fourth. Excellent front-loading and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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, usage, parameter details, and script environment. Output schema exists so return values are covered. Minor gap: no error handling or execution limits, but acceptable for a debug 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?
Only one parameter 'script' with 0% schema description coverage. The description compensates by explaining what the script can access and that it's wrapped as an async function body. Adds significant meaning beyond type 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?
Clearly states it executes arbitrary JavaScript in the DAW V8 context. The verb 'execute' and resource 'JavaScript' are specific. No sibling does arbitrary code execution, so it stands out.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly targets power users and debugging for exploring openDAW internals. Implicitly advises against using for routine tasks, but does not list explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 anchor behavior (first note kept, or mean centered), the effect on intervals, and snap-to-scale option. It doesn't detail side effects like reversibility or whether it modifies in place, but overall provides solid 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 summary, examples, and parameter list. It is slightly lengthy but necessary given the parameter count, and front-loads the key purpose. 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 7 parameters, no annotations, and presence of output schema, the description covers inputs comprehensively. It implies modification of notes in the region but doesn't explicitly state the output or side effects (e.g., whether notes are replaced). Still robust for most 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%, but the description fully documents all 7 parameters: unit_index, track_index, region_index, factor, anchor, snap_to_scale, and root. It includes defaults, range for factor (0.25-4.0), and explanations for each anchor and scale option.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 expands or compresses melodic intervals by a factor, with concrete examples for different factor values. It distinguishes itself from sibling tools like transpose (which shifts all notes equally) and invert by focusing on interval multiplication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 as 'a fundamental transformation in motivic development' and gives example factors for typical uses. However, it does not explicitly state when not to use this tool or compare directly to alternatives beyond the implicit differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses internal mechanism (PresetEncoder.encode), dependencies (instrument, effects, etc.), base64 encoding, and return type. It is transparent about what gets serialized.
Agents need to know what a tool does to the world before calling it. Descriptions 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 (approx. 100 words), front-loaded with the main purpose, then technical details, then parameter explanations. No redundant 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?
Given the output schema exists, the description need not detail return values, but it still mentions returning base64 bytes and metadata. It covers all necessary aspects for a 2-parameter export 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 description must add meaning. It explains unit_index must be an instrument (not Output) and include_timeline includes tracks/regions/notes. This goes 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 clearly states the tool exports an audio unit as a preset in base64-encoded format. It specifies the verb 'export', the resource 'audio unit', and the output format. This distinguishes it from siblings 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through parameter constraints (unit_index must be an instrument, not Output) but does not explicitly compare to other export tools or state when to prefer this one. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 is a read-only query returning overlapping notes, with no side effects. It does not explicitly state read-only, but the description implies 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 (6 lines), with purpose first, then usage, then parameter list. Every sentence adds value, 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?
Given the tool's low complexity and presence of an output schema, the description covers purpose, usage, parameters, and return format. It could mention the output schema's structure, but that is not essential.
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?
All 6 parameters are described with clear definitions despite the schema having 0% description coverage. The description adds meaning (e.g., pitch '60 = C4', from_beat and to_beat as time range boundaries).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 finds notes overlapping a given pitch and time range within a note region. It uses specific verb+resource ('Find notes that overlap') and distinguishes from siblings like list_notes or filter_notes by focusing on overlap detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions two specific use cases: collision checking and harmony/chord finding. It implies when to use this tool but does not explicitly state when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 value by stating that the tool returns metadata and type-specific info (notes count, audio file, automation events). This provides 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 concise: one sentence for the purpose, then a brief parameter list. It is front-loaded with the key information and contains no redundant or vague statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 focuses on input parameters and high-level return info. It mentions type-specific details, which is sufficient for an agent to understand what the tool provides. Could potentially mention that it returns detailed region metadata, but overall it 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 has no descriptions (0% coverage), so the description compensates by explaining each parameter (e.g., 'track_index: Track index within the AU'). This adds meaning beyond the schema's titles, helping an agent correctly specify the target region.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 ('Get detailed info about a single region') and lists the specific attributes returned (position, duration, loop, mute, content). It distinguishes itself from sibling tools like 'get_track_info' and 'list_notes' by focusing on a single 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 explains each parameter's role (unit_index, track_index, region_index), providing context on how to use the tool. However, it lacks explicit guidance on when to use this tool versus alternatives (e.g., listing all regions). The purpose is clear enough that an agent can infer usage for retrieving specific region info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adequately explains the algorithm: reads notes, groups by temporal overlap, matches pitch-class sets. It informs that the tool returns chord lists with time, root, type, and confidence, and describes parameter effects (e.g., group_tolerance, min_notes). Slight omission of project-state implications (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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, process explanation, use cases, and parameter list. It is relatively concise given the amount of information, though slightly verbose in the algorithm section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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, no schema descriptions, and no annotations, the description covers input explanation, process, and output. It lacks edge-case handling (e.g., empty region, identical chords), but provides sufficient context 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?
All 5 parameters are described in the description with clear explanations beyond the schema's type/default: unit_index and track_index as indices, region_index with -1 meaning first, group_tolerance explained with musical context (16th note), min_notes with a triad example. This compensates fully for 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 begins with 'Identify chords from existing notes in a region — harmonic analysis / reverse engineering,' providing a specific verb and resource. It clearly differentiates from sibling analysis tools by focusing on chord identification from note regions, explaining the grouping and matching process.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 clear use cases: understanding imported MIDI, analyzing AI-generated progressions, reverse-engineering harmony, verifying chords. While it doesn't explicitly state when not to use it or name alternatives, the contexts are specific and helpful for an AI agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the tool's behavior: it removes notes at specified beat positions, and explains the three deletion modes (delete, truncate, shorten), tolerance, and neighbor shortening. No annotations are provided, so the description carries the full burden. It clearly communicates the destructive nature but does not mention undo behavior or error handling.
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 intro, comparison to a sibling, and a detailed Args section. While comprehensive, it could be slightly more concise; however, it remains readable and front-loaded with 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 that an output schema exists, the description does not need to explain return values. It adequately covers the tool's behavior, parameter meanings, and mode details. Missing elements like prerequisites (e.g., existence of notes at positions) 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?
The input schema has 0% description coverage, but the 'Args' section in the description provides thorough explanations for all 7 parameters, including examples (e.g., '0,1,2,3' for rest_positions) and clarifications (tolerance in musical terms like 'within a 32nd note'). This 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 the tool's purpose: 'Insert rests at specified beat positions by removing notes.' It explains the effect (creating space, syncopation, breathing room) and distinguishes itself from the sibling tool 'thin_notes' by emphasizing positional control rather than interval/velocity/random strategies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 'thin_notes,' providing a clear alternative and indicating when to use this tool (positional rest insertion). However, it does not mention other potential alternatives like 'delete_note' or conditions when not to use this tool, slightly limiting guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the internal process (find notes at beat, group as chord, move notes) and return fields (notes_inverted, original pitches, etc.). Does not mention error conditions but is fairly transparent for a technical 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?
Description is structured with a summary line, explanatory paragraph, and parameter list. Slightly long but each part adds value. 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?
Given the output schema, the description covers return values and inputs. Does not specify prerequisites (e.g., chord must exist at position) or error handling, but overall sufficient for a mutation 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 compensates by listing all parameters with explanations (e.g., inversion=1 first, 2 second, 3 third for 7th chords; direction up=standard, down=drop). Adds value beyond schema defaults and 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 inverts chord notes by moving bottom N up or top N down an octave. It explains inversions (1st, 2nd) and distinguishes from siblings like invert_notes and spread_voicing by focusing on chord voicing at a specific beat position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 inversion theory and parameter roles but does not explicitly compare to alternatives like spread_voicing or invert_notes. It implies usage for changing chord voicing without altering the chord itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation indicates readOnlyHint=true, and the description reaffirms a read-only behavior by stating 'List' and 'Shows'. It adds behavioral details such as returning field names, current values, and automatable status, and explains the parameters. No contradictions 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 concise with three focused sentences: purpose, key behavior note, and parameter explanations. No unnecessary words, 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 simplicity and the presence of an output schema (as indicated by context signals), the description adequately covers purpose, parameters, and return values (field names, current values, automatable flag). The description is sufficient for an agent to understand and 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?
Schema coverage is 0%, so the description must provide parameter meaning. It explains unit_index as 'Audio unit index containing the instrument' and sample_index as 'For Playfield, which sample slot (-1 = top-level instrument)', adding clear semantics beyond the schema's type 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 'List all automatable parameter fields on an instrument (or specific Playfield sample)' and specifies that it shows fields supporting 'Pointers.Automation'. This differentiates it from sibling tools like list_effect_parameters and list_instrument_params, which likely list all parameters without the automation filter.
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. It implies usage for discovering automatable fields before applying automation, but does not provide direct guidance on when not to use it or mention specific sibling tools. The context is moderately clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true. Description adds that it returns SDR scores and use-case recommendations, providing behavioral detail 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?
Two sentences, no waste, front-loaded 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?
Adequate for a parameterless list tool with an output schema. Mentions sibling tool and output contents.
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?
No parameters exist, so schema is fully covered. Description adds no parameter info but is not 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 verb 'List' and the resource 'available stem separation modes', and distinguishes it from siblings by explicitly linking to mcp_opendaw_split_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?
Implies usage before calling split_stems to see available modes. No exclusions or alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details merging behavior, delete_source option, overlap resolution strategies, transpose, and region handling. It does not mention side effects like permanent changes or performance, but the key behaviors are 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, comparison, use cases, and parameter list. It is front-loaded with the main action. While slightly lengthy, every section contributes useful information, making it appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain return values. However, for a complex tool with 9 parameters and overlap strategies, the parameter semantics are thorough. Minor gap in return value documentation 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 coverage is 0%, but the description includes an 'Args' section that explains each parameter in detail, including defaults, meaning, and allowed values (e.g., resolve_overlaps strategies). This adds significant 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 'Merge notes from a source track into a destination track' and explicitly distinguishes from sibling tool copy_notes_to_track, saying it consolidates two note streams rather than just copying. This provides a specific verb+resource with clear 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 typical use cases (e.g., merge a doubled melody, consolidate counterpoint) and contrasts with copy_notes_to_track. However, it does not explicitly state when not to use this tool, though the contrast implies the exclusive scenario. Slightly lacking in exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and details the non-destructive nature, scanning all tracks across audio units, moving with relative offset, and returning counts. It does not fully disclose if automation or other data is moved, or potential limitations, but overall it is 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise first sentence and a clear breakdown of parameters and examples. While somewhat lengthy, every sentence adds value and no extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 (though not shown), the description adequately covers use cases, parameters, and return value summary. It does not address error conditions or edge cases, but for a moderately complex tool, it provides sufficient context 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?
Despite 0% schema description coverage, the description explains all four parameters in detail: from_beat, to_beat (exclusive), target_beat (beat 0=start), and unit_indices (default all). Examples further clarify usage, fully compensating 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 moves all regions within a beat range to a new position, specifying it's a cut-and-paste operation. It distinguishes from duplicate_section by noting it removes the original, and provides concrete examples like 'move the bridge from bar 33 to bar 17', 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 explicitly contrasts with duplicate_section and notes it replaces multiple delete+create sequences, giving clear when-to-use guidance. However, it lacks explicit when-not-to-use or prerequisites, though the context is sufficient for an agent to make informed decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details how sections are collected, placed sequentially, and that lengths are preserved. No annotations provided, so the description bears full burden and does it 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 well-structured with a summary, explanation, contrast, parameter details, and example, though slightly lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 parameters, return values, and example; missing error conditions or project impact details, but adequate given output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 coverage, the description fully explains both parameters: section_order as a JSON array with start/end beats and example, unit_indices as comma-separated indices or empty for 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 clearly states 'Reorder song sections — rearrange blocks on the timeline' and contrasts with swap_sections, making it distinct 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 vs swap_sections with an explicit example, but does not cover all 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It thoroughly explains core behaviors: copying an entire phrase, transposing, placing copies sequentially, and details on velocity patterns, time stretch, and cross-track placement. It does not mention authentication or rate limits, but these are less critical for a DAW tool. The behavioral disclosure is comprehensive and clear.
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 concise summary and well-structured. It includes a brief conceptual explanation, differentiation, parameter details, and musical context. While the historical references (Bach fugues, etc.) add depth, they could be trimmed. Overall, it is appropriately detailed 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?
Given the complexity of 13 parameters and domain-specific concepts, the description provides nearly complete guidance. It covers all transformations and parameter effects. An output schema exists, so return values need not be detailed. Lacks details on error conditions or prerequisites (e.g., existence of source region), 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 description coverage is 0%, so the description must compensate fully. The 'Args:' section explains all 13 parameters with defaults, allowed values, and contextual meaning. Each parameter's role and effect is clearly described, adding significant 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 'Repeat a melodic phrase N times with transposition — melodic sequence.' It specifies the verb (repeat), resource (melodic phrase), and key action (with transposition). It effectively distinguishes this tool from repeat_notes and create_sequence, 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 explicitly contrasts this tool with repeat_notes ('Unlike repeat_notes...'), providing clear guidance on when to use it over that sibling. It also explains the difference between diatonic and chromatic transposition, helping users choose the appropriate mode. However, it does not provide explicit 'when not to use' scenarios or additional alternatives beyond the one comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it deletes old instrument and creates new one, returns old/new types. Specifies preconditions (CaptureMidiBox) and limitations (not for tape). Lacks details on side effects like preservation of effects or automation, but given no annotations, this is thorough.
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?
Description is compact with no redundant sentences. Starts with action, then API, then constraints, then parameters. Could benefit from bullet points for parameters, but overall well-structured.
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, constraints, parameters, return value, and distinguishes from dozens of siblings. Despite no annotations, provides all information needed for an agent to decide 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?
Compensates for 0% schema coverage by explaining unit_index must be >=1 and listing exact factory keys for new_instrument. Provides valid values and constraints, enabling correct tool 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 clearly states it replaces the instrument on an audio unit with a different MIDI instrument. Specifies the API used and constraints on instrument types (only MIDI, not tape), distinguishing it from create/manage instrument 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?
Provides clear context on when to use (replace MIDI instrument) and constraints (only for specific instruments, AU must have CaptureMidiBox). Does not explicitly contrast with alternatives like replace_from_preset, but constraints effectively guide usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 cyclic shift behavior, direction (positive=left, negative=right), modulo wrapping, and the effect of each axis value. It also describes the preserve_pitch_contour option. However, it does not explicitly state whether the operation is in-place or returns a result, 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: a one-sentence summary, a detailed explanation of the operation, usage contexts, and a clear Args list. It is longer than necessary but every sentence adds value. The front-loading is good, with the core operation immediately stated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 (6 parameters, no annotations), the description covers the tool's behavior and all parameters adequately. An output schema exists but is not described, which is acceptable because the schema provides that information. The description is complete 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.
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: for each parameter (axis, rotate_by, unit_index, track_index, region_index, preserve_pitch_contour) it explains meaning, default values, and constraints (e.g., rotate_by wrapped modulo note count, region_index -1 meaning first region). This 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 the tool rotates notes in a region cyclically. It specifies the verb ('rotate'), resource ('notes in a region'), and operation ('cyclic shift'). The explanation of how the shift works (first rotate_by notes move to end) and the mention of compositional techniques distinguish it from siblings like shuffle_notes or reverse_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 usage contexts: serialism, jazz melodic variation, and electronic music pattern transformation. It gives practical guidance on when to use the tool but does not explicitly state when not to use it or suggest alternatives. This is sufficient for most agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description details the behavior for each mode, clamping to 0-1, and states return values (count, original range, new range). Missing permission or undo implications, but overall transparent for a velocity scaling 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 summary, contrast, mode explanations, parameter list, returns, and examples. It is slightly long but efficient; every sentence adds value. Could be more concise but front-loads purpose effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 7 parameters and 5 modes, the description covers purpose, all mode semantics, parameter roles, return values, and examples. It lacks error conditions or edge cases, but for a velocity scaling tool it is comprehensive. Output schema exists but description 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?
Schema description coverage is 0%, so the description must compensate. It thoroughly explains mode options (multiply, add, set, normalize, compress) with semantics, clarifies value depends on mode, describes region_index/ min/max_velocity clamp, and provides examples. 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 scales velocity of all notes in a region, using specific verb and resource. It explicitly distinguishes from the sibling tool create_crescendo, making the 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 contrasts with create_crescendo and explains the uniform scaling nature, but does not cover when to use alternatives like apply_velocity_curve or quantize_velocities. It provides mode explanations that guide usage, but lacks 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.
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 it's a fallback and lists known integer fields, providing some behavioral context. However, it does not disclose potential side effects (e.g., what happens if the parameter_name is invalid), permissions, or error behavior. While it covers the basics, it lacks depth 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 main sentence, a bulleted list of examples, and a usage note. It is reasonably concise, though the bullet list could be slightly trimmed. Overall, 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 complexity and presence of an output schema, the description covers the core functionality, usage guidance, and parameters. It could mention return behavior or errors, but it is fairly complete for a tool that sets integer parameters on 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?
The description adds significant meaning beyond the input schema. Schema coverage is 0%, so it compensates by explaining each parameter (unit_index, effect_index, parameter_name with examples like 'bandCount', 'bits', and value). This makes the schema much more 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 clearly states the tool's purpose: 'Set an integer parameter on an audio effect.' It specifically lists covered fields (Vocoder bandCount, StereoTool panningMixing, etc.) and distinguishes itself from the generic float setter and device-specific tools like set_vocoder_band_count. This leaves 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 notes that device-specific tools are preferred when available, and this is a generic fallback. This provides clear guidance on when to use this tool vs alternatives, which is crucial for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 states the effect (creates a NeuralAmpModelBox, links to device), the bypass behavior, and the return value (success + model_size or error). It does not mention potential side effects like overwriting existing models, but overall it's 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 concise and front-loaded with the main action. It then lists parameters in a clear list. It could be slightly more structured, but 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's complexity (5 params, 3 required, output schema exists), the description covers the core functionality, parameter roles, and return behavior. It doesn't mention prerequisites or detailed outcomes, but it's 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 schema has 0% description coverage, but the tool description compensates excellently by explaining each parameter: unit_index (AU index), effect_index (must be a NeuralAmp), model_json (full NAM JSON), label (optional, default), pack_id (optional). This adds significant meaning beyond the 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 starts with a clear verb and resource: 'Load a Neural Amp Modeler (NAM/Tone3000) model JSON into a NeuralAmp effect.' It distinguishes the tool from siblings like 'get_neuralamp_model' by focusing on the loading action and mentioning that it bypasses the popup flow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 (headless model loading) and what it achieves (bypasses popup flow), but lacks explicit comparisons to alternatives or exclusions. Still, the context is clear enough for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that original notes are replaced in place when dest_track_index=-1, and that accent_first is overridden by velocity_pattern. However, it does not state whether the operation is destructive or reversible, nor any performance or constraint implications (e.g., note overlap, time boundaries).
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 concise intro, a use-case sentence, then a clear Args list. It is slightly verbose in the Args (e.g., repeating 'original'), but all sentences add value. Could be tightened without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 (8 params, 2 required, output schema exists) and many siblings, the description covers inputs, behavior, and use cases well. It does not describe the output (though output schema exists), but that is acceptable. It lacks mention of time signature or tempo constraints which might affect subdivision.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 provides detailed explanations for all 8 parameters, including example values and effects (e.g., subdivisions: '2=diminution, 4=sixteenth fragmentation, 3=triplet subdivision'). This adds significant meaning beyond the 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: 'Subdivide each note in a region into N smaller notes.' The verb 'subdivide' and resource 'note region' are specific. It distinguishes itself from sibling tools like 'augment_notes' or 'apply_velocity_pattern' by focusing on rhythmic fragmentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 says 'Useful for diminution, rhythmic fragmentation, and creating faster passagework from longer notes,' giving clear context. However, it does not provide when-not-to-use guidance or compare with alternatives like 'consolidate_note' or 'repeat_notes', which could help the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details internal steps (auto-detect BPM, transcribe drums to specific pitches, transcribe melody with cents+clarity, create MIDI notes via create_notes_batch) and mentions returns. It lacks side-effect information but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence summary, then composite explanation, pipeline steps, use cases, parameter list, and example. It is concise (no filler) and front-loaded with the most important 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 complexity (audio to MIDI with multiple tracks, BPM detection), the description covers key aspects: purpose, pipeline, use cases, parameters, and returns. It could mention file format constraints or performance notes, but it's largely complete for selection and 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 coverage is 0%, but the description compensates by describing each parameter: filename (with path hint), bpm (default 0 meaning auto-detect), unit_index, drum_track, melody_track. It adds meaning beyond the bare schema, though could be more precise about filename 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 it transcribes a full audio track into MIDI notes, specifying drums and melody. It distinguishes itself by being a composite of transcribe_drums and transcribe_melody, which are listed as sibling tools, and explicitly says it eliminates two separate 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 provides pipeline steps and use cases (e.g., Suno-to-MIDI pipeline, extract groove, convert loop), making it clear when to use. It implicitly contrasts with separate transcribe calls but doesn't 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.
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 that the effect is added to the MIDI effect chain, that it processes note data before the instrument, and that the unit type must be an instrument AU. It also mentions the return of effect_index. This is good transparency, though it doesn't mention potential side effects or ordering.
Agents need to know what a tool does to the world before calling it. Descriptions 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 sentence for purpose, then two sentences for context and details. No redundant words, and the information is front-loaded. 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 presence of an output schema, return values need not be explained. The description covers the tool's purpose, the separate chain, parameter constraints, and effect_type options. It does not specify the order of effects in the chain or behavior when multiple effects exist, 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 description coverage is 0% (no parameter descriptions in schema). The description compensates fully by explaining that effect_type must be one of the listed values (Arpeggio, Pitch, Velocity, etc.) and that unit_index must be an instrument AU, not output. This adds critical meaning 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 clearly states the verb 'Add' and resource 'MIDI effect to an audio unit's MIDI effect chain'. It distinguishes from audio effects by explicitly separating MIDI effects (midiEffects) from audio effects (audioEffects), which differentiates it from siblings 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 provides clear context: MIDI effects process note data before the instrument, they are chained separately, and the unit must be an instrument AU (not output). It lists valid effect_types. However, it does not explicitly state when not to use this tool or offer direct alternatives, missing a small opportunity for explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 thoroughly explains the behavior: inserts diatonic passing tones on weak beats, stepwise, respecting scale and duration. It mentions cross_track to preserve original melody, but could clarify if this is additive or modifies 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, but is somewhat lengthy. However, every sentence contributes value, 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?
Given the complexity (10 parameters, no annotations, output schema present), the description covers the operation, conditions, and parameters completely. No gaps remain for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It does: each parameter (unit_index, track_index, region_index, scale, root, max_interval, velocity, duration_fraction, direction, cross_track) is described with defaults, ranges, and meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 passing tones to smooth melodic lines, specifies it's a counterpoint technique, and distinguishes it from similar tools by focusing on stepwise filling of large intervals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 conditions for when passing tones are added (interval > 2 semitones, time gap >= 1/8 note, interval <= max_interval), but does not explicitly mention alternative tools like neighbor tones or anticipations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses the underlying mechanism (normalized values, automatic mapping from BPM), interpolation behavior, and that it returns the created tempo event and full tempo map. It does not mention side effects or destructive actions, but the tool's purpose 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is multiple sentences but each provides essential information: purpose, mechanism, parameter descriptions, return value. It is well-structured and front-loaded, though slightly verbose 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 tool's complexity (3 required params, no enums, no annotations, no schema descriptions), the description covers all necessary aspects: what it does, how it works internally, parameter meanings, and output. It is complete 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?
With 0% schema description coverage, the description fully compensates by explaining all three parameters: position_beats (position in beats), bpm (target BPM 60-240), interpolation (linear/hold). It adds constraints, examples, and 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 the tool adds a tempo (BPM) change at a specific position in the track. It explains the creation of ValueEventBox on the tempo track for mid-track automation, distinguishing it from other tempo-related tools like set_bpm or create_tempo_ramp.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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: adding BPM changes mid-track with examples (e.g., 120→90→140). It explains automatic conversion and interpolation types but does not explicitly contrast with alternatives like set_bpm or create_tempo_ramp, though the sibling list implies these exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details the analysis process (identifying chords from MIDI notes using the same logic as identify_chords) and lists all output fields (chord change positions, durations, rate, density, etc.). Annotations already provide readOnlyHint=true, and the description is consistent with that. The description adds behavioral context beyond annotations by explaining the types of analysis performed.
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 concise opening, bullet points for output, usage guidance, parameter list, and return value note. It is informative without being overly verbose, though it could be slightly more concise by condensing some bullet points. Nonetheless, each sentence serves a 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 complexity (5 parameters, multiple output fields, relationship to other tools) and the presence of an output schema, the description covers all necessary aspects: purpose, inputs, outputs, usage relationships, and parameter details. It provides a complete picture for an AI agent to correctly 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?
Input schema has 0% description coverage, so the description fully compensates. It explains each parameter in a separate bullet: unit_index, track_index, region_index (with special values -1 and -2), group_tolerance (with default 0.25), and min_notes (with default 3). This adds critical meaning beyond the schema's parameter 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 clearly states the tool's purpose: 'Analyze harmonic rhythm — how fast chords change and where.' It lists specific outputs (chord change positions, durations, rate, density, etc.) and explicitly distinguishes itself from the sibling tool identify_chords, which focuses on chord identification rather than temporal patterns. This provides a clear and distinct 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 explicit usage guidance by listing companion tools: 'Use with: analyze_song_structure, reharmonize_progression, create_arrangement_variation.' It also explains how it complements identify_chords. While it does not explicitly state when not to use, the positive guidance is strong and helps the agent 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the behavior: scans all note tracks, computes per-bar features, groups consecutive bars, and classifies segments. It also mentions the return format (per-segment classification with bar range, density, energy, feature summary). The annotation readOnlyHint: true is consistent with the analysis nature. The description adds behavioral context 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 well-structured: first sentence states the core action, then details the method, then lists essential use cases, finally explains parameters. Every sentence adds value; 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?
Given the tool's moderate complexity and the presence of an output schema, the description covers all necessary context: input parameters, process, and return values. It is complete enough for an agent to understand what the tool does and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description fully explains both parameters: unit_index ('AU index (-1 = all AUs)') and bars_per_segment ('Minimum bars per structural segment... groups of bars with similar density are merged...'). This adds significant meaning 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 purpose: 'Analyze song structure by segmenting MIDI content into structural parts.' It details the method (bar-by-bar, per-bar features, grouping, classification) and lists specific section types (intro/verse/chorus/bridge/outro/breakdown). This distinguishes it from sibling analysis tools like analyze_dynamics or analyze_harmonic_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: 'Essential for: understanding existing arrangements, finding where sections change, verifying song form, and planning variations or extensions.' This guides the agent on when to use the tool. However, it does not explicitly state when not to use it or contrast with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description discloses that pitches are redistributed, timing and duration unchanged, snap-to-scale option, and preservation of original pitch range center. It does not mention return values or potential side effects beyond modification.
Agents need to know what a tool does to the world before 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: starts with one-sentence summary, then explanatory paragraph, lists contour shapes, then parameter descriptions. Efficient 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?
Covers core functionality and parameters well. Does not describe return values or error conditions, but the presence of an output schema reduces the need. Overall adequate for a transformation 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 coverage, the description adds extensive meaning: explains all parameters (unit_index, track_index, region_index, contour, range_semitones with range, snap_to_scale with options, root, preserve_first/last). 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 applies a melodic contour shape to existing notes, contrasting with transpose_notes. It provides specific verb and resource, and distinguishes from sibling tools by explaining the difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 transpose_notes, providing an alternative. It implies when to use this tool (reshaping melody) vs uniform shift, but lacks 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It details inputs (note positions, pitches via GM map, velocities), outputs (classification, confidence, features, per-bar breakdown), and lists pattern types. It does not explicitly state that the tool is read-only (no side effects), but the context implies it is analytical.
Agents need to know what a tool does to the world before calling it. Descriptions 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: one-sentence summary, details on analysis method, pattern list, use cases, then parameter explanations. It is concise at ~120 words 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?
Given the tool's analytical nature and the presence of an output schema, the description covers input selection, analysis parameters, output format (classification with confidence, features, per-bar breakdown), and usage scenarios. It does not detail the output schema fields but that is handled by the structured output.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 fully by explaining each parameter: unit_index (AU index, -1 for all), track_index, region_index with defaults. 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool classifies drum patterns from MIDI notes, lists specific pattern types (e.g., four-on-the-floor, breakbeat), and provides the GM drum map. This uniquely distinguishes it from sibling tools like 'analyze_dynamics' or '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 lists use cases: understanding patterns, matching genre expectations, verifying patterns, and suggesting variations. However, it does not mention when not to use it or suggest alternative tools for related tasks like drum transcription.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: the original note is deleted, the expansion creates N independent notes with playCount=1 positioned by the curve, and the return value. This is transparent, but could mention potential side effects on region or track 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 well-structured with a clear first sentence, explanatory paragraph, parameter list, and return value. Every sentence adds 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?
The description covers purpose, prerequisites, parameters, and return value. It could mention if the region length is affected, but overall it is adequately 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 descriptions are missing (0% coverage), but the tool description adds meaningful parameter explanations (e.g., 'unit_index: AU index') for all four parameters, greatly aiding the agent in correctly identifying hierarchical 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 consolidates a repeated note (playCount > 1) into individual separate notes. It explains the concept, parameters, and return value, distinguishing it from siblings as a specific note expansion 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 explicitly states when to use the tool: when a note has playCount > 1. It also notes the error condition for playCount=1, indicating when not to use it. However, it doesn't mention alternative tools for similar operations like merge or split notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 returns notes, an instrument breakdown, stroke types, and rhythm info. It also explains the instruments and stroke mappings, providing moderate transparency. However, it does not explicitly state whether notes are added to an existing track or if there are side effects, though the parameters (unit_index, track_index, start_beat) imply placement.
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 sentence, but it is lengthy due to extensive educational material on Arabic percussion. While well-structured (purpose, background, stroke types, rhythms, args), it could be more concise without losing essential information. The educational content is valuable but adds 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 cultural complexity and 9 parameters, the description is highly complete. It covers all parameters, explains stroke vocabulary and rhythms in detail, and mentions return values. The output schema exists (though not shown), so the description's lack of return format detail is acceptable. No gaps remain for the intended use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 includes an 'Args' section that lists and explains all 9 parameters with brief, meaningful descriptions (e.g., 'bars: Pattern length in bars (2-16, even).'). This adds substantial meaning beyond the bare schema, compensating fully for the coverage 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 starts with a clear, specific verb and resource: 'Create an Arabic/Middle Eastern percussion ensemble.' This immediately distinguishes it from sibling tools like create_djembe_ensemble (African) or create_taiko_ensemble (Japanese), as well as generic create_drum_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 does not explicitly state when to use this tool versus alternatives, but the rich educational content about Arabic rhythms, instruments, and stroke vocabulary provides clear context for when this tool is appropriate. It implicitly guides the agent toward Middle Eastern music creation without specifying exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the two-phase generation process, parameter roles, and return value. However, it does not clarify if notes are appended or overwritten on the 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 with a clear purpose statement, context, phase breakdown, parameter list, and return value. It is slightly long but every part is informative.
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 (9 parameters, no required, output schema exists), the description covers the purpose, usage, parameters, output, and genre context comprehensively.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 explains all 9 parameters with defaults, ranges, and musical context, adding 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 the tool creates a bass drop with two phases (sweep and hold). It specifies the sound effect and use cases (dubstep, EDM, trap), distinguishing it from sibling tools like create_buildup 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?
The description explains when to use it (e.g., 'quintessential dubstep/bass music drop') but does not explicitly mention 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that cadenzas use irregular, speech-like rhythm, can include accelerando, rallentando, fermatas, and pauses, and mentions output (notes created, segment breakdown, statistics). It lacks detail on potential side effects or permissions but is thorough 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections for definition, contrast, styles, segment types, and arguments. However, it is slightly verbose; some sentences could be trimmed 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?
Given 11 parameters, no annotations, and only a mention of output schema, the description is exceptionally complete. It explains the tool's unique role, styles, segment types, all parameters, and expected return data, making it fully actionable 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 must compensate. It explains every parameter (root, scale, style, octave, velocity, virtuosic, breath_marks, duration_beats, unit_index, track_index, start_beat) and adds context about segment types (Flourish, Leap, Trill, etc.), providing meaning far beyond the schema's 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 'Create a cadenza — an unmeasured virtuosic solo passage with rubato.' It defines a cadenza, contrasts it with quantized beat grid tools, and lists styles and segment types, making the purpose specific and distinguishable from 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 explains when to use this tool (for unmeasured, rubato passages) by contrasting with other tools that use quantized beat grids. It provides clear context but does not explicitly list alternatives or when not to use it, which would make it a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 details voice-leading rules, voice ranges, and that it returns notes created and voice-leading info. It does not explicitly state side effects (e.g., whether notes are appended or overwritten), but the behavior 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and structured with paragraphs for voice-leading rules and parameter details. While somewhat lengthy, each sentence adds value. Parameter descriptions are clear but could be more 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?
Given the tool's complexity (4 voices, voice-leading, 14 parameters), the description is thorough. It covers voice-leading rules, range constraints, parameter semantics, and output description. The presence of an output schema helps, but the description still adds 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?
The schema has 0% description coverage, but the description fully compensates by providing clear, detailed explanations for all 14 parameters, including defaults, formats, and supported values (e.g., chord_pattern lists all chord types). 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 clearly states 'Create a 4-voice SATB chorale with voice-leading rules', specifying both the verb (create) and resource (chorale). The additional context of 'Classic Bach chorale style' distinguishes it from other creation tools like create_chord_pads or create_melody, 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 provides context for when to use the tool, mentioning its suitability for 'vocal harmonies, string arrangements, synth pad layering'. However, it does not explicitly state when not to use or compare with alternatives like create_harmony or create_bassline, which would strengthen guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description explains key behaviors: exponential curve default, resonance_boost effect, default cutoff values. Could mention if it overwrites existing automation, but overall good.
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?
Well-structured: purpose first, then usage context, then parameter list, then examples. Every sentence adds value, though slightly lengthy.
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, includes examples, mentions return value (events, config, preview of curve). Output schema exists but description still provides enough 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 description thoroughly explains each parameter with defaults, ranges, and typical usage. Examples demonstrate practical 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?
Clearly states 'Create a filter sweep on a Vaporisateur instrument's cutoff parameter' with specific verb and resource. Distinguishes from sibling tools by focusing on a common EDM transition 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 context for when to use: 'The most common transition technique in EDM/techno/house' and describes build-up vs breakdown. Does not explicitly mention alternatives among siblings, 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains what the tool does, the pattern structure, and floor_type variations. It mentions return values (notes created, floor type, stroke breakdown). Lacks detail on side effects or authentication, but 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 long but well-structured: purpose, background, parameter explanations, and example calls. Could be slightly more concise, but all information is necessary and ordered logically.
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 presence of output schema, the description covers tool purpose, all parameters with defaults, examples, and return description. It is comprehensive and leaves no major 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%, so description adds all parameter meaning. It explains each parameter (floor_type, bars, kick_pitch, etc.) with defaults and examples. Adds musical context beyond parameter names, fulfilling the requirement completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'four-on-the-floor pattern' and defines it explicitly. It lists five distinct floor types with musical context, differentiating from other drum pattern tools. The verb-object relationship 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 for when to use this tool (foundational beats for house, techno, disco). It does not explicitly state when not to use it or name alternatives, but the context is strong enough for an 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description thoroughly discloses the sequence of operations: setting BPM, creating tracks, arranging, optional harmonic layers, genre mix, sidechain, mastering. It also notes the end state ('ready for export_audio / render'). Lacks details on potential destructive actions or error conditions, 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?
Well-structured with a summary, numbered steps, parameter list, return value, and examples. Though lengthy, the information is front-loaded and every sentence serves a purpose. Slightly verbose in the parameter descriptions but necessary due to no schema descriptions.
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 absence of annotations and schema descriptions, the description fully covers the tool's purpose, parameters, behavior, and output. It addresses the 8 parameters, explains the pipeline, and tells the agent what to expect after invocation. Very 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, but the tool description provides detailed explanations for all 8 parameters, including defaults, constraints (e.g., 'pop min 16' for bars), and behavior (e.g., 'pads and bass are skipped' when progression is set). Examples 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 'Create a complete genre track from zero to render-ready in one call' and lists the step-by-step pipeline. The verb 'create' combined with 'full_genre_pipeline' distinguishes it from sibling tools like create_genre_track or individual 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states that one call replaces 5-10 individual tool calls, and provides examples covering various use cases (basic, custom, with harmonic layers). However, it does not explicitly mention when to avoid using it (e.g., for fine-grained control), which would enhance guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 clearly states that glissando creates a continuous-sounding slide through intermediate pitches, works in chromatic/diatonic/pentatonic modes, and mentions the return value: 'Returns notes created, pitch list, scale type.' This is sufficient for an agent to understand the tool's behavior and output.
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 the purpose stated upfront, followed by a parameter-by-parameter breakdown. It is slightly lengthy, but every sentence adds necessary information. It could be slightly more concise by grouping related parameters, but it remains clear and 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?
Given the tool's 10 parameters, lack of annotations, and presence of an output schema, the description covers all necessary aspects: parameter semantics, return values, and behavioral context (scale types, differentiation from similar tools). An agent can confidently select and invoke this tool correctly 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?
The input schema has 0% description coverage, but the tool's description provides detailed explanations for all 10 parameters, including defaults and allowed values (e.g., scale_type options, rate values, velocity_curve types). This adds substantial meaning beyond the schema, fully compensating for its 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 starts with a clear statement: 'Create a glissando — smooth scale run between two pitches.' It then distinguishes this tool from riser/bass_drop by explaining that glissando plays every intermediate note at a fixed rate, unlike pitch sweeps. This effectively differentiates it from sibling tools with similar names, achieving a specific verb+resource pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 glissando with riser/bass_drop, indicating when to use this tool instead (for a true scale run feel rather than a pitch sweep). It also explains the three scale types (chromatic, diatonic, pentatonic) to guide usage. However, it does not provide explicit when-not-to-use scenarios or alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains that it generates a single sustained note with type-specific properties and returns notes created and parameters. Does not disclose side effects or destructive nature, but covers main behavior 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?
Well-structured: summary line, detailed explanation, parameter list with inline descriptions, and examples. A bit lengthy but every part adds value; could be slightly more 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?
Given the 7 parameters, no schema descriptions, and no annotations, the description is highly complete. It covers purpose, all parameters with defaults and options, return value, and provides examples 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 description coverage is 0%, but description thoroughly explains all 7 parameters: impact_type with list of values and characteristics, unit_index, track_index, start_beat, pitch (with default and override), length_beats, velocity. Includes examples with default 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?
Clearly states it creates an impact—a single hit transition element. Distinguishes itself from siblings by specifying it's for drops and section changes, and describes the output as a sustained note with type-specific characteristics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit usage context: 'Essential for EDM transitions: the hit that lands after a riser/build-up.' Does not mention when not to use or provide direct alternatives, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 explains that talea and color cycles repeat independently, causing phasing, and that the full cycle length is the LCM of lengths. It also mentions return values (notes, lengths, duration). However, it does not mention potential side effects like overwriting existing notes or prerequisites (e.g., existence of a 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 well-structured, starting with a definition, then historical context, then parameter details, then return values. It is slightly long but every paragraph adds value. Could be trimmed slightly, but no word is wasted.
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 (7 parameters, 0 required) and the presence of an output schema, the description provides comprehensive context: conceptual explanation, parameter formats, behavioral phasing, and return summary. It fully equips 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds substantial meaning to all parameters beyond the input schema. For talea and color, it explains the comma-separated format and gives examples. Repeats, velocity, unit_index, track_index, and start_beat are all described with context. 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 creates an isorhythm, defines it as a repeating rhythm (talea) combined with a repeating pitch series (color), and distinguishes it from ostinato. The verb 'create' and specific resource 'isorhythm' are unambiguous. Historical context and contrast to ostinato further clarify its unique purpose 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 explains when to use an isorhythm (for medieval motets and 20th-century composers) and contrasts it with ostinato. However, it does not explicitly state when NOT to use it or list alternative tools for similar patterns. The guidance is clear but lacks explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool generates notes based on the given parameters, and it returns the total notes created and pitches used. It does not mention side effects like overwriting existing notes or authorization needs, but the behavior is adequately disclosed 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 lengthy but well-structured: a benefit statement followed by parameter explanations and pattern examples. Each sentence adds value, though it could be slightly more concise without losing 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?
Given the tool's complexity (8 parameters, no annotations, but an output schema exists), the description thoroughly covers all aspects: purpose, parameter details, pattern syntax, and return values. It is complete and leaves no major gaps for an agent to understand 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 0% description coverage, so the description compensates fully. Every parameter (scale, root, pattern, octave, velocity, start_beat, unit_index, track_index) is explained in natural language, including default values and detailed pattern syntax with examples. This adds significant 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 it creates a melody from a scale and rhythmic pattern, using a single call instead of 10-30 create_note calls, which distinguishes it from the sibling tool mcp_opendaw_create_note. The verb 'Create' and resource 'melody' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 advises using this tool instead of multiple create_note calls, providing a clear use case. However, it does not contrast with other melody-related sibling tools like create_melody_from_progression or create_counter_melody, so it lacks exclusions for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 adequately describes the behavior: taking notes from a region, creating repeats with decaying velocity and optional pitch shift, feedback modes, and dest_track options. Missing details on error handling or prerequisites, but overall sufficient.
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, parameter explanations, and examples. It is slightly verbose but every sentence adds value; 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?
For a complex creative tool with 9 parameters and no annotations or output schema provided, the description is highly complete. It explains all parameters, provides examples, and mentions return type. The agent has enough information 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?
Schema coverage is 0%, but the description thoroughly explains each parameter with purpose, default values, and possible values (e.g., feedback_mode options, pitch_shift range). It adds significant meaning beyond the schema's minimal 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 MIDI echo — repeat notes with decaying velocity and optional pitch shift.' It uses a specific verb ('create') and resource ('MIDI echo'), and distinguishes itself by describing it as a creative effect (not a simple copy), contrasting with siblings like copy 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 context for when to use the tool (creative effect like guitar delay, synth echo) and explains parameter effects with examples, but does not explicitly compare to alternatives among the many sibling tools, lacking when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears the full burden of behavioral disclosure. It explains that the tool auto-modulates between keys, that drum_genre skips pads and bass in harmonic sections, and that default values produce a specific structure. It does not explicitly mention whether the tool overwrites existing tracks or if it is destructive, but the overall behavioral traits are well-covered 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections for parameters, examples, and default behavior. It front-loads the primary purpose. While relatively long, every sentence adds value. Minor verbosity could be trimmed (e.g., repeating modulation examples), but overall it is efficient 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?
For a tool with 9 parameters (0 required) and an output schema, the description covers all relevant aspects: sections formatting, default values, modulation logic, drum genre behavior, pattern inheritance, and usage examples. The output schema exists, so return value details are unnecessary. The description is complete enough for an agent to use the tool correctly without confusion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 0%, so the description must compensate. It thoroughly explains the 'sections' parameter with a clear format and examples, details each pattern parameter (arp, bass, melody, counter_melody), and describes 'drum_genre' and 'bpm' with valid genre list and usage notes. The description adds significant meaning beyond the schema by providing default values, behavior context, and 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 explicitly states 'Build a multi-section song with key modulation between sections — one call.' It clearly indicates a specific verb (build), resource (multi-section song), and key feature (key modulation). The description distinguishes itself from sibling tools like 'create_harmonic_arrangement' by referencing pattern parameters and by offering a higher-level structure building capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 multi-section songs with auto-modulation, avoiding manual start_beat calculation). It provides context by mentioning that arp_pattern/bass_pattern etc. are 'same as create_harmonic_arrangement,' helping the agent understand the relation. However, it does not explicitly state when NOT to use this tool or describe limitations that would point to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains rhythmic grid, ghost stabs, chord cycling, and return values (notes, voicings, hits). No disclosure of destructiveness but 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is front-loaded with purpose and organized with parameter explanations. It is slightly verbose but every sentence adds value. Could be 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?
Given 9 parameters and output schema exists, description covers all parameters, usage examples, return values, and genres. It fully compensates for missing schema descriptions and provides complete 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%, so description provides all meaning. It explains each parameter: chords format (JSON array), rhythm pattern (x, -, .), defaults, and examples. This 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 the tool creates rhythmic stabs (short chord jabs) and specifies genres like house, disco, funk. It distinguishes from siblings by focusing on stab patterns, not arpeggios or basslines.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists perfect use cases (off-beat stabs, syncopated punches, etc.) but does not explicitly mention when not to use or compare to alternatives. This is clear context but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. It explains the output (notes, vibhag structure, tali/khali positions, bols) and the mapping of bols to MIDI pitches. However, it does not disclose potential side effects like overwriting existing notes or whether the tool is destructive, but given it's a creation tool, the transparency 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-organized with sections for context, tala examples, laya, bol mapping, and parameters. Every sentence provides value, though the educational content could be slightly trimmed without losing clarity. 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of Indian classical tala and the tool's 7 parameters, the description is highly complete. It explains the cyclic structure, specific tala patterns, tempo options, and bol-to-MIDI mapping. The output schema exists, so the description correctly focuses on input semantics and behavioral context without needing to detail 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, so the description must compensate. It provides a clear 'Args' section with detailed explanations for each parameter, including defaults, ranges, and examples. It also explains domain-specific concepts like tala names and laya types, adding significant meaning 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 creates an Indian classical tala, defining it as a cyclic rhythmic structure with vibhag sections and tali/khali markings. It distinguishes from Western meter and provides specific examples of talas, making the purpose unambiguous and differentiating it from sibling tools like create_polyrhythm or create_euclidean_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 extensive context on when to use this tool, including the structure of various talas, the concept of theka, and laya tempos. However, it does not explicitly state when not to use it or compare it to alternative tools, such as other rhythm creation tools, leaving some ambiguity for an AI agent deciding between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses auto-detection of track type and returns error for audio tracks, but lacks details on side effects, permission requirements, or idempotency. A 3 is appropriate for 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?
Well-structured with clear sections and bullet points. Every sentence adds value; no fluff. Efficiently communicates essential information in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 core behaviors, parameter meanings, and return fields. Output schema exists, so return details are less critical. Could mention edge cases like invalid track index or overlapping regions, but overall adequate for agent 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 description must explain all parameters. It does so comprehensively: unit_index with default value note, track_index, start_beat, duration_beats, name with auto-labeling, and hue with color range and auto setting. 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?
Clearly states the tool creates a region on any track (note or value), automatically detects track type, and distinguishes itself from place_audio_region for audio tracks. The description 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (note and value tracks) and when to use an alternative (place_audio_region for audio tracks). Provides clear guidance on auto-detection and error handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 details left/right hand patterns, octave settings, velocity base (left hand slightly quieter), and return values (notes, voicings, chord count). It doesn't mention side effects like prerequisite track existence, but covers most behavioral traits 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: summary, sibling differentiation, then parameter details. It is lengthy but every sentence adds value. Some parameter groupings could be tighter, but overall it's 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 complexity (13 parameters, no annotations, output schema exists), the description covers purpose, parameter details, and return values. It is complete enough for an agent to invoke correctly, explaining how each parameter affects the arrangement.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 thorough explanations for all 13 parameters, including examples (e.g., chords format, left_hand patterns, arpeggio types) and default values. This 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 clearly states 'Create a two-hand piano arrangement — left hand accompaniment + right hand melody.' It distinguishes itself from siblings like create_chord_progression and create_melody by explicitly noting that this tool combines both hands into one coherent 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 this tool versus alternatives by contrasting with create_chord_progression (block chords only) and create_melody (single line). It does not explicitly state when not to use it, but the differentiation is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description clearly states the behavior: reads source region, generates N variations, writes new regions to target track. It explains transformation formats and defaults. With no annotations, it carries the transparency burden well but omits error handling and prerequisites (e.g., source region 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?
The description is well-structured: a one-line summary, process overview, parameter list with examples, and output note. It uses clear line breaks and bullet points. Length is justified by complexity; 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?
Given the tool's complexity (8 parameters, multiple transformations) and presence of output schema, the description covers core usage, parameters, and return values. It lacks explicit error handling or prerequisite checks but is 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 description coverage is 0%, so the description is the sole source for parameter semantics. It thoroughly explains all 8 parameters: source_unit, source_track, source_region, variations (with format and examples), target_unit, target_track, start_beat, spacing_beats. Defaults and examples are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb+resource: 'Create thematic variations from an existing note region.' It details the process and lists specific transformations (transpose, invert, reverse, etc.), distinguishing it from siblings like create_motif_variations and create_arrangement_variation by focusing on note-level theme-and-variations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 creating thematic variations from a note region with classical compositional context. It provides examples and parameter details. However, it lacks explicit when-to-use or when-not-to-use guidance relative to sibling tools, such as create_motif_variations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. The description adds that the tool scans all tracks and audio units, deletes overlapping regions, and returns per-track details. This provides useful 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but well-structured with summary, explanation, parameter list, and examples. Slight redundancy (e.g., 'across all tracks' repeated) but not excessive.
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 deleting across tracks, the description covers the operation, parameters, return values (number deleted, per-track details, remaining counts), and provides examples. No output schema exists, so description compensates effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 description must compensate. It explains each parameter in plain language: from_beat (start), to_beat (exclusive end), unit_indices (comma-separated, default all). Examples 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 states exactly what the tool does: delete all regions overlapping a beat range across all tracks. It clearly distinguishes itself from the sibling tool 'delete_region' by emphasizing batch deletion across tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage scenarios ('clear bars 9-12', 'remove the intro') and notes it replaces multiple delete_region calls. It does not explicitly state when not to use, but the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate destructiveHint=true, and the description correctly states deletion. It adds value by explaining the restriction on anchor markers and their role in pinning audio mapping, as well as the return value (remaining marker 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 (7 lines) yet complete: a clear action statement, a restriction note, parameter definitions in a list format, and the return value. No redundant information; each sentence serves a 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 4 required parameters, destructive annotation, and lack of output schema, the description covers all necessary aspects: purpose, constraints, parameter meanings, and return value. It even references the sibling tool list_warp_markers for obtaining the marker index, ensuring the agent has sufficient 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 0% schema description coverage, the description compensates by providing concise explanations for all 4 parameters: unit_index (AU index), track_index (within AU), region_index, and marker_index (0-based, from list_warp_markers). This adds essential context beyond the schema's 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 'Delete a warp marker' from a time-stretched or pitch-stretched audio region, distinguishing it from sibling delete tools (e.g., delete_audio_region, delete_marker) and related warp marker tools (create, list, update).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 notes that anchor markers (first and last) cannot be deleted, providing a clear when-not-to-use condition. However, no alternatives are mentioned, missing a chance to guide users to other tools for those cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark readOnlyHint=true, and the description aligns: 'detect', 'finds', 'computes'—no destructive actions. Adds value beyond annotations by detailing the computation (spectral overlap, conflict bands, severity, recommendation). No side effects mentioned, consistent with read-only nature.
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?
Front-loaded with the core purpose, then expands with examples and output fields. Slightly lengthy but every sentence adds value. Could be more terse, but the structure is logical 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?
Given the tool has an output schema (true), the description appropriately summarizes return fields (overlap_score, conflict_bands, severity, recommendation) without duplicating the schema. Includes usage hint (export stems first) and an integrated example. 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 single parameter 'filenames' has 0% schema description coverage, but the description compensates excellently: explains acceptable formats (JSON array or comma-separated), provides concrete examples, and clarifies it expects stem filenames already in the exports directory. This fully resolves the parameter 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?
Clearly states the tool detects frequency masking between stems, providing concrete examples (bass/kick at 60-120Hz, guitars/vocals at 2-4kHz). Among many sibling analysis tools, this one is uniquely positioned for a specific mix problem. The verb 'detect' paired with 'frequency masking' is precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 advises exporting stems first via 'export_stems', demonstrated in the example. While it doesn't explicitly state when not to use it, the context (post-export, pairwise analysis) is clear. It distinguishes from generic analysis tools by focusing on masking conflicts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description explains all behavioral aspects: actions are mutually exclusive, criteria are ANDed together, -1 disables a filter, and the return values differ by action (list returns note details, delete/keep return deletion count). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections (intro, criteria, actions, examples). It is somewhat long but every part contributes essential information. Could be slightly tightened but remains 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 10 parameters and three actions, the description covers all aspects: parameter roles, wildcard semantics, action behaviors, return types, and realistic examples. The presence of an output schema further complements 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 must fully explain each parameter. It does: unit_index, track_index, region_index, all pitch/velocity/beat parameters with ranges and wildcard -1, and the action enum. Examples reinforce 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 it filters notes by criteria (pitch, velocity, time range) and supports three actions: list, delete, or keep. This distinguishes it from sibling tools like list_notes (no filter) or delete_note (single note deletion).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 multiple use cases with concrete examples and explains the wildcard behavior (-1). It does not explicitly mention when NOT to use (e.g., prefer delete_note for targeting a single known note), but the examples cover common scenarios effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns a 'complete effect state snapshot' including enabled/bypass, minimized, sidechain, and parameters. This adds context beyond the readOnlyHint annotation, but does not reveal any potential performance or rate-limiting implications.
Agents need to know what a tool does to the world before calling it. Descriptions 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 summarizing purpose and differentiation, plus logical parameter explanations. 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 presence of an output schema, the description accurately summarizes the return without detail. It also fully documents the parameters and provides sibling differentiation, making the tool self-contained for selection.
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 both parameters ('unit_index' and 'effect_index') with concise, meaningful definitions. Since the schema provides no descriptions (0% coverage), the description fully compensates by clarifying the index meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 state of an effect' and lists specific components (enabled, minimized, sidechain, all parameters). It also explicitly differentiates from the sibling tool 'list_effect_parameters' by stating it is more detailed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 guidance on when to use this tool over its sibling (when more detail is needed than list_effect_parameters). However, it does not mention when not to use it or provide alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true. The description adds value by detailing the return fields and indicating real-time nature. No contradictory or missing behavioral information for a read-only status 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 with a brief header and a structured list of return fields. Every sentence is useful, front-loaded, and 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 zero parameters and presence of output schema, the description fully enumerates all return fields with types and meanings. Complete for an agent to understand the output.
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?
No parameters, so no need for additional semantics. Baseline score of 4 applies as per instructions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Get real-time engine status' and lists specific fields (playing state, position, BPM, CPU load, recording state). This distinguishes it from other get tools like get_track_info or get_project_info, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While no explicit when/when-not guidance is given, the tool's purpose and name make it obvious it's for querying engine status. Among siblings, only this tool provides engine_status, so usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation (true) already signals safety. The description adds value by specifying the scope of data returned ('complete snapshot...all AUs, tracks, regions, effects, mixer state'), which goes 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?
The description is two sentences long, front-loading the key action and resource. The second sentence provides usage guidance. No extraneous 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 has an output schema, the description need not detail return structure. It adequately covers the tool's purpose and use case, leaving nothing essential unanswered.
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%, so the description does not need to explain param details. The baseline is 4 for zero-param tools, and the description correctly states the tool returns a complete snapshot without requiring inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 clearly defines the resource ('complete snapshot of the project') while listing major components (AUs, tracks, regions, effects, mixer state). This distinguishes it from sibling tools that retrieve partial state (e.g., get_track_info, 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 explicitly states when to use the tool: 'Useful for agents to understand the current state before making changes.' This provides context for its use. However, it does not explicitly list when not to use it or offer 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with the readOnlyHint annotation, confirming a read-only operation. It adds that the result is a list of channel strips with current values, providing 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?
Two concise sentences with no filler. The key action and result are front-loaded, followed by a brief use case. 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?
Given no parameters and an output schema that likely defines the return format, the description adequately covers what the tool does, its return content, and typical use case. It is complete for safe inspection.
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 the description does not need to add parameter details. The schema coverage is 100%, so baseline score 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 explicitly states it retrieves the full mixer state, listing specific attributes (volume, panning, mute, solo, type) and the return format (list of channel strips). This clearly distinguishes it from sibling tools like get_track_info or list_tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It suggests use for inspecting mix balance and routing, which implies the appropriate context. However, it does not explicitly state when not to use it or mention alternative tools for detailed track inspection, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide readOnlyHint=true, indicating the tool is read-only. The description adds value by specifying that the tool returns parameter names, current values, units, and ranges, which goes beyond the annotations' 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 concise with a clear single-sentence purpose followed by parameter explanations and return value summary. No superfluous text; each 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?
The description covers the essential information: purpose, parameter meanings, and return content. Given the tool's simplicity and the presence of an output schema, it is sufficiently complete. It does not discuss error conditions, but that is acceptable for a list 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 full semantic meaning for both parameters: unit_index described as 'Audio unit index' and effect_index as 'Effect position in the chain (0-based, from add_effect return)'. Since schema description coverage is 0%, the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all parameters of an effect on an audio unit. It specifies the action (list) and resource (parameters of an effect), and distinguishes from siblings like list_effects (which lists effects) by explicitly focusing on 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?
The description explains the parameters (unit_index and effect_index) with clear guidance on effect_index being zero-based and from add_effect return. While it does not explicitly state when to use this tool versus other effect parameter tools, the context is clear enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It explains the formula, modes, intensity effect, clamping, and return summary. However, it does not explicitly state whether the modification is destructive or reversible, though it implies in-place modification.
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 sections: purpose, explanation, modes, formula, parameters, use cases. It is front-loaded with purpose. Some redundancy (e.g., parameter listing twice) could be tightened, but overall it is clear 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 tool's complexity (8 parameters, output schema exists), the description is comprehensive. It covers the transformation logic, all parameters, mode details, use cases, and mentions the return type. The output schema handles return value details, so the description is 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 compensate. It thoroughly explains all 8 parameters, including mode options, intensity range, pitch_ref default, and clamp range. It also provides formula details and default values, adding significant meaning beyond the 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 maps velocity based on pitch, with specific modes for different effects. It distinguishes from sibling velocity tools by emphasizing the pitch-velocity relationship, which is unique among the listed 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases such as making flat MIDI velocities more natural, drum kits, lead synth, and vocal range emphasis. It implies when to use different modes but does not directly contrast with alternative tools 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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with no annotations, the description fully discloses behavior: it copies notes from B to A while preserving absolute positions, extends region A's duration, deletes region B, and handles gaps with silence. 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?
The description is well-organized with a concise main statement followed by behavior details, use cases, parameter explanations, return info, and an example. 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?
The description covers all key aspects: behavior, parameters, use cases, and return value. It could mention error conditions (e.g., regions on different tracks) but is otherwise 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 coverage is 0%, but the description adds detailed explanations for each parameter (unit_index, track_index, region_index_a, region_index_b) in plain language, making their roles 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 merges two note regions on the same track. However, it does not explicitly differentiate from sibling tools like 'consolidate_region' or 'flatten_note_regions', which might have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 relevant use cases (joining verse+chorus, consolidating split regions, etc.) and notes that regions need not be adjacent. However, it lacks explicit guidance on when not to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains that effects between from and to shift accordingly and mentions indices are 0-based. However, it does not describe return value, error handling for out-of-range indices, or whether the operation is undoable.
Agents need to know what a tool does to the world before calling it. Descriptions 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 with five lines: purpose, chain order note, three parameter descriptions, and a final note on shifting. No redundant information, front-loaded with 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 reorder operation with three parameters, the description covers core behavior and parameter meanings. However, it lacks details on output schema and edge case handling (e.g., out-of-bounds indices), which would improve 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?
Input schema has 0% description coverage, but the description provides concise definitions for all three parameters: unit_index is 'Audio unit index', from_index and to_index are 'Current/Target effect position (0-based).' This adds 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 the tool's purpose: 'Reorder an effect within an audio unit's effect chain.' It uses a specific verb and resource, and the chain order explanation distinguishes it from sibling tools like add_effect or remove_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 implies usage through the phrase 'Use this to move effects to the desired position.' It gives context on why chain order matters but does not explicitly state when not to use it or contrast with alternatives like duplicate_effect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 copy+delete behavior, parameter effects (e.g., velocity scale clamped 0-1, time_offset, transpose), auto-creation/appending of destination regions, and the return JSON structure. Missing information includes what happens if the source region is cleared or if destination track doesn't exist, but overall it is quite thorough.
Agents need to know what a tool does to the world before calling it. Descriptions 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 contextual paragraph, and a clean Args block. Every sentence provides essential information without redundancy. The format is front-loaded with the core concept, then detailed parameter documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 parameters, 5 required) and the presence of an output schema, the description covers the operation well. It explains the return shape and parameter interactions. It could briefly mention prerequisites (e.g., source region must exist) but is largely complete 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%, but the description's Args block explains every parameter in detail, including defaults, ranges (velocity_scale clamped 0-1), and behavior (delete_source: 'If True (default), delete notes from source after copy. If False, behaves like copy_notes_to_track'). 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move notes from a source region to another track — copy + delete' and explains the operation as copying notes then optionally deleting originals. It distinguishes from sibling tools like copy_notes_to_track by explicitly mentioning the delete_source flag, 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 specific use cases: 'splitting material across tracks, reorganising arrangements, or moving a section to a different instrument.' It contrasts with copy_notes_to_track when delete_source=False. However, it does not explicitly state when not to use this tool, such as if one wants to keep the source intact without copying. Still, the guidance is clear enough for most scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 transparently explains the quantizing behavior, modes (snap, floor, ceil, round_random), and parameter effects. It also describes the return format. It does not mention undo capability, but is otherwise thorough.
Agents need to know what a tool does to the world before calling it. Descriptions 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 one-sentence headline, a short paragraph with analogy and use cases, then a clean argument list, and a return description. 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7 parameters and 2 required, the description covers all parameters and return values. It does not explicitly mention prerequisites (e.g., need a note track with velocities), but that is implied. Overall, 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 has 0% description coverage, but the description fully documents each parameter with detailed explanations. For example, it defines levels values (2-128) with musical meanings, explains all four modes, and clarifies region_index = -1 means all regions. This adds significant semantic 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 the tool's purpose: 'Quantize note velocities to discrete stepped levels.' It uses specific verb ('Quantize') and resource ('note velocities'), and includes analogy to MPC 16-level mode, distinguishing it from siblings like scale_velocity or humanize_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 use cases: 'Great for creating uniform, robotic feel (techno, industrial) or restoring clean velocity tiers from humanized performance data.' While not explicitly stating when not to use, it implies appropriate contexts and the analogies help. Could be stronger with explicit exclusion of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It explains auto-detection of song length, scanning all regions, rendering from beat 0 to end plus configurable tail. Discloses return values (path, duration, metadata). Lacks details on empty project behavior, but overall 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?
Description is well-structured: what it does, how it works, pipeline usage, parameters, and examples. Front-loaded with purpose, no superfluous sentences. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 3 optional parameters and existence of output schema (inferred from context), description covers core functionality, usage, and return information. Does not mention error conditions or prerequisites like having a project loaded, but is still fairly complete for a render 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 description provides clear explanations for all three parameters: filename (without .wav), sample rate, tail_beats (purpose and default). 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?
Description clearly states it renders the entire project, auto-detects song length by scanning all regions. Differentiates from siblings like render_range by being the full render tool. Verb 'render' + resource 'full song' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 says it closes the pipeline gap after arrangement tools like create_song_with_variations, with examples showing different tail_beats for different genres. Does not explicitly mention alternatives for partial renders, but context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses that it uses 'OfflineEngineRenderer with custom range' and returns 'the path to the exported WAV and audio metadata'. This provides useful behavioral context, though it could mention if overwriting existing files is possible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: 6 lines covering purpose, parameters, and return value. It is front-loaded with the main use case and parameter list, with 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (4 parameters, required 3, no enums) and the existence of an output schema, the description is complete. It explains the purpose, parameters, return value, and speed advantage. 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?
Schema description coverage is 0%, but the description lists all parameters with brief explanations (e.g., start_beat: 'Start position in beats (0 = project start)', filename: 'without .wav extension'). This adds meaning beyond the schema, which only has titles, and compensates well 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 verb 'render', the resource 'portion of the project', and the purpose 'quick A/B comparison'. It differentiates from sibling tools like mcp_opendaw_render_full by specifying that it renders only a part, not the whole project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 'Faster than full export for checking specific sections during mixing', which provides clear usage context. It implies that full export is the alternative, although it doesn't directly name the sibling tool. The guidance is sufficient 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries full burden. It clearly states the action (screenshot) and output (base64 PNG), implying a read-only, non-destructive operation. It lacks details like potential performance impact or that it captures the current visible state, but is sufficient for understanding the tool's 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 consists of two short, essential sentences. No extraneous words. Information is front-loaded: action, resource, output, use case. Highly 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?
Given the tool has no parameters, an output schema is provided, and the description covers purpose, output format, and use case. It is complete and sufficient for an agent to select and invoke the tool without additional clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so per guidelines baseline is 4. The description does not need to add parameter information as schema coverage is 100% and no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Take a screenshot', the specific resource 'openDAW UI', and the output format 'base64-encoded PNG image'. This is distinct from all sibling tools, which are about editing, creating, or analyzing audio/DAW 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 context 'useful for visual debugging and verifying project state', which helps the agent understand when to use it. However, it does not explicitly state when not to use it or list alternatives, though no direct alternatives exist among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully handles behavioral transparency. It explicitly states that the tool accounts for tempo automation and returns beats, PPQN position, or error. This is sufficient for a simple conversion tool, though additional details like precision or edge cases could be added.
Agents need to know what a tool does to the world before calling it. Descriptions 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, front-loaded sentences: a clear purpose, a use-case, and parameter/return info. 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?
For a tool with one parameter and a simple behavior, the description covers input, behavior (tempo map usage), and output (beats, PPQN, error). An output schema exists (though not shown), so the description doesn't need to detail return structure. Complete for agent 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?
The single parameter 'seconds' is described as 'Time in seconds (float)', adding meaning beyond the schema (which has 0% coverage). It specifies type and unit. Could be improved by noting positive values or default behavior, but it provides solid 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?
The description clearly states the verb ('Convert') and resource ('seconds to beats'), and distinguishes itself from siblings like ppqn_to_seconds by specifying it uses the project's tempo map and accounts for tempo automation, making its 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 explains when to use this tool: 'Useful for aligning audio regions to the musical grid when tempo changes mid-song.' It implies the context (tempo automation) but does not explicitly state when not to use it or provide direct alternatives, though 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It specifies the return (old and new values) and parameter range (1.0 to 64.0). It could mention if it affects playback or is safe, but it 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?
Two concise sentences plus a brief parameter explanation. No redundant information. Front-loaded with purpose. 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 one-parameter setter, the description is complete: states action, parameter semantics, and return values. Output schema exists to detail return structure. No 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 has 0% coverage, but the description adds meaning: units (quarter notes), range (1.0 to 64.0), and effect (smaller = more zoomed in). This compensates well for the lack of schema 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 it sets the piano roll time range (horizontal view width in quarter notes). The tool name and description are specific and distinct from sibling tools like set_piano_keyboard or set_piano_note_labels.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use (to change horizontal zoom) but does not explicitly state when not to use or provide alternatives. However, the tool's purpose is self-evident given the sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 reveals performance (GPU, time estimate), resampling behavior, and return value format. It does not mention destructiveness or auth requirements, but the mutation aspect (creating files) 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 clear hierarchy: purpose, hardware notes, parameter list, return value, and workflow examples. It is moderately long but 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?
Given 4 parameters, no schema descriptions, and an output schema, the description covers all parameters, return values, and provides workflow examples. It is comprehensive 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%, yet the description explains each parameter thoroughly: input_path (format), mode (all options with descriptions), output_dir (default format), and import_to_daw (behavior and return value impact).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Split' and resource 'audio file into stems', with specific mention of SOTA models. It distinguishes itself from siblings like 'separate_stems' by detailing the model options and their stem counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 guidance on when to use each mode (e.g., 'ensemble: Max quality, 4 passes', 'bs6: 6-stem, fast, low bleeding') and explains the import_to_daw workflow. However, it does not explicitly compare with the similar sibling 'mcp_opendaw_separate_stems' 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that switching phases changes which tools are registered and mentions that meta-tools are always available. It does not detail side effects or error conditions, but the core behavior is well 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 and well-structured. It starts with the main purpose, provides context, lists phases in bullet points, and includes an example. Every sentence is informative and adds 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?
The tool is simple (one parameter), and the description covers its purpose, usage, and allowed values. It mentions that meta-tools are always available. It does not explicitly describe the output or whether the phase change is immediate, but it is sufficiently complete 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 defines 'phase' as a string with no enum or description. The description compensates fully by listing the allowed values (inspect, compose, mix, render) and describing what each phase makes available. This adds significant 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 purpose: 'Switch the active tool phase for phase-based tool loading.' It explains the concept of phases and how they affect tool registration. This distinguishes it clearly from siblings that create or modify 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 explains when to use this tool (when in phase-based mode to switch phases) and lists the available phases with their purposes. It does not explicitly state when not to use it, but the context is clear. It effectively guides the agent on when to invoke this tool vs. the many content-focused siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the pipeline (WAV parsing, pitch detection, note creation) and lists return values (notes created, note count, bpm, duration, clarity). No side effects are mentioned but none expected.
Agents need to know what a tool does to the world before 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 front-loaded purpose, pipeline, use cases, parameter list, and examples. Every sentence adds 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 complexity and presence of an output schema, the description covers input format, monophonic requirement, parameter details, use cases, and examples. It lacks information on error handling or file size limits but is otherwise 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%, so the description must compensate. It provides detailed parameter explanations for filename, bpm (with auto-detect), unit_index, and track_index, adding significant 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 verb 'transcribe' and the resource 'monophonic melody from an audio file into MIDI notes on a DAW track'. It distinguishes itself from siblings like transcribe_audio and transcribe_drums by specifying monophonic 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?
Provides explicit use cases and examples for when to use the tool, but does not explicitly state when not to use it or mention alternatives. The monophonic limitation implies exclusion of polyphonic content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details that it runs four analysis modules and returns a report with prioritized suggestions and a master check. Annotations already declare readOnlyHint=true, confirming no side effects. The description adds value by specifying what the analysis covers and the output structure.
Agents need to know what a tool does to the world before calling it. Descriptions 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 clear bullet points listing the four modules and the platform-specific LUFS targets. It is informative without being verbose, and 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?
Given that an output schema exists (though not fully shown), the description covers the tool's purpose, input requirements, high-level output (combined analysis, suggestions, master check), and platform targets. It provides sufficient context for an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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' has 0% schema description coverage, but the description fully clarifies: 'Name of the WAV file in the exports directory (without path), or absolute path to any WAV file.' This adds essential 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 that this tool performs a 'complete mix diagnosis' by combining four analysis modules into one call. It explicitly lists the modules and distinguishes itself from the individual analyze_* tools, making its purpose immediately 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 advises that the agent 'can call this single tool instead of 4 separate calls', which implies it should be used for comprehensive mix analysis. However, it does not explicitly state when not to use it (e.g., if only one analysis is needed), so it lacks complete usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that it adds effects per track with genre-specific recipes, sidechain behavior, and returns effects added per track. It could mention reversibility or idempotency, but it is still transparent enough for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a short header, followed by workflow context, bullet points detailing genre recipes, parameter explanations, and an example. Every sentence adds value and 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.
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, output schema exists), the description is complete: it explains the workflow, genre-specific behavior, parameter constraints, and what is returned. The presence of an output schema reduces the need for return value detail, and the description covers the rest 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 compensate fully. It does: it lists valid genre values, explains unit_index, num_tracks (must match arrangement), and sidechain (with guidance on when to set True/False). This adds critical 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 applies genre-specific mixing effects to tracks after creating an arrangement. It uses specific verbs and resources (apply, genre mix) and distinguishes itself from sibling tools like apply_full_mix or apply_mix_preset by being part of a pipeline (create arrangement → apply genre mix → ready to render).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 'Closes the loop: create arrangement → apply genre mix → ready to render' and mentions it replaces 10-20 manual calls, giving clear context for when to use it. However, it does not explicitly state when not to use it or compare with alternatives like apply_full_mix, so it is 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.
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 that a new track is created, optionally in a new audio unit, and details parameter effects (transpose, velocity scale, time offset). It does not mention potential limits or undo behavior, but it is largely transparent about the core actions.
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, clarification, comparison, use cases, and parameter list. The use case list is slightly long but adds value. The content is informative without being overly verbose, though could be slightly 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?
An output schema exists, so return values are not needed. The description covers tool behavior, when to use, and parameters. It does not explicitly mention error conditions or prerequisites (e.g., track must exist), but the required parameters imply these. Overall, it is fairly complete for a cloning 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 0% description coverage (no parameter descriptions). The tool description compensates with an 'Args' section that explains each parameter, including ranges, defaults, and semantics (e.g., transpose -24 to +24, velocity_scale 0.1-2.0). This adds significant 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 'Clone a track — full duplication of notes, regions, and structure.' It further explains that it creates a new track from scratch with all notes, and explicitly distinguishes from copy_notes_to_track. The use cases (doubling, octave layering, etc.) reinforce 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description directly contrasts clone_track with copy_notes_to_track, stating when to use each. It also lists essential scenarios (doubling, octave layering, parallel harmony, etc.) providing clear guidance on 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.
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 transparency. It states the tool copies notes from a source region to a destination track's first region, returns a count, and supports optional transformations. It does not mention whether the source is modified, permissions needed, or error handling, 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 well-structured with a summary, bullet use cases, parameter definitions, return value, and examples. Every section adds value, and the most important information (purpose) is front-loaded. Despite length, it is efficient and not verbose.
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 (8 parameters, 3 required), the description covers all parameters, explains the return value, and provides multiple examples. It addresses potential use cases and parameter options, 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?
Despite the input schema having 0% description coverage, the tool's description provides a line for each parameter (e.g., 'source_unit_index: Source AU index'), adding meaningful explanation beyond the schema's type and defaults. 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 clearly states 'Copy notes from one track/region to another track', using a specific verb and resource. It further distinguishes the tool by mentioning 'MIDI layering and doubling' and provides concrete use cases (e.g., layer drums, create harmony), differentiating it from sibling tools that copy regions or entire tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists use cases (layer drums, harmony, call-and-response, doubles) and provides examples, giving clear context for when to use the tool. However, it does not explicitly state when NOT to use it or mention alternatives, though the use cases imply appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool generates a complete drum solo with specific structural elements and returns notes and solo characteristics. However, it does not explicitly state whether it modifies existing data or creates new content, and does not mention any potential side effects. This is good but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear opening sentence, bullet-pointed genre details, parameter list, and examples. Each section adds value 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?
Given the complexity (7 parameters, no annotations, output schema exists), the description covers the core functionality, parameter semantics, and return description well. Minor omission: the standard parameters unit_index and track_index are not explained, which could affect completeness for an agent unfamiliar with the system.
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 adds significant value by documenting parameters: solo_type (with genre-specific details), bars (range 2-16, default 4), velocity (0-1, default 0.9, with note on loudness), and seed (PRNG). It also provides examples. However, parameters start_beat, unit_index, and track_index are not described in the text, which is a minor 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 purpose: 'Create a genre-specific drum solo with rudimental vocabulary.' It distinguishes itself from the sibling 'create_drum_fill' by specifying that it creates a full multi-bar solo with phrasing, build-ups, climax, and genre-specific patterns. The purpose 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly differentiates this tool from 'create_drum_fill' (short transition) and lists five distinct genres (rock, jazz, funk, latin, marching) with detailed characteristics. It provides clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that it inserts new low-velocity notes at off-beat positions where no notes exist, and works on the first note track if track_index=-1. It mentions returns number of ghost notes added and positions. It could clarify that it does not modify existing notes, but overall good 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 with a clear opening statement, detailed explanation, parameter list, return value, and example. 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 tool has 6 parameters and no annotations, the description covers all necessary aspects: purpose, mechanism, parameter details, return value, and usage context. It is complete enough for an AI 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?
With 0% schema coverage, the description adds excellent parameter explanations: density (probability at each 16th position), velocity (0-1 with typical ranges), seed (reproducibility), plus index defaults. Example usage further clarifies. This fully compensates for the lack of 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 the tool adds ghost notes to existing drum/MIDI patterns, explains what ghost notes are, and specifies it works on the first note track. It distinguishes from siblings like create_note or create_drum_pattern by focusing on adding subtle, low-velocity 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?
The description provides usage context by mentioning genres where ghost notes are essential (funk, R&B, neo-soul, hip-hop) and explains they fill spaces between main hits. However, it does not explicitly exclude 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the melody generation algorithm (chord/tonal pattern on strong beats, passing tones on weak) and explains each pattern's behavior. However, it doesn't disclose side effects like track creation/modification or return value format, missing some external 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 well-structured: purpose, context, algorithm, parameter details, and examples. Every sentence adds value with no redundancy or fluff, achieving clarity and efficiency.
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 8 parameters and no annotation, the description covers purpose, usage timing, algorithm, parameter semantics, and provides examples. It is self-contained and complete for an agent to understand 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 fully compensates by explaining every parameter's meaning, default values, and typical ranges (e.g., octave=5 for lead, pattern behaviors). Examples further clarify usage, adding high 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 lead melody from a chord progression string, and explicitly distinguishes it from sibling tools by naming the harmonic quartet (create_chord_pads, create_arpeggiated_progression, create_bass_from_progression, THIS).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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: as part of the harmonic quartet with shared input format. It provides context but doesn't explicitly state when not to use it or name alternative tools for melody creation (e.g., create_melody), though the quartet framing implies a specific purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers behavior: it creates tempo modulation events, returns old/new BPM, ratio, equivalence, and events. It includes the formula and note values. However, it does not disclose potential side effects, permissions needed, or whether it modifies existing tempo events. Still, it provides substantial 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: starts with purpose, then formula, note values, ratio alternative, examples, and parameter list. It is front-loaded and every sentence provides useful information without repetition. It is detailed yet efficiently 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 6 parameters, 0% schema coverage, and an output schema, the description is exceptionally complete. It covers what the tool does, how to use it, all parameters with defaults, examples, and return values. It also contextualizes the tool within music theory and contrasts with simple tempo changes. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 all 6 parameters: position_beats, old_note, new_note, old_bpm, ratio, add_time_signature, including defaults, meanings, and examples. It also lists supported note values and describes the ratio option. This adds immense 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 creates a metric modulation, a tempo change preserving note-value equivalence. It provides the formula, supported note values, and examples, distinguishing it from sibling tools like add_tempo_change or set_bpm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description contrasts metric modulation with simple tempo changes, implying when to use it. It explains the precise relationship and gives examples, but does not explicitly list when not to use or mention alternatives. The context is clear 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description fully shoulders behavioral disclosure. It explains the event format, return data (events created, mute schedule, track index), and notes that the automation track 'plays back predictably every time,' implying idempotent behavior. 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?
The description is compact yet comprehensive: purpose, context, parameter descriptions, return summary, and two practical examples. Each sentence serves a distinct purpose 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 an output schema, the description still explains return values, which is helpful. It covers all essential aspects: what the tool does, when to use it, how to configure parameters (with examples), and what to expect back. No 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?
With 0% schema description coverage, the description provides essential detail: unit_index as 'AU index' and events as a JSON array of [beat, muted] pairs with a clear example. This surpasses the schema's minimal information, 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 opens with a clear verb+resource statement: 'Create timed mute/unmute automation events on an audio unit.' It immediately distinguishes itself from the sibling tool set_track_mute by framing this as a batch automation track approach, providing a specific scope and use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 situates usage in section dynamics ('mute drums during breakdowns, unmute for drops') and contrasts with multiple set_track_mute calls. It gives concrete when-to-use guidance but doesn't explicitly state when not to use it or list other alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool creates automation events on the AU's panning parameter, defaults to linear curve, and clarifies psychoacoustic reasoning. Mentions shape options and steps. Lacks details on undoability or side effects, but sufficient for typical use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Highly concise and well-structured: first line defines purpose, then usage context, parameter explanations, and examples. Every sentence adds value, with no redundancy. Front-loaded with key 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?
Given the tool's moderate complexity (7 parameters), no annotations, and presence of output schema, the description covers all essential aspects: purpose, parameter semantics, return values (events created, pan range, preview), and examples. It 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?
Despite 0% schema description coverage, the description thoroughly explains each parameter: unit_index, start_beat, duration_beats, start_pan, end_pan, curve, steps, including ranges, defaults, and examples. 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?
Description clearly states the verb 'Create' and the resource 'panning automation sweep', explains the effect of moving signal over time. It includes usage contexts (intros, guitar solos, EDM builds) and examples, distinguishing it from sibling tools 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?
Provides clear usage context: 'Classic stereo movement technique for intros, guitar solos, EDM builds, and section transitions.' However, it does not explicitly mention when not to use this tool or name alternatives, though the context implies its appropriateness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on full transparency duty. It describes the generated output (notes_created, chords, voicings, etc.) and explains the genre-appropriate nature of the progression. However, it does not mention potential side effects (e.g., overwriting existing notes) or dependencies beyond detect_key, leaving some transparency 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 with a clear opening, bullet-style parameter explanations, and a pipeline example. It is front-loaded with the core purpose and remains informative 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 tool with 7 parameters and no annotations, the description provides comprehensive context: usage flow (detect_key → this tool → create_harmonic_arrangement), all parameter details, and return fields. It integrates well with sibling tools and covers the expected pipeline.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 in detail, including key, mode, style with examples, and positional parameters (unit_index, track_index, etc.). Since schema description coverage is 0%, the description fully compensates and adds meaning beyond the 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: auto-generate a diatonic chord progression from a detected key. It uses specific verbs ('auto-generate') and distinguishes from manual methods ('no manual chord typing'), effectively differentiating from sibling tools like create_chord_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 after detect_key and eliminates manual chord typing. It implies when to use this tool over manual alternatives, but does not explicitly list conditions when not to use it or mention other alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains stochastic generation, random walk mechanics, constraints (max_step, direction_bias), and output (notes, walk statistics, seed). However, it does not explicitly state whether the tool modifies existing notes or appends, nor does it mention potential side effects on 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with opening summary, algorithm explanation, sibling comparison, and parameter list. Somewhat verbose with artistic references (Brian Eno, Xenakis) but adds context. Front-loaded with key concept.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence 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 all 16 parameters, explains output schema (notes, walk statistics, seed). Complex tool with many parameters, and description provides sufficient detail. Minor gap: does not specify if notes are appended or replaced, and 'AU index' is not 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 has 0% description coverage (no parameter descriptions), but the description details every parameter with default values, ranges, and behavioral explanations (e.g., max_step: '1 = only adjacent scale tones (very smooth, stepwise)'). 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 explicitly states 'Create a melody using a random walk through a scale — stochastic generation.' It clearly differentiates from sibling tool generate_melody by explaining the algorithm and resulting characteristics (stepwise motion, each note depends on previous).
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 contrast with generate_melody: 'Unlike generate_melody (contour-guided weighted random), random walk produces stepwise motion...creating melodic continuity that contour guidance doesn't guarantee.' Also gives example applications (Brian Eno, Xenakis, ambient, IDM) to indicate appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the generated output (sequence of scale notes across octaves) and mentions the return value (total notes created, scale info). No annotations exist, so the description carries the burden; it provides reasonable behavioral insight without covering every edge case.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise yet informative: opening verb phrase, a short description, parameter list, and an example. No wasted words, well-organized with line breaks for 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 complexity (10 parameters, output schema exists), the description covers purpose, usage, parameters, and return value. It is self-contained and provides enough information for an agent to correctly 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?
All 10 parameters are explained with brief descriptions (e.g., scale type includes 14 types from music_theory, step_duration examples). Schema coverage is 0%, so the description fully compensates by adding meaning beyond the schema 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?
Clearly states the tool creates ascending or descending scale sequences for fills and transitions. Distinguishes from sibling 'create_' tools by specifying it generates a scale run rather than other 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?
Explicitly lists use cases (drum fills, melodic transitions, lead build-ups, bass walks), providing context for when to use. Does not specify when not to use or offer alternatives, but the listed uses are specific enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes output (returns notes created, pattern, rate, total length) and parameters that affect behavior. Does not explicitly state whether existing notes are overwritten or appended, but likely adds new notes. Could mention if it modifies existing data.
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?
Description is well-structured with an introductory sentence, sibling contrast, usage list, and clear parameter explanations. It is front-loaded with the main idea. Some parameter explanations could be slightly more compact, but overall 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 tool's complexity (13 parameters, no schema descriptions, no annotations), the description covers purpose, differentiation, parameter details, and return values. It does not explicitly mention prerequisites or error conditions, but for a creation tool with many defaults and auto-find capabilities, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates thoroughly by explaining each parameter's meaning, valid values, defaults, and musical effect. For example, 'rate' values are listed with beat durations, 'pattern' types are described, 'accent_pattern' and 'velocity_ramp' are explained. This provides full 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?
Clearly states 'Create a stutter edit — rapid rhythmic repetitions with evolving rate and dynamics'. Distinguishes from siblings like create_chop and create_trill by highlighting unique evolving characteristic. Provides specific verb+resource and context.
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 create_chop and create_trill, and lists essential use cases (build-up transitions, glitch fills, vocal-chop patterns, energy ramps). Gives clear context when and why to use 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.
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 mechanism (linear interpolation, multiple ValueEventBox events), return value (events created, config, BPM preview), and defaults (steps=16). It lacks details on side effects or permissions but is sufficiently transparent 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: purpose, mechanism, parameter list, return info, examples. Each sentence adds value without redundancy. It's comprehensive yet 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?
Given the tool's complexity (6 parameters, 4 required, output schema exists), the description covers purpose, all parameters with details, return value, and examples. It provides enough information for an AI 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.
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 6 parameters: start_beat, end_beat, start_bpm, end_bpm, curve (with options and default), steps (with effect of fewer steps). Three examples demonstrate usage. This fully compensates for the lack of parameter descriptions 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 'Create a smooth tempo ramp (ritardando or accelerando) across a beat range.' It specifies the verb (create), resource (tempo ramp), and musical context. It distinguishes from sibling tool add_tempo_change by noting it creates multiple events for a smooth curve.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps 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 use: 'essential for expressive transitions, endings, and dramatic section changes.' It compares to add_tempo_change (single event vs multiple). While it doesn't explicitly state when not to use, the guidance is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 creates automation events on the AU volume parameter, ramps between dB levels, uses an exponential curve by default, and returns events created, fade config, and dB range. It does not mention side effects like overwriting existing automation, but the core behavioral traits are 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 concise and well-structured: a clear opening sentence, a brief usage context, a parameter list with defaults, a note on return value, and two concrete examples. Every sentence adds value, 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.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and the presence of an output schema (indicated but not shown), the description is remarkably complete. It explains the tool's purpose, all parameters with defaults, the curve types, the return structure, and provides examples. No obvious 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?
Schema description coverage is 0%, but the description compensates fully by listing all 8 parameters with explanations, defaults, and examples (e.g., unit_index, direction, start_beat, duration_beats, start_volume_db, end_volume_db, curve, steps). This provides complete semantic 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 purpose: 'Create a volume fade automation on an audio unit — fade in or fade out.' It uses a specific verb ('create') and resource ('volume fade automation'), and the context ('common mix technique') helps distinguish it from other automation tools. The tool name itself is also specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes usage context: 'The most common mix technique for intros, outros, breakdowns, and section transitions.' This guides when to use it, but it does not explicitly state when not to use it or compare it with alternatives like add_automation or create_automation_event. Given the clear context, it is still helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 tool modifies audio regions by adding markers, mentions anchors, and states the return value. It could add more about reversibility or permissions, but the core behavior 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 concise, front-loaded with the main purpose, and uses bullet points for parameter explanations. Every sentence adds 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?
Given the presence of an output schema (mentioned in context signals), the description adequately explains the concept of warp markers and the tool's behavior. It covers the purpose, parameters, and return value, making it complete for a create 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 5 required parameters with no descriptions. The description lists each parameter with a brief explanation (e.g., 'unit_index: AU index.'), providing meaning beyond the schema titles and adding value for all 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 'Add a warp marker to a time-stretched or pitch-stretched audio region' and explains the concept of warp markers and anchors, distinguishing it from sibling tools like delete, update, 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 provides clear context for when to use this tool (for time-stretched or pitch-stretched regions) and explains the role of warp markers, but does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description details key behaviors: shift mode extends region, negative offset clamped at 0, circular mode wraps and preserves region length. Return stats are mentioned. No contradictions; adequately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for purpose, modes, parameters, and examples. Every sentence adds value; no fluff. Front-loaded with the core action and musical intent.
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 essential aspects: purpose, two modes with behavioral differences, parameter details, and practical examples. With output schema existing, no need to detail return values separately. 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?
Schema has 0% description coverage, but the description compensates fully by explaining each parameter (unit_index, track_index, region_index, offset, mode) with valid ranges, defaults, and common values. 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's purpose: 'Displace all notes in a region by a fixed rhythmic offset.' It elaborates on modes (shift/circular) and gives concrete musical examples (laid-back, pushed), distinguishing it from sibling tools like apply_swing or quantize_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?
Provides explicit context for when to use each mode and offset value, with examples like 'laid-back' and 'pushed.' Implicitly guides when not to use (reset with offset=0), but does not explicitly name alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses supported formats (WAV/MP3/FLAC/OGG), streaming download with timeout, default save location (/tmp), and return values (path, size, suggestion). No annotations provided, so description carries full burden. Lacks details on error handling or overwrite behavior, but 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with sections for purpose, pipeline context, supported formats, parameter details, return value, and examples. Front-loaded with core function. Some redundancy (e.g., examples repeated), but overall 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, usage, parameters, return, and next steps. Assumes output schema exists for return value details (not shown). Missing explicit error handling or edge cases, but for a download tool, the description is sufficiently complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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; description fully compensates by explaining each parameter: url (direct URL from AI generator), filename (default derived from URL), output_dir (must exist, default /tmp). Examples demonstrate usage with custom filenames.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 verb ('download'), resource ('audio file from URL'), and context (bridges AI generators and DAW). Distinguishes from siblings by explaining its position in the pipeline: generate track → get URL → download → import audio. Examples reinforce purpose.
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 states when to use (after generating a track, before import_audio_to_tracks) and provides alternatives (manual curl/wget). Includes examples with specific use cases (Suno tracks) and next steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 the tool captures raw output before audio effects, sends, volume/pan processing. It also notes unit_index must be >0 and not the output AU. However, it does not disclose potential side effects (e.g., whether it replaces original audio) 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with three clear paragraphs: purpose, comparison, parameters. Some slight redundancy in describing 'no effects' but overall efficient. 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?
Covers purpose, comparison, parameter constraints, and use cases. Has output schema so return values are documented elsewhere. Lacks information on file location, persistence, or blocking behavior, but adequate for a straightforward export 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 meaningful parameter explanations: unit_index must be >0 and not output AU, filename without .wav extension, sample_rate default 48000. This adds critical 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 the tool exports a single audio unit as a DRY stem, contrasting it with export_single_stem which includes effects. It specifies the resource (audio unit), the action (export), and the concept of dry stem (no effects/channel strip).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool versus export_single_stem: 'Unlike export_single_stem (which routes through the channel strip with effects), this captures the raw instrument output...' Also lists use cases: freezing, flattening, re-amping.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by detailing the return content: instrument type, parameters with values, units, and constraints. It also lists compatible instruments, providing context not in 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 concise, front-loading the purpose and then covering parameter, return value, and compatible instruments in a single, well-structured paragraph 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 single parameter and existing output schema, the description is fully complete: it explains the parameter, specifies return content, and lists compatible instrument types.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 the unit_index parameter's meaning and domain (-1 for auto-detect). It also adds context about supported instrument 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 verb 'List' and the resource 'parameters of the instrument connected to an audio unit'. It distinguishes itself from sibling tools like list_effect_parameters and list_midi_effect_params by specifying 'instrument' parameters. The parameter unit_index is defined with auto-detect logic.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 unit_index parameter, including the sentinel value -1 for auto-detection, and lists compatible instruments. However, it does not explicitly state when not to use this tool or provide alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds value by specifying the returned data (MIDI note, enabled state, effects), which is 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?
Three concise sentences front-load the purpose and include all necessary information with zero 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?
Given the tool's simplicity, the presence of an output schema, and the description's additional detail on return content, completeness is achieved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds crucial meaning to the sole parameter unit_index, explaining that -1 auto-detects Playfield, which is not evident from the schema alone (schema coverage 0%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 drum pads (samples) on a Playfield drum machine, distinguishing it from generic sample-listing tools like mcp_opendaw_list_samples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 unit_index parameter with auto-detect hint. While no explicit when-not or alternatives are given, the purpose is narrowly scoped to Playfield drum pads, making usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details the automated process: gain compensation, EQ correction, optional stereo adjustment, output of a matched WAV file, and a return object with analysis. It labels stereo matching as 'experimental'. While it doesn't mention file permissions or side effects, it adequately discloses the main 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: a concise purpose sentence, step-by-step breakdown, parameter list, and example. Each section adds value without redundancy. The parameter list is clear and the example illustrates typical usage. No unnecessary 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 description covers the tool's purpose, operation steps, parameter details, and return structure (via example). Given that the tool has an output schema, the example return is a bonus. For a moderately complex matching tool, the description 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% (no parameter descriptions in schema). The description compensates by listing all 6 parameters with clear explanations: filename, reference, output_filename, and three boolean flags (match_lufs, match_spectrum, match_stereo) with defaults. An example call further clarifies usage. 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's function: automatically matching a mix to a reference track via spectral and loudness alignment. It explicitly references 'Phantom's match_to_reference' and explains the three-step process, making the purpose unmistakable and distinguishing it from sibling tools like 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool's workflow (LUFS, spectral, stereo matching) and provides an example. It implies usage for A/B matching but does not explicitly state when not to use it or suggest alternatives. The reference to a known plugin helps, but lacks direct exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries full burden. It discloses critical behavior: for audio regions with seconds timeBase, delta conversion via tempo map; for note regions, note positions shift by -delta. It also mentions return values (new position, duration, loopDuration) and error cases.
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 followed by details and bulleted parameters. It is slightly verbose in a couple of sentences, but overall 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 has simple parameters and an output schema exists, the description covers key behaviors and returns. It omits prerequisites (e.g., region existence) and side effects, but is largely complete for effective 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%, but the description defines each parameter clearly: unit_index, track_index, region_index, and delta_beats with context-specific meaning. This adds significant semantic value beyond the schema's basic 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 specific verbs ('Shift the content start') and clarifies what the tool does: it moves content inside a region without moving the region itself. It distinguishes from siblings like move_region_to_track or set_region_position by focusing on content shifting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 use case ('useful for realigning content within a region after tempo changes') and explains behavior differences for audio vs note regions. However, it does not explicitly state when not to use this tool or compare to alternatives like move_notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 details the substitution techniques and return values (reharmonized string + mapping + explanation). However, it lacks information on side effects, error handling, or prerequisites (e.g., valid chord format). It is transparent enough for most use 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 well-structured: a summary sentence, then parameter breakdowns, followed by multiple practical examples. Every sentence adds value, and the examples illustrate usage. It is comprehensive without being verbose.
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 substitution techniques, parameter interactions), the description is highly complete. It covers concept, each technique, parameter meanings, and provides three realistic examples. The return value is described. It meets the high bar for 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 fully compensates. It explains each parameter in detail: progression format with examples, all five techniques with musical explanations, intensity levels with percentages, and target_chord indexing. This adds significant 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 purpose: 'Reharmonize a chord progression — substitute chords with functionally equivalent alternatives for richer harmony.' The verb is distinct ('reharmonize'), the resource is specific ('chord progression'), and it differentiates from sibling tools like 'create_chord_progression' or 'modulate_progression' by focusing on substitution rather than creation or modulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 the tool ('to transform a progression without changing its fundamental direction') and provides context for reharmonization. However, it does not explicitly state when not to use it or compare it to alternatives like 'modulate_progression', leaving some ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 details all 7 steps performed, parameter effects, and return value overview. It does not mention potential side effects on project state or external dependencies (e.g., Suno API), but the level of detail is high and no contradictions 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 efficiently structured with a one-line summary, a numbered step list, parameter explanations, and an example. Each sentence serves a purpose, no redundancy, and the important information is front-loaded. 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.
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, pipeline nature), the description covers all necessary aspects: input requirements (audio file), optional parameters with defaults, step-by-step process, output summary, and a concrete usage example linking to sibling tools (download_audio, render_full). The output schema exists, so return values are adequately summarized.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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. Every parameter (filename, genre, style, stem_mode, master_lufs, add_harmony, add_counter_melody, bars) is explained with type, default, and functional role, adding semantic value beyond the schema's 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 clearly states the tool performs a 'Full Suno remix pipeline in one call' with a specific verb-resource pair, and distinguishes it from individual step tools by noting it 'replaces 8-10 individual tool calls.' The steps are enumerated, 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?
The description provides an explicit usage scenario with a complete example (chirp_generate → download_audio → remix_track → render_full), and mentions post-call action ('call render_full to export'). However, it lacks explicit when-not-to-use guidance or direct alternatives among the many sibling tools, though the pipeline nature implicitly covers this.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 that notes are copied, transforms (time, pitch, velocity) are applied cumulatively per repeat, and structure is preserved. However, it does not explicitly state whether the source region is modified or if the operation is reversible, which would increase 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 with a concise summary paragraph followed by a clear Args list. Every sentence adds distinct value without redundancy. No fluff exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no annotations, and an output schema (so return values not needed), the description covers all parameters with examples, defaults, and cumulative behaviors. It also compares to a sibling tool, making the context complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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. Every parameter is explained with default values, valid ranges (e.g., repeats 1-16), cumulative effects (transpose_semitones, velocity_decay), and behavioral details (direction affects sign). The Arg block 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 repeats notes N times with per-repeat transformations, includes the specific verb 'repeat', identifies the resource as 'notes in a region', and distinguishes from create_midi_echo by highlighting differences in decay versus uniform transform. Use cases like sequences and ostinato patterns further clarify 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 explicitly contrasts this tool with create_midi_echo, indicating when to use it (preserving note structure, uniform transforms) versus alternatives (decaying feedback). It implies usage for sequences and motivic development but does not provide explicit when-not-to-use scenarios or prerequisites beyond the required parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 discloses that it serializes all tracks, regions, effects, notes, settings to an ArrayBuffer and saves to exports directory. It also states the return values: file path, size, and box count. However, it does not specify overwrite behavior or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions 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 sentences: purpose, serialization details, companion tool reference, and parameter/returns note. It is concise and front-loaded, with no unnecessary 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 (saving entire project), the description covers: what is serialized (boxGraph), output format (.odaw), location (exports directory), parameter detail (no extension), return values (path, size, box count), and complementary restore tool. Even with an output schema present, the description provides sufficient 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 only parameter 'filename' is described as 'Name for the saved project (without extension).' This adds crucial meaning beyond the schema, which only provides a title and type string. Since schema coverage is 0%, the description fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save the current project state to a binary file.' It specifies the verb 'Save', the resource 'project state', and the format '.odaw file'. It also distinguishes itself from sibling tool 'load_project' by mentioning it as the complementary load 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 it serializes the entire boxGraph and saves as .odaw file, and explicitly suggests using load_project to restore later. This gives clear when-to-use context and a sibling tool reference, but does not mention when not to use or alternatives like export_mix or export_stems.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains key behavioral traits: how each articulation affects note lengths, edge cases (last note, chords), and the return value. Since no annotations are provided, the description carries the full burden. It could benefit from noting irreversibility or undo availability, but overall is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized: purpose statement, articulation explanations, parameter list, edge cases, and an example. Every sentence earns its place, and the structure is front-loaded and easy to scan. Length is justified by 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?
Given the complexity (6 parameters, 3 articulation modes, edge cases) and the existence of an output schema, the description is thorough. It covers all necessary aspects for an agent to use the tool correctly, including parameter semantics and behavioral caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 each of the 6 parameters, including defaults, unit indices, and the meaning of staccato_ratio and micro_gap. It adds significant value beyond the schema's bare properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set articulation for notes — legato, staccato, or tenuto.' It specifies a verb ('set'), resource ('articulation for notes'), and enumerates the exact types, making it distinct from siblings like mcp_opendaw_apply_articulation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 articulation (e.g., 'Use for smooth string lines...'), but does not explicitly differentiate from sibling tools or state when not to use this tool. It lacks alternatives, but the within-tool guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 explains the basic behavior: enabling/disabling the loop and the meaning of from_beat and to_beat. It does not mention side effects like immediate application to playback or any destructive actions, but for a simple set operation this is adequate. The transparency is good for a non-destructive parameter change.
Agents need to know what a tool does to the world before calling it. Descriptions 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 short paragraphs. The first paragraph states the purpose and basic behavior. The second lists the parameters with one-line explanations. No redundant words. Every sentence adds value, making it easy to scan 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?
The tool has 3 required parameters, all explained. The behavior is simple: set loop region with enable/disable. There is an output schema (not shown) which presumably documents the return value. Given the tool's simplicity, the description covers all necessary information for an agent to use it correctly. No missing aspects identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 3 parameters with only titles, and schema description coverage is 0%. The description fully compensates by explaining each parameter: 'from_beat: Loop start in beats.', 'to_beat: Loop end in beats.', 'enabled: Whether loop is active.' This adds the exact meaning needed 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 purpose: 'Set the playback loop region.' It explains that playback loops between from_beat and to_beat when enabled. This distinguishes it from sibling tools like set_region_* or transport controls. The verb 'Set' combined with the resource 'loop region' makes the action 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 guidance on when to use the tool: to define a loop region. It explicitly explains how to disable the loop by setting enabled=false, stating the behavior that the region is kept but inactive. While it doesn't explicitly list alternatives, the context of DAW tools implies the user would know when looping is needed. The simple use case is well-covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 values for leaving properties unchanged and notes that the tool 'Returns updated values, or error.' This provides good transparency about behavior, though it does not detail potential side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions 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 summary line, bullet lists for properties and indices, a clear skip instruction, and a return statement. Every sentence adds value, and it is front-loaded with the most important 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?
Given the tool's complexity (8 parameters, 0% schema coverage, no annotations), the description covers all necessary context: parameter meanings, ranges, skip behavior, and return value. It is complete 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.
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 all 8 parameters: the four advanced properties with ranges and defaults, the four index parameters, and the skip mechanism. This adds significant meaning beyond the minimal 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 'Set advanced note properties' and lists specific properties (chance, cent, playCount, playCurve), distinguishing it from basic set_note_properties and other sibling tools. The title and first line make 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 explains that these properties are beyond basic ones and provides instructions on skipping properties with -1 or -999. However, it does not explicitly contrast with sibling tools like set_note_cents or set_note_properties, which could guide the agent's choice more directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It details behavior: original trimmed, new region created, straddling notes kept. It does not mention undo or side effects, but the behavior is transparent enough for a split 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: purpose, behavior, use cases, parameter list, returns, example. Each section is concise and useful, no wasted 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?
Given the output schema exists, no need to explain return values. The description covers all necessary aspects: behavior, use cases, parameters, and example, making it fully complete for a split 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 description compensates fully. It explains all 4 parameters (unit_index, track_index, region_index, split_beat) with purpose and constraints (split_beat must be within region range), plus an example. Adds significant 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 action: split a note region into two at a given beat position. It explains the behavior (trim original, create new region, handle straddling notes) and distinguishes from sibling tools like merge or delete by the specific splitting action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases (e.g., divide long region, cut silence, create variations) and an example, guiding when to use. It lacks explicit when-not or alternative tools, but the context and use cases sufficiently indicate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully carries the burden. It details exactly what each mode does to notes (e.g., 'move every other note up by spread_octaves octaves') and lists return values (original pitches, new pitches, mode used, chord size). 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: summary, mode explanations, parameters, examples. It is somewhat lengthy but every section adds value. 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?
For a tool with 4 modes and chord transformation complexity, the description covers purpose, mode mechanics, parameter roles, return values, and an example. With output schema present, it is sufficiently complete for an agent to understand 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 coverage is 0%, but the description explains mode (4 options with details), chord_position (beat position), and spread_octaves (range and default). It does not explain unit_index, track_index, or region_index, but these are common DAW identifiers likely understood from 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 tool's purpose: 'Spread or compact a chord voicing — open vs close harmony.' It specifies the action (transform spacing) and resource (chord tones at a beat position), and is distinct from sibling tools like create_comping or invert_chord_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?
Each mode (open, close, drop2, drop3) is explained with its musical effect and typical use cases, e.g., 'Classic jazz piano voicing technique' for drop2. The example shows concrete usage. However, it doesn't explicitly contrast with alternative tools or state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the internal pipeline (frequency bands, onset detection, classification into kick/snare/hat, velocity estimation, beat conversion, note creation). It discloses that notes are created on the specified track via create_notes_batch. However, it doesn't mention potential failure modes or format limitations (e.g., only WAV).
Agents need to know what a tool does to the world before calling it. Descriptions 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: concise first sentence, numbered pipeline, use cases, parameter list, return values, and examples. No redundant information; every sentence adds value. 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 tool's complexity (multi-step pipeline, 5 parameters, return structure), the description is remarkably complete. It explains the process, parameter semantics, return values, and provides a realistic example. Output schema exists, but the description still lists return fields for 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 explains all five parameters: filename (WAV file or path), bpm (tempo, 0=auto-detect), sensitivity (threshold 1.0-2.0), unit_index (AU with note tracks), track_index (target track). It also includes default values and an example, fully compensating 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 clearly states the tool's purpose: 'Transcribe drum onsets from an audio file into MIDI notes on a DAW track.' It specifies it's for drum/percussive content, contrasting with sibling transcription tools like transcribe_melody. The verb 'transcribe' and resource 'drums' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 examples. It implies when to use (percussive audio) but doesn't explicitly state when not to use or compare directly to alternatives like transcribe_melody.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 that the tool creates a SignatureEventBox on the timeline's signature track and returns details. However, it does not mention potential conflicts with existing signature changes at the same position or idempotency, which would strengthen 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, using only three sentences: purpose, distinction from sibling, and parameter descriptions. No redundant information; every sentence 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?
Given no annotations and three parameters, the description adequately covers the tool's function and parameter semantics. It mentions the return value (signature event details) and the effect on the signature track. Could provide a bit more about behavior with existing events, 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 description fully explains each parameter: position_beats (position in beats), numerator (beats per bar), denominator (note value per beat with examples). Since schema coverage is 0%, this compensates completely, adding meaning beyond type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds a time signature change at a specific position, using a specific verb ('Add') and resource ('SignatureEventBox'). It distinguishes itself from the sibling tool 'set_time_signature' by explaining the difference (global vs. mid-track).
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 'set_time_signature' and explains when to use this tool (for mid-track changes). It provides an example (4/4 → 3/4 → 4/4) to illustrate usage, making the context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description consistently describes a read-only analysis. It elaborates on what bands and global descriptors are computed, and mentions the return structure, providing good behavioral detail. No contradictions, but could mention that it requires a valid WAV file.
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?
Moderately long but well-organized with bullet points and examples. Front-loaded with purpose and followed by useful details. Could be slightly more concise, but no 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?
Given the single parameter, readOnlyHint annotation, and output schema (present), the description covers all essential aspects: what it does, what it returns (bands + global descriptors + suggestions), and how to use it. No 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 description fully explains the single parameter 'filename' with both relative and absolute path options, adding significant meaning beyond the schema's bare 'string' type. Since schema coverage is 0%, the description carries the full burden and does so excellently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Spectral analysis of audio across 7 ISO frequency bands' and lists the specific bands and metrics, making the tool's purpose unmistakable. It distinguishes itself from siblings like analyze_track by focusing on detailed frequency band 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 says 'Use after analyze_track for mix decisions' and provides concrete examples of when to use based on specific metric values (e.g., high low_high_ratio, low spectral_centroid), offering actionable guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description thoroughly explains the behavior: oscillates velocity cyclically based on note position, creates repeating patterns, and details the modulation parameters and their effects. Also documents return values. Some implicit behavior (like how rate syncs to beat) could be more explicit, but overall very informative.
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-structured: a brief summary, an explanation of the modulation effect, a key distinction from a sibling tool, a detailed Args list, and a Returns section. Every section adds value, though the Args list could be slightly more concise by integrating 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?
Given the complexity (8 parameters, output schema exists), the description is exceptionally complete. It covers all parameters, distinguishes from a relevant sibling, and describes return values. No gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 tool description includes a comprehensive Args section that explains each of the 8 parameters with examples, defaults, and meaning (e.g., rate cycles per beat, depth as modulation depth, shape waveforms, etc.). 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 it applies periodic velocity modulation using LFO, and explicitly contrasts with apply_velocity_curve which does monotonic ramps. The purpose is specific and easily distinguished 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 explicit guidance on when to use this tool (for repeating velocity patterns) and when to use apply_velocity_curve (for monotonic ramps). Includes details on the modulation effect (pumping, breathing, wave-like motion).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully explains both modes, including the fallback to clamp when range < 12 semitones. It also describes the return value. Missing details on whether modifications are in-place or return new data, 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is relatively long but well-organized with clear sections (modes, instrument ranges, parameter list, example). Front-loaded with core action. Slightly verbose but justified by detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all relevant aspects: modes, edge cases, parameter explanations, example, and return value. No output schema provided, but description compensates. Complete for a 6-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 description coverage is 0%, but the description adds complete meaning for all 6 parameters, including defaults, ranges, and an example call. This compensates fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 constrains notes to a pitch range using 'clamp' or 'octave_wrap'. It distinguishes from sibling tools like transposition or note manipulation by focusing on range correction.
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 specifies when to use: after AI generation, transcription, or aggressive transposition. Provides common instrument ranges and mode selection guidance (clamp for MIDI safety, octave_wrap for instrument constraints).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description shoulders the full burden. It comprehensively describes the chord format, pattern options, rate semantics, defaults, and return value ('Returns the total notes created and pitches used'). All behavioral aspects are disclosed without contradiction.
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 but structured: a one-line headline followed by a clean parameter list. It is efficient but could potentially be more concise by grouping related parameters (e.g., unit_index and track_index). Overall, it is well-organized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 9 parameters and the existence of an output schema, the description covers all inputs, defaults, return value, and provides examples. It places the arpeggio in context (track, unit, start beat) and explains the pattern behavior. No gaps are evident 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?
The input schema has 0% description coverage, so the description must fully document each parameter. It does so: chord format with examples, pattern list with explanations, rate values, octave, steps, velocity, start_beat, unit_index, and track_index all explicitly described. 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 starts with a specific verb-resource pair ('Create an arpeggio from a chord name') and immediately provides a comparative efficiency hook ('one call instead of 8-32 create_note calls'), clearly distinguishing this tool from its sibling 'mcp_opendaw_create_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 description clearly states the tool's purpose for arpeggio creation and contrasts it with create_note, giving strong contextual usage guidance. However, it does not explicitly list when not to use this tool or mention alternative arpeggio methods, though for a specialized tool this is less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: bassline octave and velocity defaults, pattern notation with special characters, return value, and parameter defaults. It provides comprehensive 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 thorough with examples and parameter details, which adds length but remains front-loaded and efficient. Slightly long but acceptable given 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?
Given 8 parameters, no annotations, and an output schema, the description covers purpose, pattern syntax, defaults, and return value comprehensively. No missing context for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 explains each parameter in detail, including root note formats, pattern syntax with examples, and defaults for octave, velocity, scale, etc. It 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 first sentence clearly states the tool creates a bassline from root note and rhythmic pattern, and explicitly contrasts with multiple create_note calls, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for bassline creation efficiently, contrasting with create_note, but does not explicitly mention when not to use it or provide alternatives among other bass-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 tool creates sustained chord pads with configurable parameters, describes return values (chords created, pitches, total notes), and covers default behaviors. However, it does not mention potential side effects or performance implications, which would elevate the score to 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 well-structured with a clear summary, parameter explanations, and examples. It front-loads the key differentiator and purpose. While comprehensive, it is slightly verbose but each sentence adds value. A score of 4 reflects good economy without being terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters, no annotations, and a complex harmonic domain, the description is remarkably complete. It covers input format, parameter roles, defaults, supported chord types, use case examples, and return values. The presence of an output schema is noted, and the description adequately explains what is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 adds extensive meaning for each parameter. It details the chord format (root+type), supported types (maj, min, dom7, etc.), explains bars_per_chord, octave, velocity, and other parameters with default values and examples. 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 the tool creates chord pads from a human-readable progression string. It explicitly distinguishes from the sibling tool create_chord_progression by contrasting the input format (hyphen-separated string vs JSON arrays). 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 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 the alternative create_chord_progression, noting that this tool is for simpler string inputs. It also gives genre-specific examples (synthwave, pop, jazz) and explains default behaviors, helping the agent decide contextually.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden. It explains that the tool creates notes on a track with specific parameters and returns notes, chords, and rhythm pattern. While it doesn't explicitly state non-destructive behavior or permission requirements, it gives sufficient detail about what the tool modifies and returns. Minor gap: no mention of whether it overwrites 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise purpose statement, sibling differentiation, then detailed parameter breakdown. It is front-loaded with the key concept. However, it is somewhat long; a few sentences could be trimmed without losing clarity. Still, it earns its length with useful context.
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 (9 parameters, no annotations, but output schema exists), the description is complete. It covers all parameters with examples, explains the return value, and provides musical context. No gaps remain for an agent to understand invocation requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 for parameters, so the description must provide full meaning. It does: every parameter (chords, rhythm, unit_index, track_index, start_beat, chord_octave, velocity, note_spacing, syncopation) is explained with format, defaults, and examples. The rhythm parameter even includes multiple pattern examples with musical context. This far exceeds schema capabilities.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'comping — rhythmic chordal accompaniment' and explicitly distinguishes it from sibling tools like create_chord_progression and create_stab by contrasting sustained vs rhythmic patterns. The verb 'create' and resource 'comping' 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Unlike create_chord_progression (sustained blocks) or create_stab (house stabs), comping gives each chord a rhythmic identity — the chord follows the groove.' This clearly explains the context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It details how voices cycle independently, alignment after LCM, output structure (total notes, voice periods, alignment interval), and constraints (2-6 voices, 1-16 bars). It does not mention error handling or side effects, but covers the core behavior 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 somewhat lengthy but well-structured: starts with definition, contrasts with sibling, explains parameters, lists common cross-rhythms, and provides an example. Every sentence adds value, though some text (e.g., lengthy list of common rhythms) could be more concise 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?
Given the tool's complexity and the presence of an output schema, the description is remarkably complete. It covers the concept, parameter details, usage examples, and return value. It implicitly references sibling tools and provides sufficient context 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, which it does excellently. It explains the 'voices' parameter format (comma-separated periods, 2-6 voices), 'bars' as total length in beats, and other parameters like 'base_velocity' (attenuation per voice). It also describes the return value, adding significant 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 defines what the tool does: 'Create a cross-rhythm — multiple voices with independent period lengths creating shifting alignment.' It distinguishes cross-rhythm from polyrhythm, provides musical context (African cross-rhythms, Steve Reich), and gives examples, making the purpose highly 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts cross-rhythm with polyrhythm, guiding when to use this tool versus a sibling (e.g., 'Unlike polyrhythm...'). It includes common cross-rhythm patterns and an example call, providing clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral burden. It discloses that the accompaniment loops indefinitely, the lead improvises, and the structure is call-and-response. However, it does not explicitly mention whether the tool is destructive (overwrites existing data) or safe, but the creative context implies it adds new material.
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 paragraphs, bullet-pointed style details, and a clear parameter list. It front-loads the overall purpose and structure, then details styles and parameters. A slightly more concise version could improve readability, but given the complexity, it is 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 complexity (12 parameters, multiple styles, musical context), the description is complete. It explains the instrument roles, style differences, and return values ('notes created, instrument breakdown, and rhythm info'). The output schema exists, so return value explanation is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 listing all 12 parameters with detailed explanations, including purpose, defaults, and pitch values. It even enumerates the four style options with rhythmic characteristics. This makes the parameters fully 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 clearly states it creates a West African djembe/dunun ensemble with cyclical ostinato and call-and-response. It uses specific verbs ('create') and resources ('djembe ensemble'), and distinguishes itself from related tools like samba and songo by contrasting the cyclical vs. linear 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 explains when to use this tool (for West African drumming) and contrasts it with samba (parade ensemble) and songo (drum kit), providing clear alternatives. It also describes the intended musical context and structure.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: tempo-aware, rhythmic locking, track assignments, return value. Lacks details on whether it overwrites existing notes or creates missing tracks. With no annotations, description carries full burden; mostly 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?
Well-structured with front-loaded purpose, bullet points, parameter list, and examples. Slightly verbose but each 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?
Complete description for a complex multi-track arrangement tool. Covers behavior, parameter semantics, and examples. Output schema handles 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?
Provides detailed explanations for all 10 parameters (ranges, defaults, meanings) despite 0% schema description coverage. Fully compensates with clear 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?
Clearly states it creates a full drum & bass arrangement across 3 tracks. Uses specific verb-resource combination, distinct from sibling genre-specific 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly frames as multi-track alternative to creating individual patterns, with genre-specific guidance. Provides examples and notes when to use (DnB genre) vs. other arrangement tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's behavior: it creates notes on specific tracks, describes the musical content for each track, and specifies return value (notes per track and total). No contradictions with any structured fields.
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 bullet points, musical breakdown, and examples. Each part adds value, though it could be slightly more concise. Still efficient for the 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?
Given 11 parameters, 0% schema coverage, no annotations, and an output schema, the description is highly complete: it explains the style, each track's role, parameter details, defaults, ranges, and examples. It covers all necessary context 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 has 0% description coverage, but the description explains every parameter with defaults, ranges, and musical context (e.g., 'bpm: Tempo (70-90, default 78)', 'octave: MIDI octave for bass'). This 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 'Create a full lofi hip-hop arrangement' with specific musical details for each track, effectively distinguishing it from sibling tools that create other genres (e.g., create_blues_arrangement). The verb 'create' and resource 'arrangement' are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 lofi hip-hop arrangements) and provides examples and parameter ranges. While it doesn't explicitly state when not to use it, the context of sibling tools covering other genres implies appropriate usage. Lacks explicit alternatives but still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It thoroughly explains the Markov chain behavior, order options, transition probabilities, and mention of returns (notes, statistics, seed). No hidden behaviors.
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, conceptual explanation, contrast, and parameter list. While long, each section adds value and no content is redundant. Could be slightly more concise but still 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?
Given 12 parameters and complexity, the description covers all behavioral aspects, parameter semantics, and expected outputs. 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?
Schema description coverage is 0%, but the description provides detailed explanations for all 12 parameters in the Args section, including default values, formats (e.g., interval_weights JSON example), and allowed 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 clearly states the tool's purpose: 'Create a melody using a Markov chain over scale-degree intervals.' It explains the concept of Markov chains and contrasts with random_walk, making the unique value proposition evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises when to use this tool (for stylistic memory) and explicitly contrasts with random_walk. It explains the transition matrix options (default vs custom) but does not list other alternatives or explicitly 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the process (stages, continuous line) and notes that it writes one continuous line. It could mention whether it modifies existing data or creates new, but the description is fairly transparent 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 summary, then detailed explanations. It front-loads the purpose and uses bullet points for parameters. While slightly long, 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?
Given the tool's complexity (10 parameters, generative process) and the presence of an output schema, the description covers input, process, and output (returned metrics) completely. It leaves no major 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 compensate. It explains every parameter in detail, including motif formats (scale degrees or MIDI, with examples), step options, and defaults. This is exemplary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 (develop), resource (motif), and output (through-composed melodic line). It explains the compositional stages and distinguishes from siblings like create_variations and create_sequence, which enhances purpose clarity.
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 (to evolve a short motif into a continuous line) and when not (if separate regions are needed, use create_variations; if pure transposition, use create_sequence). This helps the agent select correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the internal behavior (repeating bass pattern, evolving harmonies, variation styles) and output (returns notes created, etc.). Lacks details on error handling or invalid input, but is thorough 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with upfront purpose, historical context, differentiation, and detailed parameter list. A bit verbose but well-organized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers musical form, parameter details, return values, and usage context. No annotations exist, but the description fully compensates. Suitable for a 12-parameter tool with no required inputs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Provides extensive parameter descriptions with examples, defaults, and supported values (e.g., MIDI pitches, chord types, velocity ranges). Adds significant meaning beyond the schema 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?
Clearly states the tool creates a passacaglia with a specific verb+resource structure. Differentiates from related forms like ostinato and pedal_point, providing historical and modern context.
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 distinguishes this tool from siblings (ostinato, pedal_point, bordun) with a direct comparison. Describes the musical context and appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries full responsibility. It thoroughly explains behavioral traits: each track's content (drums, bass, chords, lead), musical theory (i-VI-III-VII progression, half-time feel), and return value ('notes created per track and total'). There is no contradiction with annotations as none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose sentence, track-by-track breakdown, parameter explanations, and examples. However, it is slightly verbose (e.g., repeating the tempo feel) and could be streamlined without losing clarity. Still, it earns a high score for effective organization.
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 (genre-specific arrangement with 11 parameters) and the presence of an output schema (indicating return structure), the description covers all necessary aspects: track content, musical theory, parameter guidance, and examples. It is fully sufficient 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?
Schema description coverage is 0%, but the description adds significant meaning: it explains the purpose of each parameter (e.g., 'bpm: Tempo (55-85, default 68 = modern R&B sweet spot)'), provides examples, and links parameters to musical context (e.g., 'root: Root note (C minor = dark R&B key)'). 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 'Create a full modern R&B arrangement' with specific verbs ('Create') and resources ('arrangement'). It distinguishes from sibling tools by detailing the R&B style, including artists (The Weeknd, Frank Ocean) and harmonic/melodic characteristics, making it 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: BPM range (55-85, default 68), bar length must be multiple of 4, and example calls. It implicitly suggests use for R&B composition but does not explicitly exclude other genres or state when not to use. Alternatives (sibling tools) are not mentioned but the genre-specific content guides appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It details that the tool transforms motifs via imitation, inversion, retrograde, etc., and explains the swap parameter's effect. It also mentions the return value (notes created, mode, statistics). Minor missing detail on potential side effects, but overall 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 and front-loaded with purpose, but slightly lengthy due to the enumeration of transformation modes and parameter list. While every sentence adds value, minor redundancy exists (e.g., repeating 'motif passes between voices'). Still above average.
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: it explains the technique, lists transformation modes, details all parameters, and mentions return values. With an output schema existing, the return description is sufficient. The tool is complex but the description is 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?
Schema description coverage is 0%, so the description must compensate fully, which it does. It explains all 12 parameters with clear semantics, default values, and even interaction notes (e.g., duration_factor overrides modes). 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 clearly states the tool creates a voice exchange, a specific contrapuntal technique. It uses precise verb and resource ('Create a voice exchange') and explicitly distinguishes from sibling tools like clone_track and copy_notes_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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with clone_track and copy_notes_to_track, stating that this tool transforms material rather than copying exactly. It provides clear context for when to use (imitative counterpoint) and when not to use (exact copies), and outlines the transformation modes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details the algorithm (onset detection + autocorrelation), pure Python implementation, return fields with ranges, and the use case. No contradictions 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 well-structured with a clear purpose, algorithm steps, use case, parameter, return fields, and example. It is slightly verbose with algorithm details but remains front-loaded 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?
Given the tool's simplicity (one parameter, no nested objects), the description covers all essential aspects: purpose, usage, parameter, returns, and example. The presence of an output schema means 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.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description thoroughly explains the 'filename' parameter: it can be a name in the exports directory or an absolute path, and includes an example. This fully compensates 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 clearly states 'Detect BPM (tempo) of an exported WAV file' with a specific verb and resource. It distinguishes from siblings like mcp_opendaw_set_bpm by outlining the detect→set workflow for Suno integration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 it (for Suno tracks before setting BPM) and provides a usage example. However, it does not explicitly list alternative tools or scenarios where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description details the 7 problem types, the filename parameter constraints (exports dir or absolute path), and the output format (severity, value, recommendation). No contradictions 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?
Well-structured with a numbered list and example, but slightly verbose. Front-loaded purpose, but could be trimmed by a sentence or two. Still efficient and 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?
Given the output schema exists (not shown but referenced), the description provides example output and covers input constraints. All necessary information for an AI agent 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?
With 0% schema description coverage, the description fully compensates by explaining the filename parameter: 'WAV file in exports dir, or absolute path.' This adds crucial context beyond the schema's type/required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 detects 7 specific technical audio problems (clipping, DC offset, hum, sibilance, mud, harshness, resonances), which distinguishes it from other analysis tools like detect_bpm or analyze_mix. The verb 'detect' and resource 'technical audio problems' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 checking audio quality issues and provides an example, but does not explicitly contrast with sibling tools (e.g., detect_frequency_masking) or state when not to use it. Still, 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.
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 clearly states what the tool does: creates a copy of every note shifted by an interval, and describes the behavior for chromatic and diatonic modes, return value (count of notes doubled). It does not explicitly state that it modifies existing notes (destructive) or if it requires a selected region, but the overall behavior is well explained. A small gap: no mention of prerequisites (e.g., track must exist) 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 fairly long but well-structured: it starts with a one-line purpose, then contrasts with sibling, explains mode options, lists interval definitions with musical context, and ends with example use cases. It could be slightly shorter by omitting some interval details that might be redundant for experienced users, 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.
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 an output schema (present), the description covers all essential information: what the tool does, when to use it, how each parameter works, and example invocations. It provides enough context for an AI agent to select and invoke the tool correctly, including clarification of edge cases (same-region vs cross-track, diatonic mode requirements).
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 descriptions in the input schema parameters). The description compensates fully by explaining each parameter in detail: interval options with musical context, diatonic mode requirements, velocity_scale, time_offset, unit_index, track_index, etc. It 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a clear action verb and resource: 'Double a melody at a parallel interval — thickening and harmonization.' It explicitly contrasts with the sibling tool copy_notes_to_track by highlighting support for named intervals and diatonic transposition, making the purpose distinct 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 on when to use this tool versus alternative: 'Unlike copy_notes_to_track (chromatic transpose only), this supports named musical intervals and diatonic transposition (stays in key).' It further explains two distinct use cases (same-region vs cross-track) and includes concrete examples for octave doubling, diatonic thirds, and power-chord doubling, leaving no ambiguity about usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It lists all returned metrics (onset grid, IOI, syncopation, density, rhythm string, swing factor) and explains grid resolutions. No hidden 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?
Well-structured with summary, return fields, grid resolutions, use cases, and parameter list. Slightly long but efficient; 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?
Output schema exists but description compensates with clear return value descriptions. Covers enough for agent to use correctly without external reference.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 0%, but description fully documents all 4 parameters: unit_index, track_index, region_index (with default -1), and grid (with enumerated values and defaults). Adds meaning beyond 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?
Clear verb+resource: 'Extract rhythmic pattern from notes'. Distinguishes from siblings like groove_transfer or harmonic rhythm analysis by focusing on rhythm 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?
Provides explicit use cases (cloning, syncopation measurement, groove transfer, comparison, melody generation). Does not state when not to use, but context is clear given sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behaviors: it creates instrument tracks, loads stems, and describes the pipeline. It mentions side effects like track creation and returns detailed info.
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 overview, parameter details, return info, and examples. It is slightly verbose but each section adds value. Could be tightened without loss of 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?
Given the tool's complexity and presence of an output schema, the description covers all necessary aspects: return values (track count, per-track info, suggested next steps) and integration with other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by explaining each parameter (file_path, mode, start_beat, bpm) with details, default values, and mode options. Examples 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 it imports audio files, optionally splits into stems, creates tracks, and places them at start_beat. It uniquely positions itself as a 'Suno-to-DAW bridge', distinguishing it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance on when to use (import audio, optionally with stem separation) and includes examples for different modes. However, it does not explicitly mention when not to use or provide alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond the readOnlyHint annotation by detailing what each profile contains (LUFS, spectral balance, stereo width, dynamic range). This informs the agent about the output 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 concise with three short paragraphs, each adding value: purpose, content detail, and usage guidance. No extraneous information; perfectly 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 absence of parameters and the presence of readOnlyHint and an output schema, the description fully covers what the tool does and the nature of its return values. It references a sibling for further action, making it contextually complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no additional semantics are needed. The description implicitly covers the purpose, meeting the baseline expectation for no-param 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 explicitly states 'List all available genre reference profiles for mix analysis', providing a specific verb and resource. It clearly distinguishes this tool from siblings like compare_to_profile(), which uses these profiles.
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 clear guidance by stating 'Use compare_to_profile() to check your mix against any of these', telling the agent when to use this tool vs. the sibling. It implies a prerequisite: list profiles before comparing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly indicates a read-only operation (list) consistent with the readOnlyHint annotation. It details the return value (warp marker list with position, seconds, isAnchor) and the edge case (empty if no stretch mode), providing full 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 concise and well-structured: purpose, background, parameters, return value. 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 tool's simplicity and existing output schema, the description covers purpose, usage context, parameters, return behavior, and edge case. It is fully self-contained 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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining each parameter (unit_index, track_index, region_index) with brief descriptions. While not exhaustive, it adds meaningful context beyond the schema's empty 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 warp markers on time-stretched or pitch-stretched audio regions, with a distinct verb and resource. It differentiates from sibling tools like create_warp_marker, delete_warp_marker, and update_warp_marker by focusing on listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 is used for tempo-matching audio regions, providing context. However, it does not explicitly state when not to use it. Alternatives like get_region_info are not mentioned, so guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, it details exactly what is removed (audio units, tracks, regions, effects) and notes the output audio unit is preserved. This adds significant 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 two sentences plus a note, all front-loaded with the main purpose. Every sentence adds value 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?
Given the tool has no parameters, annotations cover destructiveness, and description explains effects and use case, the information is complete. Output schema exists but description doesn't need to cover 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?
With zero parameters, the description adds context about the tool's effect but doesn't need parameter details. Baseline for 0 params 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 the tool resets the project to a fresh state, removing all audio units, tracks, regions, and effects. The verb 'reset' and resource 'project' are specific, and the destructive nature distinguishes it from creation or loading 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 explicitly says 'Useful for starting a new mix session without reloading the browser,' providing clear context. However, it does not explicitly mention when not to use it or list alternatives like load_project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It explains the surgical behavior, tonic preservation, and per-note shift logic. While it doesn't explicitly mention edge cases (e.g., notes outside from_scale), the detailed examples and parameter descriptions provide sufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with summary, behavior explanation, examples, comparisons, and args. However, it is somewhat verbose—some sentences could be trimmed without losing value, but the overall organization aids 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 output schema exists, the description adequately covers the tool's complexity: 7 parameters explained, behavior contrasted with siblings, and return value mentioned. No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 includes an 'Args' section that explains every parameter, including defaults and special values like -1. This adds substantial meaning 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 opens with a clear verb+resource ('Transform notes from one scale/mode to another, keeping the tonic') and explicitly distinguishes itself from sibling tools like force_scale_notes and reharmonize_progression, making its unique function 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 provides when-not guidance by contrasting with force_scale_notes (snaps to nearest scale tone) and reharmonize_progression (works on chord symbols), and includes multiple examples illustrating typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the burden of transparency. It explains that content is exchanged, different lengths are handled, and gaps between sections stay in place. This gives a clear behavioral model without requiring 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 well-structured with paragraphs and an explicit Args section, but it is somewhat lengthy. It could be slightly more concise while retaining 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?
Given the tool's complexity (swapping with length differences, gaps, units), the description covers all key behaviors and even mentions return format. An output schema exists, but the description still adds value by explaining sections_swapped, notes_moved, and section sizes.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 includes an 'Args' section that explains all five parameters clearly: section1_start/end, section2_start/end, and unit_indices. This adds essential 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 swaps two sections of the arrangement by exchanging their positions. It uses specific verbs ('swap', 'exchange') and resources ('sections', 'arrangement'), and distinguishes from sibling tools like move_section or reorder_sections by focusing on a reciprocal exchange.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 song structure experimentation' and gives examples like swapping chorus before verse. However, it does not explicitly state when not to use the tool or mention alternative tools like reorder_sections for multi-section reordering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's behavior: it reads existing notes, computes target onsets, distributes notes round-robin or to nearest onset, and optionally adjusts velocity/duration. Edge cases like pattern cycling and note distribution are explained, making the tool's behavior completely 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 clear introductory sentence, a 'How it works' section, parameter definitions, and an example. Every sentence contributes meaning, and there is no redundancy. It is comprehensive yet 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?
Given the complexity of 8 parameters, no schema descriptions, no annotations, and an output schema, the description covers all necessary context: algorithm steps, parameter details, edge cases, and return value. It is fully 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 has 0% description coverage, so the description must compensate. It does so thoroughly by explaining each of the 8 parameters, including their format, default values, and behavioral implications (e.g., velocity_mode options, rhythm_string vs onset_grid priority). This adds immense 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: apply a rhythmic pattern to existing notes by repositioning onsets. It uses specific verb+resource ('apply a rhythmic pattern') and distinguishes itself as the inverse of 'extract_rhythm.' The sibling context is implicitly handled by explaining the relationship to extraction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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, including an example workflow with extract_rhythm. However, it does not explicitly state when not to use it or list alternative tools beyond mentioning its inverse relationship. The guidance is strong 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true. Description adds context about what is preserved and the operation's effect, though the behavior is well covered by the purpose 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?
Front-loaded with core action, followed by explanation, sibling differentiation, parameter details, and examples. 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?
Covers purpose, usage, parameters, examples, expected output, and distinguishes related tools. Adequate given complexity and presence of 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?
With 0% schema description coverage, description compensates by explaining each parameter's meaning (unit_index, track_index, region_index) and provides usage 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?
Description clearly states the tool clears all notes from a region while preserving the region. It explicitly distinguishes from siblings delete_note_region and delete_note.
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 when-to-use scenario ('erase and rewrite') and contrasts with alternative tools, giving clear guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully handles behavioral context. It discloses key traits: copies parameters, appends effects to destination's existing chain, returns list of cloned effects with new indices. This is comprehensive for a clone 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?
Five short sentences, no fluff. Core action in first sentence, use case in second, parameter explanations in third and fourth, return format in fifth. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (clone operation), no output schema needed for completeness, but the description mentions the return format. Context signals (2 params, no nested objects, output schema exists) are adequately addressed. No missing elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 parameters (0% coverage), but the description explains each parameter inline: 'src_unit: Source audio unit index.' and 'dst_unit: Destination audio unit index (effects appended to existing chain).' 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 clearly states the action: 'Copy all effects from one audio unit to another, including parameter values.' The verb 'copy' and resource 'effect chain' are specific. It distinguishes from siblings like 'duplicate_effect' (single effect) and 'move_effect' by specifying it copies all effects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a concrete use case: 'applying the same vocal chain (EQ → compressor → reverb) to doubled vocal tracks.' This helps the agent understand context but does not explicitly mention when not to use or what alternatives exist (e.g., for partial cloning use duplicate_effect individually).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It describes the core behavior: copying a melody into multiple voices with time and pitch shifts, and notes return values. However, it does not explicitly state whether the tool is destructive or read-only, or if it modifies existing track content versus creating new regions. Still, it is fairly transparent about inputs and outputs.
Agents need to know what a tool does to the world before calling it. Descriptions 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 opening sentence defining the tool, a paragraph explaining the musical concept and distinguishing from siblings, followed by a bulleted list of parameters. 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?
Given the tool's complexity (10 parameters, no required fields, no enums) and that an output schema exists, the description is complete. It explains all parameters, provides examples, and mentions return values. The only minor gap is potential side effects, but the output schema covers return info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema (which has 0% coverage). Each parameter is explained with ranges, defaults, examples, and constraints (e.g., 'transposition must have exactly voices 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 defines the tool's purpose: 'Create a canon — strict melodic imitation with delayed voice entries.' It specifies the verb 'create' and the resource 'canon', and distinguishes from sibling tool 'create_counterpoint', which generates a new independent melody rather than copying the same melody.
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 (to create a canon) and when not to (for generating new independent counterpoint). It directly contrasts with 'create_counterpoint' and gives real-world examples like Pachelbel's Canon and 'Row Row Row Your Boat' to clarify usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description carries the full burden. It explains the creation of new internal objects (AudioBusBox, etc.) and the signal flow (dry signal unchanged). It states the return indices. However, it does not explicitly address error cases (e.g., invalid src_unit) or performance implications. Still, the behavioral coverage 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a concise opening sentence, followed by technical details, parameter breakdown, return info, and a workflow example. It is detailed without being verbose; every sentence contributes necessary 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?
Given the tool's complexity (creating multiple bus/unit objects) and the presence of an output schema, the description covers all essential aspects: what is created, parameter details, return values, and usage workflow. An agent can confidently invoke this tool based on the 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?
The input schema has 0% description coverage, so the description must compensate fully. It does so by explaining each parameter: src_unit (source unit index), name (FX bus name), send_level_db (range -∞ to +12 with suggested value), routing ('pre' or 'post' with default). This adds critical meaning 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 clearly states it creates a parallel FX send bus, distinguishes it from a redirect, and explains the internal components (AudioBusBox, AudioUnitBox, AuxSendBox). The purpose is specific and unambiguous. Among siblings, there is no other create_send tool, but it differentiates from general audio bus 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit workflow guidance: create_instrument_track → create_send → add_effect. It explains when to use this tool (parallel send) and what not to do (redirect). Parameter constraints are given with examples (e.g., send_level_db -∞ to +12, -6dB suggested). This leaves no ambiguity for the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It explains that audio plays at a different speed while syncing to project tempo and mentions warp markers. It lacks details on potential side effects or permissions, but for a creation tool, 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 front-loaded with the main action and a key differentiator, followed by a compact parameter list. Every sentence adds value without redundancy. It is efficient and well-structured.
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 thorough. It explains the concept, differentiates from a sibling, lists all params with defaults, and summarizes the return values. The presence of an output schema complements the brief return description, making it 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.
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 explain all parameters. It does so comprehensively: sample_id links to load_audio, unit_index defaults, start_beat is positional, playback_rate with examples, transient_mode with valid values, and bpm for warp calculation. Each parameter's purpose is 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 clear verb+resource: 'Place a time-stretched audio region on a track.' It explicitly contrasts with the sibling tool place_audio_region, highlighting the musical timing and warp markers, which effectively distinguishes it 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance by contrasting with place_audio_region, stating that this tool uses musical timing (beats) instead of seconds. This helps the agent decide when to use 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.
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 thoroughly explains the behavior: lowest note to voice 1, handling of fewer/more notes, direction options, velocity balance options, and target unit behavior. This level of detail exceeds expectations for 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 well-structured: a concise one-liner, followed by a process explanation, a typical use example, and then parameter details. Every sentence adds value without redundancy. It's 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 fully covers the tool's functionality, parameter details, and use cases. With an output schema available (though not provided), the description does not need to explain return values. It is complete for an agent to correctly 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 provides comprehensive meaning for each parameter: defaults, valid ranges (2-8 for num_voices), behaviors (e.g., 'Chords with fewer notes... get rests'), and options (direction and velocity_balance with enumerated values). This fully compensates for the schema 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 clearly states the tool 'Explodes chords into separate voice tracks' and explains the orchestration process. The verb 'explode' is specific, and the resource ('chords' into 'voice tracks') is well-defined. This distinguishes it from sibling tools like 'invert_chord_notes' or 'spread_voicing' by focusing on splitting chords into separate tracks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides typical use cases ('piano chord track → bass + cello + viola + violin') and explains the orchestration technique. It does not explicitly state when not to use it or list alternatives, but the context is clear. The presence of many sibling tools makes this a solid 4, as it offers enough guidance for selecting the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description explains the operation (adds per-note cent offsets), return values (per-track counts, total detuned, cent range), and parameter effects. Lacks explicit statement on reversibility or side effects, but 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Contains two paragraphs plus a bullet list and an example. Every sentence adds value, no fluff. Front-loaded with purpose and usage, then parameter details, then example.
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?
Complete for a tool with 6 parameters, no annotations, and an output schema. Covers purpose, usage guidelines, parameter semantics, and return value. Includes examples and distinguishes from sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 coverage, description fully documents each parameter: unit_index, track_index, region_index with -1 meanings; cents_depth with qualitative examples; bias direction; seed for reproducibility. Adds significant meaning beyond 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?
Clearly states it adds micro-detune (cents) to notes for intonation humanization. Distinguishes from sibling humanize_notes which handles velocity/timing/duration but not pitch.
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 humanize_notes and provides specific use cases (string sections, vocal MIDI, brass, sterile MIDI). Tells when to use and when not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the readOnlyHint annotation: it explains clip types, properties returned (type, index, duration, mute, label, loop), and parameter behavior. 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 efficiently structured: a one-line purpose statement, followed by clip type details, parameter explanations, and return list. Every sentence adds value 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 simplicity and the presence of an output schema, the description covers what the tool does, parameter meanings, and return fields. It is complete for an AI agent to understand 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 titles with 0% description coverage. The description fully compensates by explaining each parameter: unit_index is 'Audio unit index' and track_index is 'Track index (-1 = all tracks on the unit).' This adds essential 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 clearly states the tool's purpose: 'List clips (session view / clip launcher) on tracks.' It specifies the three clip types and their properties, making the resource and verb unambiguous. This distinguishes it from siblings like list_tracks 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?
The description provides explicit parameter explanations, including the special case of track_index = -1 for all tracks. However, it does not explicitly discuss when not to use this tool or compare it to alternatives, though the context is clear for listing clips.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It details the algorithm (grouping by position, offsetting by speed and index), parameter effects, and return value. 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?
The description is concise (~250 words) and well-structured: purpose, parameter details, algorithm, return value, and examples. 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?
Given 6 parameters with no schema descriptions and an output schema, the description covers algorithm, all parameters, return type, and provides three practical examples. 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 adds comprehensive parameter explanations: direction values with musical context, speed with note equivalents and range, jitter with range and purpose, and indexing parameters with meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 converts block chords into strum patterns, using a specific verb ('strum') and resource ('notes'). It distinguishes from siblings like arpeggiation or rhythm application by focusing on guitar-style strumming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 (static chord pads needing lifelike strumming) but doesn't explicitly exclude alternatives or mention when not to use. Context is clear but lacks direct sibling comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: scales both position and duration, moves notes in time without changing BPM, describes warp_factor range and meaning, explains the origin anchor point, and mentions return value (modification counts, region extent). 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?
The description is well-structured: a concise introductory sentence followed by bullet-style explanations of parameters and behavior. It is front-loaded with key information 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?
Given the complexity of the tool (warp factor, origin, multiple indexes), the description covers all essential behavioral and input aspects. Output schema exists, and the description also mentions return values. No gaps or unanswered questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 five parameters (unit_index, track_index, region_index, warp_factor, origin) with defaults, ranges, and behavioral meaning. For example, it clarifies that -1 means 'all' and describes the effect of each origin value. 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 warps note positions and durations by a factor, with specific examples (half-time, double-time). It distinguishes from the sibling tool scale_durations by noting that this tool moves notes in time rather than just changing length.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select 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 scenarios (half-time, double-time, custom stretch) and contrasts with scale_durations. It also mentions genre use cases (trap, lofi). However, it doesn't explicitly state when not to use this tool or list alternative tools beyond scale_durations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the deep-copy behavior with all dependencies, describes parameters for move semantics and insert position, and mentions the return values. Lacks explicit details on whether source is modified when delete_source is false, but 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 four sentences, front-loaded with the main purpose, then technical details, followed by parameter explanations. No wasted words; all information 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 complexity (deep-copy with dependencies, move semantics), the description covers what it does, how it works, parameter details, constraints, and return values. Has output schema so not required to explain returns, but it still lists them. 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?
Schema coverage is 0%, so the description must explain each parameter. It does so thoroughly: unit_index as source, delete_source for move semantics, and insert_index for mixer order with auto-place behavior. Adds 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?
Clearly states it transfers/copies an audio unit, specifies it deep-copies with all dependencies, and distinguishes itself from duplicate_audiounit by noting higher completeness and the limitation that output unit cannot be copied.
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 compares with duplicate_audiounit, stating this tool is more complete and uses box-graph serialization, guiding when to prefer this tool. Also notes the output unit cannot be copied, setting clear constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses the tool's behavior: it finds notes on strong beats, shortens them, and inserts an anticipation note on the weak beat before. It explains the effect on the original note structure and details parameter impacts, providing complete transparency without contradicting any 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 comprehensive but somewhat lengthy due to musical theory context and parameter details. However, it is well-structured with a clear front-loaded purpose, a logical flow from concept to parameter list, and no irrelevant information. It earns its 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?
Given the tool's complexity (11 parameters, output schema exists), the description covers all necessary aspects: musical context, structural effect, parameter semantics, and differentiation from siblings. It is fully complete for an AI agent to understand 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?
With 0% schema description coverage, the description compensates by providing detailed explanations for all 11 parameters in an 'Args' section, including defaults, ranges, and musical meanings (e.g., anticipation_offset as 'sixteenth note before'). This 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 'Add anticipation notes before strong-beat notes' and provides a thorough explanation of the anticipation technique, distinguishing it from passing tones, suspensions, and neighbor tones. It also lists genres where it is used (jazz, pop, Latin), making the purpose unmistakable and 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?
The description explicitly contrasts anticipation with other non-chord tone techniques (passing tones, suspensions, neighbor tones), providing clear guidance on when to use this tool versus alternatives. It also explains the musical context and structure, helping the agent understand the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses internal behavior: it describes the automation events generated ('[[0, false], [start_beat, true], [end_beat, false]]') and confirms that all tracks are restored. This provides comprehensive 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 with a clear breakdown: purpose, benefit, internal mechanism, parameter list, and examples. It is slightly lengthy but every sentence adds value; could be slightly more concise but remains 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 complexity (5 parameters, output schema exists) and no annotations, the description covers all aspects: purpose, usage context, internal logic, parameter semantics, return value, and practical examples. It is complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 defining each parameter (solo_track, total_tracks, start_beat, end_beat, unit_indices) with clear explanations and examples, adding significant meaning beyond the 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: 'Mute all tracks except the solo track for a beat range, then restore.' It uses a specific verb and resource combination, and explicitly differentiates itself from the sibling tool create_mute_automation.
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 explains when to use this tool (e.g., 'Essential production technique: spotlight one element') and explicitly contrasts it with the alternative of multiple create_mute_automation calls, providing clear usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Although no annotations are provided, the description explains the key behavioral trait: 'The engine serializes the current project state into the AudioWorklet processor, so all boxes must exist first.' This gives the agent insight into what happens internally and why ordering matters.
Agents need to know what a tool does to the world before calling it. Descriptions 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—only three sentences. The first sentence states the core purpose, and the next two provide essential usage guidelines and behavioral insight. Every sentence is necessary and well-structured.
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, no complex side effects) and the presence of an output schema (so return details are already documented), the description covers all necessary context: purpose, prerequisites, sequence, and internal 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?
The tool has zero parameters, so the baseline is 4. The description does not need to add parameter meaning, but it provides relevant context about the tool's prerequisites and behavior, which is more than sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Start the audio engine' and identifies the resource ('AudioWorklet'). It includes the prerequisite 'after setting up tracks and regions', which distinguishes it from other engine control tools like engine_panic, engine_sleep, and engine_wake.
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 specifies when to call the tool: 'Call this AFTER loading audio, creating tracks, and placing regions — but BEFORE playback or effects.' This provides clear sequencing and context, though no alternatives are listed since this is a one-time startup step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 explains the algorithmic structure (splitting the original note into three parts: first part, neighbor, return), with precise details on how the neighbor is placed. It discloses that short notes are skipped (min_duration_beats parameter) and that the default neighbor velocity is softer than the main note. It also explains the cross_track parameter for preserving original notes. This is 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: a one-sentence summary, a musical explanation, a structural outline, a comparison to siblings, genre examples, and then a clearly formatted parameter list. Every sentence adds value—no fluff, no repetition. It front-loads the core purpose and immediately differentiates from related tools. The parameter descriptions are concise yet informative, using consistent formatting.
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 exhaustive for a tool with 11 parameters and no schema descriptions. It covers the musical theory, the splitting algorithm, all parameter constraints, defaults, and even cultural context (Bach, jazz, country, classical). The output schema exists, so return values need not be explained. The description leaves no significant gaps for an agent to understand 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%, meaning no parameter descriptions in the JSON schema. The description compensates fully by explaining every parameter in detail, including valid ranges, defaults, and musical implications. For example, neighbor_fraction is described as '0.1-0.5, default 0.25' with guidance on subtle vs prominent effects. neighbor_offset: '0.1-0.9, default 0.5' with examples (0.15 near start, 0.5 middle, 0.85 near end). direction: explains 'upper', 'lower', 'alternating' with context. This adds immense 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 begins with a clear verb+resource: 'Add upper/lower neighbor tones to embellish existing notes.' It immediately distinguishes neighbor tones from passing tones by explaining that neighbor tones ornament a single sustained note while passing tones connect two different notes. This explicitly differentiates it from its sibling tools like mcp_opendaw_add_passing_tones, establishing a 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts neighbor tones with passing tones ('Unlike passing tones which connect two different notes...'), and positions it as the third of four classic non-chord tone techniques (passing tones, suspensions, neighbor tones, anticipation). This provides clear guidance on when to use this tool versus alternatives. It also lists genres where neighbor tones are used, helping the agent choose appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: maps note position to velocity via mathematical curves, explains each curve type's shape, and indicates return value (per-region counts). This goes beyond minimal requirements.
Agents need to know what a tool does to the world before 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: one-line summary, behavioral paragraph, parameter breakdown, return info, and examples. Every sentence adds value; no repetition 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?
Covers purpose, usage guidance, parameter semantics, behavior, return values, and examples. The output schema exists, and the description still explains what is returned. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools 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 compensates by explaining all 7 parameters: unit_index, track_index, region_index, curve_type (with 5 shapes), start_velocity, end_velocity, and power. It also provides default values and 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 clearly states the tool applies a velocity envelope across notes, specifying deterministic curve shapes. It distinguishes from 'humanize_notes' by contrasting deterministic vs random, providing 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (deterministic envelope for expressive phrasing) vs alternative ('humanize_notes' for random variation). Also provides examples for common use cases like build-ups and crescendo rolls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully explain behavior. It states that the tool 'reads current average velocities, computes scale factors to reach targets, and applies them' and that 'Original relative dynamics within each track are preserved (multiply mode).' It also notes that it returns per-track velocity stats before/after, giving a complete picture of 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 well-structured with sections: summary, presets list, behavioral notes, parameter explanations, and a usage example. Every sentence adds value without redundancy. It is concise yet comprehensive.
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 5 parameters, 0% schema coverage, no annotations, and an output schema (which isn't shown but exists), the description covers all necessary aspects: purpose, when to use, behavior, parameters, return value, and examples. It also differentiates from a sibling tool. The description is complete for 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?
Schema description coverage is 0%, so the description must compensate. It explains each parameter: track_indices as comma-separated indices, preset as one of five named presets or 'custom', target_velocities for custom mode, and region_index with defaults. It also provides a detailed example showing how to use parameters together.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships 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 'Balances velocities across multiple tracks — MIDI mix leveling.' It uses a specific verb ('balance velocities') and resource ('multiple tracks'), and distinguishes itself from the sibling tool 'scale_velocity' which operates on one track at a time.
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 (for relative balance across multiple tracks) and when not (use scale_velocity for a single track). It provides multiple presets and a custom mode, along with examples of how to use the tool with different parameter combinations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, description adds details: analyzes pitch class distribution, uses Pearson correlation, tests 15 specific scales, returns structured output with confidence rating. No contradiction.
Agents need to know what a tool does to the world before 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: one-sentence summary, method explanation, list of scales, return value details, usage suggestions, parameter descriptions, and example. All sentences are relevant and 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?
Despite having an output schema, the description already covers return values explicitly. Tool has only 3 parameters, and description explains all. Complete and no 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 descriptions coverage is 0%, but description explains each parameter: unit_index, track_index, region_index (with default -1 meaning first region, -2 meaning all). Provides example usage with region_index defaulting to -1.
Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'detect musical scale/key from MIDI notes in a region', differentiates from sibling 'detect_key' which works on WAV audio. Provides method (Pearson correlation against 15 scales) and lists the scales.
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 when to use it: before force_scale_notes, diatonic_transpose_notes, generate_melody, reharmonize_progression. Contrasts with detect_key for audio-based key detection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![opendaw-mcp MCP server](https://glama.ai/mcp/servers/AMEOBIUS-team/opendaw-mcp/badges/card.svg)](https://glama.ai/mcp/servers/AMEOBIUS-team/opendaw-mcp)

Score Badge

Copy to your README.md:

[![opendaw-mcp MCP server](https://glama.ai/mcp/servers/AMEOBIUS-team/opendaw-mcp/badges/score.svg)](https://glama.ai/mcp/servers/AMEOBIUS-team/opendaw-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/AMEOBIUS-team/opendaw-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server