ReaperMCP
Server Quality Checklist
Latest release: v0.6.3
- Disambiguation3/5
Many tools have overlapping purposes, such as multiple ways to insert MIDI notes (compose_arrangement, midi_insert_note, midi_insert_notes_batch, create_drum_pattern, create_chord_progression) and batch vs single-item operations. Although descriptions often note preferences, the sheer number of similar tools makes it difficult for an agent to quickly choose the correct one.
Naming Consistency3/5Most tools follow a verb_noun pattern (e.g., transport_play, item_set_volume), but there are inconsistencies like marker_add vs add_markers_batch, and engine_* tools that break the pattern. The mix of conventions creates confusion.
Tool Count2/5With 166 tools, the set is excessively large for a typical MCP server. While a DAW is complex, many tools are specialized or redundant, overwhelming an agent. A leaner set would improve coherence and usability.
Completeness4/5The server covers a broad range of DAW operations, including project, track, item, MIDI, audio, mixing, routing, and export. Minor gaps exist (e.g., no direct audio recording sequence), but overall it is comprehensive for music production tasks.
Average 3.9/5 across 166 of 166 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 9 of 9 community issues answered or closed in the last 6 months
- 101 commits in the last 12 weeks
- Last stable release on
- 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.
This server has been verified by its author.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'Set send pan' but does not explain what happens if the send does not exist, whether the operation is reversible, or any side effects on existing settings. This lack of detail is critical for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
While very short (one sentence plus an Args list), the description is under-specified for a tool with three required parameters. Conciseness should not come at the cost of clarity; here it omits essential context about the tool's purpose and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and the presence of three required parameters, the description is incomplete. It does not explain what a 'send' is in this audio production context, how track_index and send_index relate, or what the pan value does acoustically. This leaves the agent guessing about the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. The 'Args' section barely improves on the schema: 'track_index: Source track' and 'send_index: Send index' are tautologies. Only 'pan: -1.0 to 1.0' adds value by specifying the range. The description does not explain what these parameters mean in context (e.g., track indexing, send creation order).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set send pan' states a specific verb and resource, but it essentially repeats the tool name without adding context. Among siblings like send_create and send_remove, it distinguishes itself only by name, not by clarifying what a 'send pan' is or how it differs from other send modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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., send_set_volume or send_set_mute). There is no mention of prerequisites, such as the send needing to exist first, or typical use cases like balancing stereo sends.
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 'move,' indicating mutation, but provides no details about side effects, performance, or index conventions (e.g., 1-based vs 0-based).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, with no extraneous information. However, it could be slightly more structured with a note for each parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description lacks essential context such as indexing conventions, what happens if tracks are invalid, or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description merely repeats parameter names ('Item index', 'Destination track index') without adding meaning. No context on valid ranges or types are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move item to different track,' which is a specific verb and resource. It distinguishes from siblings like 'item_move' by specifying 'to track,' but does not explicitly differentiate from other item movement 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/5Does 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., item_move). No mention of prerequisites, such as track existence or item validity.
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 are absent, so the description must disclose behavior. It only says 'Delete a note' without describing what happens if the note doesn't exist, reversibility, side effects, or any constraints. 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus parameter list), which is concise. However, the minimal content sacrifices clarity. It is front-loaded with the purpose but lacks necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation, the description is partially complete but lacks behavioral context (e.g., return value, error handling). With no output schema, the user is left uninformed about the result of the deletion.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description only lists parameter names without adding meaning. For example, 'item_index' and 'note_index' are not explained (e.g., how to obtain them, valid ranges). The description adds no value beyond the schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Delete a note' clearly states the verb (delete) and resource (a note). It is straightforward, but it does not distinguish from sibling tools like midi_delete_all_notes or midi_delete_cc, leaving potential 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. There is no information on when to use this tool versus alternatives, no prerequisites, and no exclusions. The description merely states the action.
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 behavioral traits such as whether it adjusts enclosed notes, if it's destructive, or any constraints on the values. 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and includes a list of arguments. It is appropriately sized for a simple tool but missing critical details. Loses points for lacking depth, but is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description is insufficient. It does not cover return value, side effects, or constraints. For a tool that modifies item boundaries, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description only labels parameters without adding meaningful semantics. It mentions quarter notes but does not explain valid ranges, interpretation, or relationship between parameters. Minimal value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sets MIDI item boundaries in quarter notes. Verb 'Set' and resource 'MIDI item boundaries' are specific. Distinguishes from sibling tools that deal with notes or 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/5Does 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 item_set_length or other MIDI tools. 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Sort MIDI events by time' without disclosing behavioral traits such as whether the sort is in-place, ascending or descending, if it affects all events or selected ones, or any side effects like undo impact. This is insufficient for an agent to understand 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus an args list) and front-loaded with the core purpose. However, it sacrifices necessary detail for brevity, making it marginally acceptable. It could be restructured to include more information without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and only one parameter with no schema description, the description is incomplete. It fails to explain what 'sort by time' means (e.g., ordering, tie-breaking), the return value (if any), or error conditions. For a simple tool, more context is needed for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description repeats the parameter name 'item_index' with the same meaning as the schema ('MIDI item index'), adding no additional semantic value. Schema coverage is 0%, so the description does not compensate with details like valid ranges, examples, or context about what constitutes a valid index.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'sort' and the resource 'MIDI events' along with the sorting criterion 'by time'. It distinguishes itself from sibling MIDI tools like 'midi_quantize' and 'midi_humanize' by specifying the action. However, it does not mention the scope (e.g., all events in the item or selected only) 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., item must exist) or conditions that would make this tool inappropriate. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a state change (starts recording) but lacks details on prerequisites (e.g., armed tracks), side effects (e.g., overwriting existing recordings), or post-conditions. No annotations are present to supplement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
At two words, the description is extremely concise but at the expense of clarity and completeness. It omits essential context, making it under-specified rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), a minimal description might suffice, but the lack of prerequisites, effects on transport state, and relationship to other transport tools makes it incomplete. An agent would need additional context to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100%. The description adds no parameter information, which is acceptable as there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start recording.' clearly indicates the tool initiates a recording process, which is a specific verb and activity. However, it does not specify what exactly is being recorded (e.g., audio on selected tracks) and does not distinguish it from sibling tools like transport_play or transport_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Sibling tools include transport_play, transport_stop, and others, but the description offers no context for selection.
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 behavior. It only states the action without mentioning side effects (e.g., file overwriting, blocking behavior, or project state requirements). Minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the action. However, the 'Args:' section is informal and lacks structured formatting. It is concise but could be more organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or return value description. For an export tool, the description should mention potential side effects, required project state, or that it may take time. The context is incomplete given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should compensate. It lists parameter names and format options but adds little meaning: 'Output file path' is redundant, and format enumeration repeats schema defaults. No constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Render project to audio file,' which is a specific verb and resource. However, it does not differentiate from the sibling tool 'bounce_stems,' which likely also renders audio, missing a chance to clarify unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives. The description does not mention scenarios, prerequisites, or when not to use it. The sibling 'bounce_stems' is not addressed.
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 implies a read operation but fails to mention return format, side effects, or scope of 'sends/receives'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief but lacks a structured layout; it is acceptable but could be more informative without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the presence of many send-related siblings, the description is incomplete; it does not explain what the tool returns or how it integrates with other tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter description 'Track index' adds no value beyond the schema title; it lacks details like valid range, zero-based indexing, or typical values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'sends/receives' on a specific track, which distinguishes it from sibling tools like send_create and send_remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, nor any context about prerequisites 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 are provided, so the description carries the full burden. It only says 'Delete an item' without disclosing destructive nature, reversibility, or side effects, leaving the agent uninformed about behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it lacks a clear structure beyond a one-line purpose and a single parameter line. It is concise but may be overly minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, schema descriptions, and output schema, the description is insufficient. It does not explain return values, side effects, or prerequisites, making it incomplete for a deletion operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 'Item index' but does not clarify what the index refers to (e.g., item number within a track or project), which could confuse the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete an item' with a specific verb and resource. It also hints at differentiation by advising to use items_apply for multiple items, but does not elaborate on other related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance to prefer items_apply for batch operations, which is useful context. However, no further when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only says 'Set time selection' without disclosing side effects, error cases, or whether it overwrites existing selection. Lacks any 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line), which is concise but omits necessary details like parameter semantics and behavioral notes. It is appropriate for a simple tool, but slightly too terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 required numeric parameters, no output schema), the description provides the core purpose. However, it fails to cover behavioral transparency (e.g., effect on existing selection), making it incomplete for an agent to understand fully.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description merely repeats parameter names and types ('start seconds', 'end seconds') from the schema, adding no extra meaning about units, ranges, or relationships between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set time selection,' which is a specific verb and resource. It distinguishes from sibling tools like selection_get_time (retrieval) and selection_set_loop (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 selection_get_time or selection_set_loop. No preconditions or use cases mentioned.
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 present, so the description must convey side effects. It states retrieval of data but does not explicitly confirm read-only behavior, permissions, or error conditions. Minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence stating the purpose and a straightforward parameter note. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool returns complex data (FX chain), but the description omits details on output structure, error handling for invalid indices, or behavior when no FX exists. With no output schema, this gap is significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, and the description only reiterates '0-based track index,' which is already evident from the schema. No additional meaning or constraints are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the FX chain for a track, listing the types of information returned (names, enabled, presets, param counts). This is specific and distinguishes it from sibling tools that may manipulate FX or retrieve other data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 fx_get_params or fx_get_preset, leaving the agent without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It states the operation but does not disclose whether the original item is modified or destroyed, what the result is (e.g., two new items), or if any side effects occur. Safety-critical details like destructiveness 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two lines) and avoids unnecessary words. Every sentence contributes meaning. The structure could be improved (e.g., using a list or clearer formatting), but it remains concise and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description should provide more context. It does not explain the outcome of splitting, how to access resulting items, error conditions, or any required state (e.g., item must exist). The completeness is inadequate for a tool that modifies project state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by specifying that 'position' is in seconds. However, schema coverage is 0%, so the description should compensate more fully. It does not clarify index base (0 or 1), valid ranges, or behavior for out-of-bounds values. The added value is minimal but non-zero.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Split item at position', using a verb and resource. It distinguishes from sibling item_* tools (e.g., item_delete, item_move) by specifying a split operation. However, it does not elaborate on what splitting entails (e.g., creates two items), which could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, typical use cases, or exclusions (e.g., cannot split certain item types). The agent receives 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides minimal behavioral disclosure. It does not explain that undo is reversible via redo, whether it affects multiple actions, or if it is destructive. The agent lacks crucial context about the undo stack.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three words), but it sacrifices completeness. A sentence or two more would improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (no parameters, no output schema), the description should at least mention that undo can be called repeatedly or that it uses a history stack. It lacks this context, making it incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description cannot add meaning beyond the schema. Baseline is 4, and the description is minimal but sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it undoes the last action, with a specific verb and resource. However, it does not distinguish from sibling tools like 'project_redo' or clarify the scope of 'last action' (e.g., project-wide vs. track-level).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 'project_redo' or sequential undo behavior. There is no mention of prerequisites or limitations.
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 for behavioral disclosure. It only restates the tool name and does not describe side effects, such as whether it clears prior selections or affects item selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (four words), but it essentially repeats the tool name without adding context or structure. It is under-specified rather than concisely informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless action, the description is minimally adequate. However, it lacks context about its effect on the current selection state (e.g., whether it deselects items) and its relationship to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is effectively 100%. The description adds no parameter information, which is acceptable given there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (select) and resource (all tracks), but does not differentiate from sibling tools like selection_select_all_items or selection_deselect_all_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/5Does 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 when to select all tracks versus selecting items or deselecting tracks.
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 'Set loop points' and parameter units, but does not disclose side effects (e.g., whether it clears any existing loop, if it affects playback, or any constraints like start < end).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (3 short sentences) and front-loaded. However, it may be too brief, lacking context that could be added without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete. It does not define what loop points are, how they relate to time selection, or any behavioral details necessary for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds minimal meaning: it clarifies that both parameters are in seconds. However, it does not specify valid ranges, constraints, or behavior when values are out of bounds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The name 'selection_set_loop' and description 'Set loop points' clearly indicate the tool sets loop points. Among siblings like 'selection_set_time', this is distinct as it specifically targets loop points, not time selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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., 'selection_set_time' or 'transport_set_position'). No prerequisites, conditions, or exclusions mentioned.
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 'Start playback.' It fails to disclose whether the tool is idempotent, resumes from pause, or has any side effects. Insufficient for behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, front-loaded with the core action. While it could add more context without losing conciseness, it achieves its minimal goal efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and no output schema, the description is too sparse. It omits crucial context like how it interacts with the transport state (e.g., does it toggle? resume from pause?), leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description adds no value beyond the schema, but baseline 3 is appropriate given zero parameters. No parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start playback.' clearly indicates the verb (start) and resource (playback), making the tool's purpose obvious. However, it does not differentiate from sibling tools like transport_pause or transport_record, but the name itself already implies 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/5Does 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 transport_pause, transport_toggle_repeat, or transport_stop. The agent receives 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states action without disclosing side effects, error behavior, or state changes. For a mutation tool (loading a preset), 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one-line action then three parameter descriptions. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has 3 required parameters, no output schema, no annotations. Description omits return value, error states, and interaction with other fx tools. Incomplete for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds '0-based' for track_index and fx_index, which is helpful. However, no further detail on preset_name format or allowed values. Minimal extra beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Load preset by name', with clear verb 'Load' and resource 'preset'. Differentiates from siblings like fx_get_preset and fx_navigate_preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., fx_get_preset or fx_navigate_preset). No context about prerequisites 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?
With no annotations, the description must disclose all behavioral traits. It only states the basic action and return value, but omits side effects (e.g., whether the new take becomes active), error conditions (e.g., invalid item_index), or any other behavioral characteristics beyond the minimal operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences) and front-loaded with the action. However, it is so brief that it sacrifices useful structure such as examples or a note on return value format. It earns its place but could be expanded without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the presence of many sibling tools, the description lacks completeness. It does not clarify that this tool applies only to items supporting takes (e.g., audio items), nor does it explain the return value's format or error handling. An agent would need additional context to use it safely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'item_index' is described as 'Global item index', adding slight context beyond the schema's title and type. However, no further meaning is provided (e.g., zero-based vs one-based, range of valid indices, or relationship to other item tools). With 100% schema coverage of the parameter name but 0% description coverage, the description adds minimal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a new empty take to an item') and the resource ('item'), and specifies the return value ('Returns the new take's index'). It distinguishes from sibling take manipulation tools like item_take_delete_active, item_take_list, and item_take_set_active.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 or when not to. There is no mention of prerequisites (e.g., item must exist), no alternatives suggested, and no context that might help an agent choose between this and other take-related 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, so the description must bear full responsibility. It only states 'Remove a send' without mentioning error handling, side effects, or what happens if indices are invalid. More behavioral 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, which is appropriate for a simple operation, but it lacks structure (e.g., no summary sentence, just a direct restatement). It could be more informative without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and two required parameters, the description should explain how to obtain valid indices (e.g., via send_get_all) or return values. It does not, leaving the agent without full context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds minimal meaning: it labels track_index as 'Source track index' and send_index as 'Send index'. This clarifies which index refers to what, but offers no extra details like valid ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Remove' and the resource 'send', making the tool's action unambiguous. It effectively distinguishes from sibling tools like send_create (add) and send_get_all (list).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any context about prerequisites or when not to use it. The description is purely operational.
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 present, so the description must fully convey behavioral traits. It only states the action and parameter meanings, omitting details about potential side effects, required permissions, or error conditions (e.g., invalid track/send 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at four lines, with the action stated first and parameters listed clearly. It is appropriately sized for a simple setter tool, though a bit more context would not hurt.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description does not explain return values, error handling, or side effects. This leaves the agent underinformed for a tool in a complex environment with many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the bare schema by explaining that track_index is the source track, send_index is the send index, and volume_db is in dB with 0 as unity. 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Set send volume,' which is a specific verb+resource combination. It clearly distinguishes from sibling tools like send_set_mute and send_set_pan, which cover different aspects of send configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. The description does not mention alternatives or prerequisites, leaving the agent without context for selecting 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, the description must disclose behavioral traits. It only states 'Rename a track,' which implies a mutation, but lacks details on side effects, prerequisites (e.g., track must exist), or safety. The description is insufficient for an agent to understand the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two lines of prose and a clear argument list. Every word earns its place, and the structure 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple rename tool with two parameters, the description is nearly adequate. It clarifies the arguments but lacks usage guidance and behavioral context. Given the absence of annotations, it leaves gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value by specifying that track_index is 0-based, which is not in the schema. However, for the name parameter, it only says 'New name,' which adds minimal meaning beyond the field name. Given 0% schema coverage, the description partially compensates but could be more precise.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does 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 'track,' effectively distinguishing it from sibling tools like track_create or track_delete. However, it could be more explicit about whether it renames the track in the project or elsewhere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 whether it should be used instead of creating a new track with a different name. The context signals show many track-related siblings, but the description offers no context for selection.
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 explains the direction parameter but does not mention side effects, boundary behavior, or if the operation is reversible. The minimal description fails to convey 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise; the purpose is front-loaded in a single sentence, followed by param details. No unnecessary words, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is bare minimum. It does not mention return values, error handling, or behavior with invalid indices, leaving gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description carries the burden. It adds meaning: track_index and fx_index are 0-based, direction values are denoted (1=next, -1=previous). This significantly aids understanding beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool steps to next/previous preset, using a specific verb and resource. It distinguishes among FX tools (e.g., from fx_set_preset which sets a specific preset) but does not explicitly mention 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/5Does 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 fx_set_preset. Lacks context on prerequisites 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?
Without any annotations, the description carries the full burden. It only states the action and lists arguments, but does not disclose important behavioral traits such as whether the file must exist, whether existing items are replaced, snapping behavior, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence plus a minimal argument list. Every element is necessary and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is incomplete. It does not explain the return value, error handling (e.g., invalid path, non-existent track), or whether the operation is destructive. The three parameters are barely explained, missing details like validation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides brief explanations for each parameter ('Target track index', 'Absolute file path', 'Insert position in seconds') which adds meaning beyond the schema names. However, it does not specify units for track_index (0-based vs 1-based) or that position defaults to 0, leaving room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Insert audio/MIDI file into track') and the resource ('track'). It distinguishes itself from sibling tools like item_create_midi (which creates MIDI items from scratch) and load_loops (which loads loops into a library) by specifying file insertion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 item_create_midi or load_loops. There are no prerequisites, restrictions, or suggestions about 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, and the description only states the basic action. It does not disclose what happens if the marker number is invalid, whether the cursor movement is animated, or if it affects playback. The behavioral footprint is under-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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two sentences. The key information is front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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, no output schema), the description is minimally adequate. However, it lacks information about error handling (e.g., if marker number is out of range) and whether the tool scrolls the view. For a navigation command, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter `marker_number` has schema coverage 0%, but the description adds '1-based marker number', which clarifies indexing beyond the schema's type-only specification. This provides essential semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it moves the cursor to a marker, which is a specific action on a specific resource. It distinguishes from sibling tools like marker_add or marker_delete, though it doesn't explicitly differentiate from marker_get_all or transport_set_position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 transport_set_position or marker_get_all. No context about prerequisites or common 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, and the description only says 'Delete a CC event.' It does not disclose side effects (e.g., what happens to surrounding events), error behavior (e.g., invalid index), or whether the operation is reversible. This 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one line for the action and two argument descriptions. No redundant information. Could be slightly more structured (e.g., separate lines), but effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation (delete a CC event by two integer indices), the description covers the essential purpose and parameter meaning. However, it lacks details on valid index ranges, error handling, or impact on other data, which might be needed for robust agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must add meaning. It labels item_index as 'MIDI item index' and cc_index as 'CC event index', which adds context beyond the schema's type and title. However, this is minimal additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a CC event.' with a specific verb (delete) and resource (CC event), distinguishing it from siblings like midi_insert_cc. This is 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 Guidelines2/5Does 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 versus alternatives (e.g., midi_delete_all_notes, midi_delete_note), nor any prerequisites or recommended 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 description only says 'Delete a track' without disclosing side effects like deletion of items, automation, or undo behavior. No annotations are available to supplement, so the agent gets minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no unnecessary words. The purpose and parameter are front-loaded in two short lines.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should explain return values or success indicators. It fails to provide completeness for a simple but destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds '0-based track index', which is not in the schema, providing useful semantics. However, it does not explain valid ranges or error handling for out-of-bounds indices.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'track', distinguishing it from sibling tools like track_create or track_rename which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, such as prerequisites (e.g., track must exist) or warnings about irreversible nature. The description lacks any contextual usage hints.
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 'Set cursor position.' It does not disclose whether playback continues, pauses, or if the cursor movement is instant. This is insufficient for an agent to understand 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with only two lines, front-loading the action. Every sentence is necessary and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, low parameter description coverage, and no annotations, the tool description is too minimal. It omits important details such as whether the tool works during playback or recording, and what the expected behavior is when setting an out-of-range position.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds 'Position in seconds' to the seconds parameter, providing meaning beyond the schema's type and title. However, it does not clarify allowed range or format (e.g., floating-point, negative values).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the cursor position, using the verb 'Set' and the resource 'cursor position'. It distinguishes from sibling tools like transport_play and transport_stop, which control playback state, not 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/5Does 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 transport_play or transport_get_state. The description lacks context like 'use this to jump to a specific time' or comparison with other transport 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, so the description must fully disclose behavioral traits. It only states 'toggle repeat/loop mode' without explaining what the initial state is, whether the toggle is momentary or persistent, or any side effects. This is insufficient for an agent to understand 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.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. It fails to provide any additional context or detail that might help the agent, making it minimally adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is very sparse. For a simple toggle tool, it could include details like 'toggles the repeat/loop state of the transport' or note if it affects playback. The current text is incomplete for an agent to fully understand the tool's function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the input schema provides no meaningful information. The description adds value by clarifying the action (toggle), which is not explicitly stated in the schema. With zero parameters, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'toggle' and clearly identifies the resource 'repeat/loop mode'. The sibling tools list includes no other tool with similar functionality, so it uniquely distinguishes itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no context about its relationship to other transport tools like transport_play or transport_toggle_metronome, leaving the agent uninformed about appropriate usage scenarios.
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 of disclosure. It does not mention idempotency, maximum batch size, error behavior, or whether existing markers/regions are overwritten. This lack of behavioral context is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear header and structured args section. It is front-loaded and efficient, but could be slightly better organized (e.g., separating markers and regions more clearly).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately explains input format but lacks information about output (e.g., return values), error handling, and operational constraints (e.g., whether positions must be within project timeline). Given the tool's complexity, more context is needed for safe use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% coverage, but the description provides a detailed specification of the JSON array format, including examples for markers and regions, and optional color field. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Batch add markers/regions', indicating it adds multiple markers and regions at once, which distinguishes it from single-add tools like marker_add and marker_add_region. The purpose is specific and resource-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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., marker_add for single markers, marker_add_region for single regions). No explicit context or exclusion criteria 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 must carry behavioral info. It only states basic select/deselect action, missing details on side effects, scope (e.g., current track?), or visual feedback.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and clear with bullet-point style for parameters. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple selection tool, but lacks context on return value, error handling, and scope. With many sibling selection tools, more context would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description explains each parameter ('item_index: Item index.', 'selected: True=select.', 'exclusive: Deselect others first.'), adding meaning beyond the schema titles despite 0% coverage metric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Select/deselect an item.' It identifies the action and resource, and from sibling names, it's distinct from mass selection or deselection 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives like selection_select_all_items or selection_deselect_all_items. Usage is implied but not clarified.
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 does not disclose behavioral traits such as side effects, error conditions, or whether the operation is destructive. The agent is left uninformed about what happens after the region is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences for purpose and guidance, followed by a list of parameter definitions. Every part carries weight, with no redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, required start and end, and no output schema or annotations, the description is insufficient. It lacks details on return values, error handling, and what constitutes a valid region addition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by specifying units for start and end (seconds), ranges for color values (0-255), and a label for name. This compensates for the schema's lack of descriptions (0% coverage).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action (Add region) and includes a helpful sibling differentiation by recommending add_markers_batch for multiple operations. However, it does not define what a 'region' is in this context, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a single usage guideline: 'Prefer add_markers_batch for multiple.' This is useful for one scenario but lacks broader guidance on when to use this tool versus other marker-related tools, or context around 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?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, error handling, or side effects. The term 'count' implies a read operation but 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single-line purpose followed by parameter listing. It is front-loaded and contains no redundant information, earning its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple with one parameter and no output schema, the description lacks details about the return value format and what constitutes a valid 'item'. 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameter descriptions (0% coverage), so the description adds 'MIDI item index' for the item_index parameter, which provides minimal meaning. It does not explain acceptable ranges or default behavior, leaving room for ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool counts notes, CCs, and sysex events in a MIDI item, using a specific verb 'count' and resource, which distinguishes it from sibling tools like midi_get_notes or midi_insert_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites or contraindications. The description merely states what it does without contextual usage advice.
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 only states the basic action without detailing effects on multiple takes, invalid indices, or whether it's reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words, but lacks structure like bullet points or sections; it is front-loaded with the action but the parameter description is inline.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 insufficient: it doesn't clarify indexing (0-based?), behavior on invalid indices, or which take is affected when multiple exist.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds semantic meaning by explaining item_index as 'MIDI item index', 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action ('Clear all notes') and the resource ('MIDI item') clearly, distinguishing it from siblings like midi_delete_note which deletes individual 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/5Does 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 midi_delete_note or midi_select_notes. The description does not provide context for appropriate usage 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 carries the full burden. It does not disclose that this is a read-only operation with no side effects. The behavior is implied by the name, but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and immediately conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is somewhat complete. However, it could mention the return type (text) or that it retrieves existing notes. The lack of output schema detail reduces completeness slightly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds no additional meaning beyond the schema, which is empty. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the project notes/description text' uses a clear verb 'Get' and specifies the resource 'project notes/description'. It distinguishes from the sibling 'project_set_notes', which is for setting 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/5Does 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 is minimal and does not provide any context about when to retrieve notes, e.g., before editing or after changes.
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 should disclose behavioral traits. It only mentions a 100 KB limit but not whether notes are overwritten, if the operation is reversible, or any side effects. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence and an argument list. No extraneous content; front-loads the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 no output schema, the description covers the basics but omits behavior details like overwriting or persistence. 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description must compensate. It adds a valuable constraint (max 100 KB) not in the schema, but lacks details on formatting or allowed characters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'project notes/description text'. It effectively distinguishes from the sibling 'project_get_notes' and other project tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 project_new or project_save. Only a size limit is mentioned, but no context on selection criteria.
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 is responsible for behavioral disclosure. It only states 'Create new track' without detailing side effects, requirements (e.g., open project), or what happens on success/failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no superfluous text. Uses a clear argument list format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple creation tool, the description provides minimal but functional completeness. Missing details on return value, project context, or error handling, but adequate given tool simplicity and no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must complement. It explains index as 'Insert position (-1 = end)' and name as 'Optional track name', adding meaning beyond types. However, lacks details like constraints or behavior for invalid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create new track' is direct and specific, clearly stating the verb and resource. It effectively distinguishes from sibling tools like track_delete, track_rename, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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., track_template_apply, item_create_midi). No exclusions or prerequisites mentioned.
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, and description only says 'Delete' without additional behavioral traits like irreversibility, permissions, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences total, no redundant information. Structure is front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter) and lack of annotations or output schema, the description is minimally adequate but misses details like error handling or confirmations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds 'Template name to delete' which clarifies the parameter's purpose beyond the schema's title. However, no format or constraints are specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states clearly 'Delete a saved track template' with verb and resource, and distinguishes from sibling tools like track_template_save and track_template_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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, nor mentions prerequisites or consequences. 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only says 'Bypass', which implies a state change but doesn't clarify if it toggles, what happens to the plugin's state, or if there are side effects (e.g., automation, undo). Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a clear header and bulleted arguments. No redundant text, but could include more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description provides basic info but omits what 'bypass' means precisely (e.g., temporary/permanent, effect on output). No output schema, but return value is likely void. Lacks completeness for an agent to fully understand behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds meaning by noting '0-based track index' and '0-based FX chain index', clarifying indexing which the schema omitted. This compensates well for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Bypass an FX plugin' with a specific verb and resource. Among siblings like fx_enable, fx_remove, etc., this uniquely identifies the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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., fx_enable for unbypass, fx_remove for deletion). No prerequisites or context about when bypassing 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?
No annotations provided. Description only states 'remove' without disclosing destructive nature, reversibility, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one action sentence plus parameter docs. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple removal tool with no output schema or annotations, the description covers the core purpose and parameters adequately.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds basic semantics: '0-based track index' and '0-based FX chain index', which is not in schema. However, it could be more precise about indexing context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Remove FX from track chain' with specific verb and resource. It distinguishes from sibling tools like fx_add, fx_disable, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., fx_disable vs fx_remove). 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 are provided, so the description carries the full burden. It only states the basic action without disclosing any side effects, constraints, or behavior beyond 'move.' There is no information on what happens to the original position, ripple editing, or error conditions. This lack of transparency is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences and an 'Args' list. However, the 'Args' list lacks types and further explanation, making it less structured than ideal. The main purpose is front-loaded, earning a high conciseness score but with a slight deduction for the minimal parameter documentation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 lack of output schema and annotations, the description fails to provide complete context. It does not mention return values, error conditions, or prerequisites (e.g., which item to move). The agent is left with insufficient information for robust invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning beyond the parameter names. The 'Args' section simply repeats the names ('item_index', 'new_position') without explaining what they represent (e.g., index from which list, unit of new_position). This fails to bridge the gap left by 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move item to new position,' which is a specific verb and resource. It also distinguishes from a sibling tool by advising 'Prefer items_apply for multiple.' This effective differentiation earns a high score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to prefer an alternative tool ('Prefer items_apply for multiple'), providing clear context on when to use this tool versus another. This is direct and helpful for the agent.
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 burden of behavioral disclosure. It does not state side effects (e.g., closing current project), error handling, or state changes beyond opening the file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no extra words. Two sentences plus Args section provide the essential information efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description is insufficient. It fails to explain return values, errors, or how this tool fits into a workflow (e.g., using it before other operations).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'path' is explained as 'Absolute path to .rpp file.' which adds meaningful context beyond the schema's 'string' type. This clarifies the required absolute path and file extension, compensating for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Open .rpp project file.' which is a specific verb (open) and resource (.rpp file). This distinctively sets it apart from sibling tools like project_new or project_save.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention prerequisites, when not to use it, or refer to sibling tools like project_new or project_get_info.
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 only states the action without detailing behavior like what happens if already enabled, error conditions, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, front-loaded with purpose, and 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose and parameter meaning but lacks usage guidance, behavioral details, and error handling. Adequate for a simple tool but not fully complete given missing annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds an 'Args' section explaining the 0-based indexing for both parameters, which compensates significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Enable an FX plugin' with specific verb and resource. Distinguishes from siblings like fx_disable and fx_add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 (e.g., fx_disable) or prerequisites like plugin existence or current 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 provided, and the description does not disclose any behavioral traits such as side effects on other FX positions, destruction, or authorization 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple move operation, but lacks context about index bounds, whether the FX must exist, and what happens to remaining FX positions. No return value described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to all three parameters (track_index, fx_index, new_index) beyond the schema's type/title, explaining they are indices and 0-based for track. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Move FX to different position in chain' with a specific verb and resource, distinguishing it from siblings like fx_add or fx_remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 fx_enable/fx_disable or fx_rename. No exclusions 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits such as whether the UI window is blocking, what happens if the FX has no GUI, or any side effects. With no annotations provided, the description carries the full burden of transparency but falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no redundant text. It front-loads the core action and lists arguments clearly. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 omits important context such as the return value (if any), error conditions, or whether the UI opens immediately. Given the simple nature of the tool, this is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains both parameters ('0-based track index', '0-based FX chain index'), adding meaning beyond the schema which only declares types. This compensates for the 0% schema description coverage, though more detail (e.g., where to find these indices) would improve it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Open') and the resource ('FX plugin UI window'), and the args specify the track and FX indices. This distinguishes it from sibling tools like fx_add or fx_remove which perform different actions on FX.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives (e.g., when would an agent choose this over fx_get_params or fx_set_preset). No prerequisites or context for invocation are mentioned.
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 side effects like undo handling, selection changes, or error behavior (e.g., invalid track_index). More context is needed 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one-line summary followed by bullet points for parameters. No redundant information, front-loaded purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description specifies the return value (global index) but lacks error handling details or reminders for related operations (e.g., item_delete). Adequate for a simple tool but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds meaningful constraints: track_index is 0-based, position >=0, length >0, and units are seconds. This adds value beyond the schema defaults and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create an empty MIDI item on a track' with a specific verb and resource. It distinguishes from siblings like item_insert_media and item_get_all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. Siblings like item_insert_media offer related functionality, but no comparison or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 only states it saves and returns confirmation, omitting critical details like whether it overwrites without prompt, if it requires an existing file path, or how it handles unsaved changes. For a destructive action (saving overwrites the file), 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences front-load the essential action and return value. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple save tool with no parameters and no output schema, the description is moderately complete. It states the action and return value, but lacks context on prerequisites (e.g., project must be open and have a file path) and fails to clarify behavior like overwriting or creating backup. This could lead to confusion if the agent uses it on a new, unsaved project.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage. With no params, the description need not add param info, and the baseline of 4 is appropriate. No additional semantic value is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Save the current project' with a specific verb and resource, distinguishing it from siblings like project_save_as (which saves to a new path) and project_new/project_open (which create/open projects).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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., project_save_as or project_export_audio), nor are any prerequisites (e.g., project must be open and have a file path) mentioned.
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 says 'Set grid division' without explaining that it modifies project state, whether it is reversible, or any side effects. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two sentences plus an Args line. Every sentence conveys useful information, and the key info is front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with no output schema, the description is minimally adequate. It covers the core intent but lacks detail on result (e.g., whether it returns success) or any required preconditions. Lags behind the completeness needed for higher confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description compensates by explaining that grid_division is 'Grid size in quarter notes' and giving example values. This adds meaning beyond the schema's bare type definition, though a range or validation hint would improve clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Set grid division' with concrete examples (quarter, eighth, sixteenth), which clearly specifies the action and resource. There are no sibling tools with similar purpose, so differentiation is not needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool or when to avoid it. No mention of alternatives or prerequisites (e.g., whether project must be open). 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions the core action but discloses no behavioral traits such as whether it also deselects items, whether it can be undone, or any side effects. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single, clear sentence that is front-loaded. Every word serves a purpose with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, parameterless tool the description is minimally adequate but lacks context about interaction with other selection states or effects on the project. Some additional clarity would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema provides no additional info. The description adds the meaning of the action, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (deselect) and the target (all tracks), which is specific and distinguishes from siblings like 'selection_deselect_all_items' by specifying '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/5Does 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 'selection_select_all_tracks' or 'selection_deselect_all_items'. The description only states the action 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, and the description fails to disclose important behavioral details such as whether selecting all items replaces or adds to the current selection. This omission could lead to misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (3 words), but it sacrifices important contextual information. It could benefit from a brief note on selection behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple action with no parameters or output schema, the description is minimally adequate. However, it lacks clarity on the selection mode (replace vs. add), which is essential for correct invocation among sibling selection tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the description does not need to add parameter details. The baseline for no-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Select all items' uses a specific verb ('Select') and resource ('all items'), clearly differentiating it from siblings like 'selection_deselect_all_items' and 'item_select'. 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (when you want to select all items) but provides no explicit guidance on when to use this tool versus alternatives like 'item_select' or 'selection_deselect_all_items'. No context-specific recommendations.
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 the function, but fails to mention side effects, persistence, or impact on playback.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with parameters explained in a structured list. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with two parameters and no output schema, the description is adequate. It covers the essential information needed to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema types: track_index as '0-based track index' and mute as 'True=mute, False=unmute'. This helps the agent understand the parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Mute/unmute a track', using a specific verb and resource. It distinguishes itself from sibling tools like item_set_mute and send_set_mute by focusing on 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/5Does 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 muting options, nor any prerequisites or context. The description only explains parameters.
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 but only states 'Toggle pause' without explaining behavior (e.g., effect on current playback state, idempotence, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two words with no redundancy; maximally concise for a simple toggle action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle with no output schema, the description covers the core action but lacks contextual completeness, e.g., no mention of its effect on transport state or relation to other transport tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. The description sufficiently adds meaning by specifying the action, which is adequate for a zero-parameter toggle tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Toggle pause' clearly states the action (toggle) and resource (pause), distinguishing it from siblings like transport_play and transport_stop.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 transport_play or transport_stop, nor any context about preconditions or typical workflows.
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?
Without annotations, the description carries the full burden but only states the basic action and parameter range (20-999). It does not disclose side effects, whether changes apply immediately, or impact on playback.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence plus an argument listing. However, it could benefit from a slightly more structured format (e.g., separate sections for behavior and constraints).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the core function and parameter constraints. However, it omits behavioral details like whether the tempo change affects current playback or requires stopping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 adding the valid range '20-999' for the BPM parameter, which is absent in the schema. This adds meaningful context beyond the raw type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set project tempo', which is a specific verb+resource combination. It distinguishes from sibling tools like detect_common_bpm (detection) and tempo_add_marker (marker-based tempo).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 tempo markers or detection. The description lacks context such as prerequisites 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 are provided, so the description must cover behavioral traits. It only states the basic action without disclosing side effects, reversibility, or what happens if already muted. This 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two lines plus a short arg list. It front-loads the main action and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (2 params, no output schema), the description covers the basics but misses details like index base (0 or 1) and error handling. 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.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description's parameter explanations are minimal: 'item_index: Item index' is vague, and 'mute: True=mute' is obvious. It barely adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Mute/unmute item' with a specific verb and resource. It distinguishes from the sibling tool 'items_apply' by advising to prefer it for multiple items.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Prefer items_apply for multiple,' providing an alternative for batch operations. However, it does not explicitly state when not to use this tool, 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.
- 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 the action without mentioning side effects, prerequisites (e.g., item must have multiple takes), or safety. The description lacks sufficient behavioral context 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a purpose sentence followed by parameter details. It is front-loaded and avoids unnecessary words. However, formatting the parameters as a list would improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description adequately covers the action and parameter semantics. However, it omits behavioral details (e.g., what happens if take_index is invalid) and does not mention return values, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the description adds clear parameter meanings: 'item_index: Global item index' and 'take_index: 0-based take index (from item_take_list).' This significantly aids understanding beyond the schema's bare property titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Switch which take plays back on an item.' It uses a specific verb and resource, and distinguishes from sibling tools like item_take_list (list takes) and item_take_add (add takes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for changing the active take but provides no explicit when-to-use or when-not-to-use guidance, nor mentions alternatives. Without stating prerequisites or exclusion criteria, the agent may misuse it (e.g., on items with a single take).
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 merely restates the tool name without disclosing behavior when there is nothing to redo or other 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise at 4 words, but lacks additional context that could be helpful without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides the core functionality but omits edge cases (e.g., no undo history) which would be useful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; baseline of 4 as per guidelines for 0-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Redo last undone action', which is specific and directly distinguishes it from the sibling 'project_undo' and 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or alternatives, but the purpose is implied through the context of undo/redo.
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 correctly implies a read-only operation but does not specify performance implications, output format, or any potential side effects. Minimally 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no wasted words. Clearly conveys the tool's purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite zero parameters, the description fails to describe the output format or structure of the 'routing diagram.' Without an output schema, this information is essential for proper use. Leaving the agent guessing about the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, and schema coverage is 100% (none). Baseline score of 4 is appropriate as description does not need to elaborate on parameters, but the empty schema is clearly communicated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the full project routing diagram including sends, receives, and outputs. It distinguishes itself from sibling tools like send_get_all by indicating a comprehensive 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/5Does 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 send_get_all or track_get_all. No mention of prerequisites or context where it is most useful.
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?
Minimal description without annotations. Does not disclose what happens if send doesn't exist, whether operation is idempotent, or any side effects beyond setting mute.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: 5 lines with clear arg list. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Nearly complete for a simple boolean setter with 3 required params. Lacks error handling details, but sufficient for basic use. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: explains 'mute: True=mute' and identifies parameters as 'Source track' and 'Send index'. Could be more precise (e.g., indexing convention) but clarifies basic intent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Mute/unmute send.' with specific verb and resource. Among sibling tools like send_set_pan and send_set_volume, it uniquely handles mute 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/5Does 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 (e.g., other send modifications). No prerequisites or context for correct 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?
No annotations are provided, and the description only mentions what information is included ('sample_filenames') but fails to disclose behavioral traits such as whether the operation is read-only, error handling on invalid track_index, or 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loads the purpose, and uses a clear 'Args' format. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should list the fields in 'detailed info', but only mentions 'sample_filenames' and defers to another tool. Missing key return data makes the description incomplete for tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'track_index' as an integer, but the description adds crucial context: '0-based track index'. This clarifies the parameter semantics beyond the schema, which had 0% description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get detailed info for one track' and distinguishes itself from 'track_get_all' by mentioning it includes 'sample_filenames'. It specifies the action and resource, 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description references 'track_get_all' for understanding 'sample_filenames', hinting at an alternative tool, but does not explicitly state when to use this tool versus others, nor 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds that audio items include 'source_file'/'source_filename' and directs to another tool for explanation, offering some behavioral context but no details on return format 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two sentences and a parameter line, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations; the description is vague about what 'detailed info' includes beyond one specific field for audio items. Leaves agent guessing about the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the only parameter description in the tool definition is 'Item index.' which adds minimal value beyond the property name. Should explain how to obtain the index.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get detailed info for one item' with a specific verb and resource, and distinguishes from sibling 'item_get_all' by mentioning it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (to get one item's info) and references sibling 'item_get_all' for additional context, but does not 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavioral traits. It states 'Set item length' but does not explain what setting the length does (e.g., trim, stretch, or change endpoints), potential side effects (e.g., affecting adjacent items), whether it is destructive, or any authorization needs. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two sentences and a parameter list, front-loading the key action and guidance. However, it omits necessary behavioral details, making it too terse for safe usage. Still, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description leaves significant gaps. It does not explain the effect on the item (e.g., trimming vs stretching), whether the length is absolute or relative, or how errors are handled. For a tool that modifies project state, this is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning by naming the parameters and giving brief definitions: 'item_index: Item index' and 'length: Length in seconds.' While this clarifies the units for length, it does not specify allowed ranges, formats, or behavior for edge cases (e.g., negative length). It is minimally adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Set item length' with a specific verb and resource. It also distinguishes from the sibling item_apply by advising to prefer items_apply for multiple items, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Prefer items_apply for multiple', providing clear guidance on when to use this tool versus the alternative. This helps the agent choose correctly between single and batch 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?
No annotations are provided, and the description fails to disclose critical behavioral traits such as whether notes are appended or overwritten, error handling, or return values, leaving the agent uncertain 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence and an Args list, though the structure could be more formal (e.g., bullet points) for easier parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the sibling tools and lack of output schema, the description omits important context such as return value, behavior regarding existing notes, and prerequisites (e.g., must there be an existing MIDI item?), making it incomplete for confident use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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: track_index as 0-based, item_index as MIDI item index, and notes as a JSON array with a clear example format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Batch-insert notes into a MIDI item' and labels it 'Primary tool for writing MIDI,' which immediately distinguishes it from single-note insertion tools like midi_insert_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch writing MIDI notes, providing clear context, but does not explicitly exclude single-note scenarios or mention 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 partially explains behavior: grid_seconds calculation and strength range. However, it does not disclose side effects (e.g., whether it modifies the item destructively, affects only selected notes, or 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, starting with a clear one-sentence summary, followed by relevant math and parameter details. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While it covers purpose and parameter details, it lacks behavioral context (e.g., reversibility, scope of quantization) and does not differentiate from sibling tools like midi_humanize. Given no output schema, completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 provides grid math for grid_seconds, strength range (0 to 1), and clarifies item_index as a global item index. This adds significant context beyond the schema's titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Quantize') and resource ('notes in a MIDI item to a time grid'). It distinguishes itself from sibling tools like midi_humanize or midi_sort by specifying grid quantization.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 midi_humanize or when not to use it. The description lacks explicit context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 that -1 keeps the current value, but does not disclose side effects (e.g., whether it auto-updates the item), required permissions, or whether the operation is destructive. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the purpose in the first sentence, followed by a concise Args block. Every sentence serves a purpose, and there is no redundant information. It is appropriately sized for the 7 parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should cover prerequisites and outcomes. It explains parameters well but omits what the tool returns (e.g., success indicator), how to obtain valid indices, and any workflow context. For a MIDI editing tool, this is moderately complete but lacking in overall context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 specifying ranges (pitch 0-127, velocity 1-127, channel 0-15) and the meaning of -1. However, it does not clarify what 'note_index' or 'item_index' refer to, nor whether start/end positions are relative to the item. These gaps prevent a score of 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Edit existing note' clearly states the action and resource, distinguishing it from sibling tools like midi_insert_note (create) and midi_delete_note (delete). The verb 'edit' and resource 'existing note' 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for modifying an existing note, but does not explicitly compare with alternatives like midi_insert_note or midi_delete_note. No when-not-to-use or prerequisite conditions are stated, leaving usage guidance implicit.
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 side effects, but it fails to mention whether creating a new project closes the current one or handles unsaved changes. It also does not specify the format of the returned project info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is 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.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, the description is mostly complete, but it lacks context on how creating a new project affects the existing state (e.g., does it replace the current project?).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema covers everything. The description adds no parameter info, but according to guidelines, 0 parameters gives a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'a new empty REAPER project', differentiating it from sibling tools like project_open (load existing) and project_save (save current).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It indicates when to use the tool (to create a new project), but does not explicitly mention when not to use it or provide 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.
- Behavior2/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 function but does not disclose potential side effects, undo behavior, or whether it affects other tracks. Minimal behavioral context beyond the 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and to the point, listing purpose then parameter details. Could be slightly improved with bullet formatting, but overall efficient with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two integer parameters and no output schema, the description covers the essential information: what it does, parameter meanings, and value semantics. However, it could elaborate on the effect of setting a track as folder parent or last in folder.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with only titles and types; description adds meaning by specifying that track_index is 0-based and folder_depth is the folder state value. This significantly 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/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sets folder state and explains the meaning of each value (0=normal, 1=folder parent, -1=last in folder). This specificity distinguishes it from sibling track manipulation 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use this tool versus alternatives. Usage is implied by the context of track folder management, but no exclusions 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?
The description states the basic effect but does not disclose error handling, side effects, or behavior when the track index is invalid or recording is in progress.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, with two sentences that efficiently convey all essential information without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema, the description is sufficient but minimal; it omits potential context like valid track index range or recording state implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning by explaining track_index as 0-based and arm values as True=arm, False=disarm, compensating for the schema lack.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Arm/disarm track for recording' uses a specific verb and resource, clearly distinguishing this tool from sibling tools like track_set_mute or transport_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 prerequisites (e.g., track existence) or conditions for arming/disarming.
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 fully disclose behavioral traits. It only mentions the action 'solo/unsolo a track' without details on side effects, error conditions, or impact on other tracks. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with no wasted words. It uses a clear header and numbered list for arguments, making it easy to parse. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the core action and parameter meanings. It could mention error handling (e.g., invalid track index) but is still reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema: 'track_index: 0-based track index' clarifies the integer parameter, and 'solo: True=solo, False=unsolo' explains the boolean. Since schema coverage is 0%, this is essential and well-done.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Solo/unsolo a track' clearly states the action (solo/unsolo) and the target (a track). It effectively distinguishes this tool from siblings, as no other tool in the family addresses solo 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/5Does 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 or what prerequisites exist. It only states the action, leaving the agent without 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?
No annotations are provided, and the description does not disclose what information is returned (e.g., names, IDs). It only says 'list', which is vague for behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is direct and to the point, with no extraneous words. Earns its place efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations. The description is adequate for a simple list operation but leaves the agent guessing about the return format, which is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds no parameter info. Baseline for zero parameters is 4, and the description does not hinder understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all saved track templates, with a specific verb and resource. It distinguishes from sibling tools like track_template_apply and track_template_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when or when-not to use, but the simplicity implies it's for retrieving a list of templates. No alternatives mentioned, but siblings cover other 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?
No annotations are provided, and the description only states 'Set playback speed' without disclosing side effects, reversibility, or whether it affects pitch. The behavioral context is minimal beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two lines, with no wasted words. It is front-loaded with the purpose and immediately provides parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and single parameter, the description is minimally sufficient. However, it lacks information about return values, whether it works during playback or only when stopped, and any potential impact on pitch or other settings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning to the sole parameter 'rate' by specifying a valid range (0.25-4.0) and the default meaning (1.0=normal), which the input schema does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set playback speed' with the verb 'Set' and resource 'playback speed', and provides the rate range. It distinguishes from sibling transport tools which focus on play/pause/record/tempo, not speed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adjusting playback speed, but does not explicitly state when to use it versus alternatives like transport_set_bpm or transport_play, nor does it mention any prerequisites or context (e.g., while playing or stopped).
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 present, so the description carries the full burden. It only says 'Stop playback/recording' without disclosing additional behavioral traits such as whether it stops both simultaneously, if the play cursor moves, or any side effects. This is a basic description lacking 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence. It gets the point across efficiently, though it could provide a bit more context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description is mostly complete. It covers the primary purpose, but could be enhanced by specifying behavior when both playback and recording are active.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description need not add parameter details. The baseline is 4, and the description is clear about the tool's action.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool stops playback or recording, with a clear verb and resource. It distinguishes well from sibling tools like transport_play and transport_record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but does not provide explicit guidance on when to use it versus alternatives. Usage is implied by the name and context, but no when-to-use or when-not-to-use details are 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 accurately reflects the action of toggling, but does not disclose any additional behavioral traits such as whether playback continues, if there is a visible indicator, or any side effects. Since annotations are absent, the description carries the full burden but provides minimal extra 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two words, front-loading the essential action and resource. Every word is necessary, and there is no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle with no parameters and no output schema, the description is minimally adequate. It conveys the core action but lacks details about the effect on the system or any visual/audio feedback. A more complete description could help the agent understand the tool's impact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to add parameter-level meaning. With zero parameters, a baseline of 4 is appropriate per the guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (toggle) and the resource (metronome), making it easy for an agent to understand what the tool does. It distinguishes itself from siblings like transport_play or transport_stop, which handle playback rather than metronome 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, typical use cases, or when toggling the metronome is appropriate, leaving the agent without 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?
No annotations provided, so description carries full burden. It states 'delete' which implies destructive action, but doesn't mention reversibility, side effects, or return value. Adequate but could be more transparent about 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear action sentence followed by parameter list. The parameter list is informative but could be more compact (e.g., combine fx_index/param_index). Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description provides core function and parameter meanings. It misses details on parameter combination (e.g., when to use envelope_name vs fx_index), error conditions, and return value. Functional but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so description must compensate. It adds meaningful constraints (start_time >=0, end_time > start_time) and clarifies fx_index/param_index usage. However, it lacks explanation of envelope_name default and relationship between parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete all envelope points in a time range' using a specific verb ('delete') and resource ('envelope points in a time range'). It distinguishes from siblings like envelope_add_points (add) and envelope_get_points (read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly specify when to use this tool vs alternatives. It implies usage by its action, but lacks explicit context or exclusions. Given siblings, the purpose is clear, but no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only states 'Add marker' without disclosing side effects, return values, or project context (e.g., whether marker is added to current project). Minimal behavioral 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one line for purpose, one line for usage guideline, then a bullet list of arguments. Front-loaded with key info, no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 5 parameters, the description is too sparse. It lacks details on what happens when position overlaps, whether marker is added in the current project timeline, and any constraints or return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description adds meaning: 'position: Seconds' clarifies unit, 'color_r/g/b: Red/Green/Blue 0-255' specifies ranges, and 'name: Label' provides semantic context not in schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Add marker' clearly indicates the action and object. It distinguishes this tool from 'add_markers_batch' for multiple markers, providing specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'Prefer add_markers_batch for multiple', guiding the agent on when to use alternative tool. However, it does not address other marker-related siblings like marker_add_region.
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 only states the basic operation without disclosing side effects, idempotency, or behavior on invalid items. This is 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus parameter explanations. No unnecessary words, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers the core functionality and parameter meaning. Missing edge cases (e.g., invalid item_index) but still fairly complete given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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: 'item_index: MIDI item index' and 'select_all: True=select, False=deselect'. This adds context 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Select/deselect all notes in item', specifying the verb (select/deselect) and resource (all notes in a MIDI item). This distinguishes it from sibling tools like midi_insert_note or midi_get_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for selecting/deselecting all notes but provides no guidance on when to use this tool versus alternatives like midi_select_notes for selective selection. No exclusions 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states it groups tracks into a bus with compression, but does not disclose important behavioral details such as whether original tracks are muted, how routing is set up, or what happens to existing sends. With no annotations provided, the description carries full burden but 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear main sentence, an explanatory paragraph, and a parameter list. It is fairly concise, though the Args section could be integrated with the schema descriptions to reduce redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters and no output schema or annotations, the description explains what the tool does and parameter purposes. However, it lacks information on return values, side effects, or how the bus interacts with existing routing, leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description provides meaningful parameter explanations in an Args section (e.g., source_tracks format, typical ranges for glue_threshold_db and glue_ratio). These add significant value beyond the naked schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Group drum tracks into a dedicated bus with a glue compressor.' It distinguishes itself from sibling tools like setup_parallel_compression by explicitly comparing to a 'lighter-touch version of parallel compression.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it is for 'gentle comp gluing' and controlling the drum group's overall level, with an explicit note that it's different from parallel compression. However, it does not explicitly list when not to use it or name specific 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 provided. Description discloses use of REAPER action 41644 and restoration behavior, but lacks info on whether operation is reversible or has 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus args line. No wasted words, front-loaded with core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one param and no output schema, the description is complete enough. It explains the operation, parameter, and underlying action. Could clarify typical use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter track_index described as '0-based track index', adding specific context beyond the schema's type and title. Schema has no parameter descriptions, so description compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it unfreezes a track and restores original FX chain and MIDI state. Differentiates from sibling track_freeze by being its inverse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or avoid. Does not mention alternatives or prerequisites despite sibling track_freeze existing.
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 automatically filters out junk params, but does not state it is a read-only operation, potential side effects, or behavior on error. The output format is hinted but not detailed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with four sentences: purpose, filtering behavior, and two parameter definitions. No redundant text, and key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers purpose, filtering, and parameter semantics. However, it lacks explicit mention of read-only safety, return format details, and potential edge cases, leaving gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by defining both parameters as 0-based indices. This adds meaning beyond the schema's type/required info, though it could include constraints or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get all parameters') and the resource ('FX plugin'), and specifies the output includes 'names, values, formatted display'. It is distinct from sibling tools like fx_set_param or fx_get_preset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the filtering note, but does not explicitly state when to use this tool versus alternatives or when not to use it. No mention of prerequisites or comparison with other getters.
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 the tool reads preset name and count, implying it is read-only, but does not explicitly disclose safety or side effects beyond the obvious. Minimal but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with the purpose stated in the first line followed by a structured Args section. Every sentence is necessary and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description covers the basic return (preset name and count). However, it could be more explicit about the exact structure of the return value, but it is sufficient for a minimal getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only type and title for parameters, but the description adds that track_index and fx_index are 0-based, which is critical for correct usage. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current preset name and count. The verb 'Get' and resource 'preset' specify the action and target, distinguishing it from sibling tools like fx_set_preset or fx_get_params.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. There is no mention of context, prerequisites, or exclusions. Siblings like fx_navigate_preset or fx_get_chain are not referenced.
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 the action but does not mention side effects (e.g., what happens if only one take remains, or if the item has no takes). The destructive nature is implied but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a brief Args list. Every sentence adds value: the first states the purpose, the second gives usage guidance. It is concise without any filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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, no output schema), the description is adequate but not fully complete. It does not address edge cases or provide details about the outcome, which are important for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (item_index) with no description. The description adds 'Global item index' under Args, clarifying its meaning. However, it lacks details like range or zero-based index. Schema coverage is 0%, so the parameter info in the description is essential but minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete the currently active take from an item', specifying the exact action and resource. It distinguishes from siblings like item_take_set_active and item_take_add.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'To delete a non-active take, first call item_take_set_active on it', providing clear guidance on when and how 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action (delete) without disclosing side effects, behavior on invalid indices, or whether the operation is undoable. This is minimal transparency for a 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences and a bullet for the argument. Every word adds value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple deletion tool with one parameter, the description is mostly adequate. It covers the essential input and usage hint, but lacks safety details and confirmation of return behavior. The tool is straightforward, so completeness is reasonable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter marker_index is documented as 'Index from marker_get_all', which provides meaningful context beyond the schema's type definition. This helps the agent understand the expected value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it deletes a marker or region, and specifies the input as an index from marker_get_all. This distinguishes it from sibling tools like markers_apply for batch operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises to prefer markers_apply for multiple deletions, which gives a clear usage hint. However, it does not explicitly cover when not to use this tool or provide other 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 provided, so description carries the burden. It adds parameter ranges (channel 0-15, pitch 0-127) and clarifies pitch mapping (60=C4). However, it lacks details on prerequisites (item must be MIDI), side effects (overwrites existing?), or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short paragraphs with a clear first sentence and a concise list of arguments. No redundant text; each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 required params and no output schema, the description provides parameter ranges but misses usage context (item existence, failure cases, return value). It is adequate for simple insertion but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, so description adds value by specifying ranges and units (seconds for positions, pitch mapping). But it doesn't explain parameter meaning beyond the name (e.g., velocity impact).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Insert single note), resource (existing item), and distinguishes from compose_arrangement. It contrasts with sibling tool midi_insert_notes_batch, which inserts multiple 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'For composing use compose_arrangement,' providing an alternative usage. However, it does not explicitly compare with other MIDI note tools like midi_insert_notes_batch for multi-note scenarios.
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 for behavioral disclosure. It mentions that MIDI is not deleted, but it does not explain what 'unlock' means, what side effects occur, or whether the action is reversible. This is insufficient for a tool that likely performs a nontrivial 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at two sentences, with no wasted words. The primary action is stated first, and the alternative is clearly signposted, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (0 parameters, no output schema), the description covers the basic behavior. However, it assumes knowledge of 'compose_arrangement' and what 'unlock' entails. An AI agent might benefit from a brief explanation of the context or the nature of the 'locking' mechanism.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema coverage is 100% by default. The description does not need to add parameter information, and it does not detract. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it unlocks compose_arrangement without deleting MIDI. The verb 'unlock' is specific, and it distinguishes from the sibling wipe_all_midi by noting the difference in MIDI handling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly references an alternative tool (wipe_all_midi) for when deletion is desired, providing clear context for when to use this tool versus when not to. However, it does not elaborate on other potential conditions or prerequisites, 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 tool creates a bus atomically but does not detail error conditions, idempotency, side effects, or response format. The parameter descriptions are basic, and behavioral traits like creation validation or overwrite behavior are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a one-sentence summary followed by a clear parameter list. Every line adds value, and the structure (Args:) is standard and easy to parse. No redundant or vague statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters, no annotations, and no output schema, the description adequately covers parameter semantics but lacks behavioral context (errors, return value, side effects). For a tool creating a bus, missing info on idempotency and what happens if bus_name conflicts reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning by explaining each parameter (e.g., fx_chain format reference, sends_from JSON structure, bus_position meaning). This compensates well for the schema gap, though some parameters could benefit from more detail (e.g., bus_color default empty string).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates an effect return bus combining track, FX, and sends in one call. The verb 'Create' is specific, and the resource 'effect return bus' is distinct from sibling tools like setup_fx_chain (only FX) or setup_routing (only routing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks explicit guidance on when to use this tool versus alternatives like setup_drum_bus or setup_fx_chain. No conditions, prerequisites, or exclusions are provided, leaving the agent to infer usage 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?
No annotations are provided, so the description must cover behavioral traits. The description states it creates sends (mutation) but does not disclose side effects, permissions, or error handling. It defines input format but not output 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and to the point, with a clear header and args section. Every word is useful, though it could be slightly more structured (e.g., bullet points for fields).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (batch create sends with optional parameters), the description covers the essential information: what it does and how to format the single required parameter. It lacks return value details, but that is acceptable as no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by detailing the JSON array structure and each field (source_track, dest_track, volume_db, pan). However, it provides only an example, not exhaustive documentation of all possible values or defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Batch create sends' with optional volume/pan, which specifies the action (create sends) and scope (batch). This distinguishes it from single-send tools like send_create.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies batch usage but does not explicitly state when to use this tool vs. alternatives (e.g., send_create for single sends). No exclusions or prerequisites are 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 details the processing chain and bus creation/reuse, but does not mention if the operation is reversible, what happens on error, or performance impact. The description is transparent enough for typical use but lacks edge-case 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured with a summary sentence, a numbered list of processing steps, and a parameter list. While a bit lengthy, each part adds value. Minor redundancy with parameter list duplicates schema info, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no annotations, no output schema), the description covers the main behavior thoroughly: chain order, default EQ/comp settings, bus creation/reuse. Lacks details on return value or conflict handling, but adequate for expected usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds significant context by explaining each parameter's role in the processing chain (e.g., 'HP filter at hp_freq', 'Mud cut: -2dB at 250Hz'). It also mentions default values for several parameters, aiding selection beyond schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a 'one-call vocal-chain setup' with a specific list of processing steps (HP filter, mud cut, presence boost, etc.) and mentions creating a plate reverb bus. This distinguishes it from sibling tools like fx_add or send_create which are lower-level.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It says 'Designed to give a polished broadcast-ready vocal with one call,' implying when to use. However, it does not explicitly state when not to use or contrast with alternatives like manual chain setup or other setup tools (e.g., setup_parallel_compression). Guidance is implied but not explicit.
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 a behavioral limit: sample_filenames is capped at 20 distinct names per track and is empty if no audio items. This adds transparency beyond a simple listing of properties.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences and a note. It front-loads the purpose, then adds necessary detail about sample_filenames. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return includes properties and sample_filenames behavior. However, it does not fully specify the structure (e.g., array of objects) or describe all properties beyond names. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so baseline is 4. The description adds value by detailing the output fields, especially the special sample_filenames field, which compensates for the lack of output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all tracks with specific properties (name, volume, pan, etc.), including a detailed explanation of the sample_filenames field. This directly distinguishes it from siblings like track_get_info (single track) or track_get_mixer_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/5Does 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 track_get_info or track_get_mixer_state. The description implies it is for bulk retrieval, but lacks when-not or context for choice.
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 explains the parameters and the exclusive flag behavior, but it does not disclose potential side effects (e.g., what happens if track_index is out of range, whether the action is undoable, or any impact on 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a bullet-like arg list. Every sentence adds value without redundancy. Properly 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple selection tool, the description covers the basic functionality and parameters. However, it is missing information about return values (likely void) and error behavior. Given no output schema and no annotations, a bit more context about state changes would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (schema has no descriptions), so the description fully compensates by clearly explaining each parameter: track_index as 0-based, selected as True=select, exclusive as Deselect others first. This adds 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.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb-resource pair "Select/deselect a track" and explains how the parameters control behavior. However, it does not explicitly differentiate itself from sibling tools like selection_select_all_tracks or selection_deselect_all_tracks, which also manipulate track selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for selecting or deselecting an individual track by index, but it provides no explicit guidance on when to prefer this over alternatives, such as using selection_get_selected_tracks for reading state or selection_select_all_tracks for bulk actions.
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 meaning of different input_index values and that track_index is 0-based. However, it does not disclose behavioral traits such as whether changes are immediate, reversible, or require 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a brief intro followed by an args section. It is well-structured and front-loaded. Each sentence provides necessary information. Minor waste: the 'Args:' section could be integrated but it's fine.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (2 required params, no output schema, no annotations), the description covers the key aspects: purpose, parameter details, and valid value ranges. It does not explain return values or error conditions, but for a simple setter this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no property descriptions), so the description must compensate. It explains track_index as '0-based track index' and input_index with a detailed mapping (none, mono, stereo, MIDI, MIDI all). This adds significant semantic value beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set recording input.' It provides a detailed mapping of input_index values (0=none, 1-1024=mono, etc.), which distinguishes it from sibling tools that set other track properties like mute or volume.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 (e.g., track_set_record_arm). However, it does provide specific valid input values, which guides usage. No exclusions or when-not-to-use 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?
With no annotations, the description must disclose behavioral traits. It mentions that position -1 keeps current and name None keeps current, but does not state side effects, required permissions, reversibility, or what happens on success/failure. Significant 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: a one-line purpose followed by a clean Arg list. Every sentence adds value, and the structure 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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet the description omits return values or error behavior. For a mutation tool, this is a notable gap. Given no annotations, the description should provide more context about outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description adds essential meaning. It explains position constraints ('>= 0, or -1 to keep current') and the default for name ('None=keep'). However, marker_index lacks detail beyond 'Marker index', which could be improved.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Edit marker/region', specifying the verb and resource. It distinguishes from sibling tools by guiding users to prefer markers_apply for multiple edits or region end/color changes, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises when to use an alternative: 'Prefer markers_apply for multiple, or to also edit a region\'s end/color.' This provides clear context and exclusions, helping the agent decide when to use this tool versus its 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 reveals the tool is read-only and non-destructive (implied by 'get'), but does not disclose any additional behavioral traits such as return format, caching, or error behavior. Since it's a simple mapping, this is minimally sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the tool's purpose and includes a helpful example. It is front-loaded and has no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and a trivial function, the description is complete enough for an agent to understand and use it. It could optionally specify the output structure (e.g., a dictionary), but this is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema description coverage is 100%. The description adds no parameter information because none is needed. Baseline is 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a MIDI note number to name mapping with a concrete example (C4=60). It uses a specific verb 'Get' and resource 'MIDI note number to name mapping', distinguishing it from sibling tools that manipulate MIDI 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for converting note numbers to names when working with MIDI data, but provides no explicit guidance on when to use this tool versus alternatives like midi_get_notes. For such a simple lookup, the purpose is clear enough, but lacking any context or exclusion criteria.
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 does not disclose any behavioral traits beyond the basic purpose. It fails to confirm that it is read-only or describe any side effects, leaving the agent without important 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each serving a distinct purpose: stating the function and providing usage guidance. There is no superfluous information, and it is front-loaded with the tool's primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is largely adequate. It could specify the return format (e.g., start and end times) but is not critically incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description adds no information about output or behavior, but given the zero-parameter case, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'current time selection', clearly stating its purpose. It distinguishes from sibling tools like selection_set_time and project_get_overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions an alternative (project_get_overview) for when additional data is needed, providing clear guidance on when to use this tool versus that one.
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 parameter behaviors (e.g., 0 inherits previous value, linear ramp), which is valuable given no annotations. It implies mutation but does not mention side effects like overwriting existing markers or undoability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear points for each parameter. It is efficient but the Args section could be slightly more concise; still, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all inputs fully for a mutation tool with no output schema. It does not explain what happens if a marker already exists at the position, but this is minor. Overall sufficient for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully defines each parameter: position is time in seconds, bpm inherits if 0, time_sig_num/denom for numerator/denominator, linear for ramp mode. This compensates completely for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it adds a tempo and/or time-signature marker at a given time, using a specific verb and resource. It distinguishes from sibling tools like tempo_delete_marker, tempo_list_markers, and transport_set_bpm by focusing on marker addition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as transport_set_bpm or transport_set_time_signature. It lacks explicit 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?
With no annotations, the description carries full burden. It discloses parameter ranges but does not mention behavioral traits like undoability, playback impact, or whether it is destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two sentences and a parameter list, front-loading the core purpose with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool without output schema, the description covers the basic functionality and parameter constraints. It could mention the tool affects the project transport, but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates by explaining numerator as 'Beats per measure (1-32)' and denominator as 'Beat value (1,2,4,8,16,32)', adding meaning beyond the schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set time signature.' with a specific verb and resource, distinguishing it from sibling tools like transport_set_bpm or transport_set_playrate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating the tool's purpose, but provides no explicit guidance on when to use it versus alternatives, nor any exclusionary 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; description clarifies color format but does not disclose mutation effects, error handling, or whether it overwrites or merges.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose, concise with essential details, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers input format well but lacks return value description; overall adequate for a simple batch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds comprehensive meaning beyond schema: describes JSON array structure, required fields, and color format in detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb (batch set) and resource (multiple tracks) with specific properties (volume_db, pan, color, etc.), and distinguishes from individual track setting 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies batch usage vs individual track setters, but no 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?
With no annotations, the description thoroughly explains the mastering chain, plugin detection and fallback, per-style targets, and the fallback behavior for unknown styles. It also notes the clean parameter removes existing FX. However, it does not describe post-conditions or potential side effects beyond applying the chain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-organized and front-loaded with the purpose, then details. The long list of styles could be condensed, but it adds necessary context. Overall, each sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a mastering tool with auto-detection, fallback, and 35 styles, the description covers all essential aspects: chain order, plugin behavior, per-style targets, fallback, and parameter semantics. It is complete for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by defining style as a required catalog name and listing all 35 supported styles, and explaining that clean removes previously added master FX. This provides meaning beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a professional mastering chain to the master bus, detailing the chain order, plugins, and supported styles. It distinguishes itself from sibling tools like engine_mix or engine_fix_mix by focusing solely on mastering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 engine_mix or engine_fix_mix. The description does not mention prerequisites, scenarios, 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?
Without annotations, the description discloses return value (index + params or -1) but does not mention side effects, permissions, or other behaviors. It adequately describes the read operation but falls short of full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two lines and an args list. Every sentence is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a simple lookup tool with one parameter and no output schema, the description fully explains the input and return value. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (track_index) with 0% coverage, but the description adds meaning by stating it is 0-based, which is not in the schema. This compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool finds a VSTi instrument on a track, returning its index and params or -1 if none. It distinguishes from sibling fx tools like fx_add or fx_get_chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for locating an instrument but provides no explicit guidance on when to use this tool vs alternatives like fx_get_chain or fx_list_installed. No exclusions or context cues.
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. It discloses the capping behavior (max_results default and ceiling) and hints at the need to check count. It does not mention permissions, side effects, or return format, but for a read-only tool the disclosure 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, then parameter details with no unnecessary words. It follows a clear front-loaded structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks details about the output structure (no output schema). It covers the essential behavioral aspect of capping but omits what a note object looks like (e.g., pitch, velocity, position). Given the tool's simplicity, it's passable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds meaning: for max_results it gives default (500) and hard ceiling (10000), and recommends midi_count_events. For item_index, it repeats 'MIDI item index' from schema. This adds value beyond the schema's bare titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: 'Get notes in a MIDI item (capped at max_results to limit context size).' It specifies the resource (MIDI item notes) and the action (get), and naturally distinguishes from siblings like midi_insert_note or midi_count_events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using midi_count_events first if unsure about total count, which provides context for when to use this tool versus another. However, it does not explicitly exclude use cases or mention alternatives for filtering or other note operations.
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 discloses behavioral traits through parameter modes (add, configure, find_or_add) but does not explicitly state whether the tool is destructive (e.g., overwrites existing FX), requires permissions, or has side effects. It focuses on parameter details rather than overall tool 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear first sentence and organized into an Args section. While slightly lengthy, every part adds value, and the structure aids readability. Could be slightly more concise but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides comprehensive parameter guidance but lacks information about return values (e.g., success/error handling) and does not mention any post-conditions or error cases. Given the tool's complexity and lack of output schema, these gaps reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by providing a detailed breakdown of the 'tracks' JSON structure, including track_index, fx_chain with name, params, preset, fx_index, add_mode, and value ranges. This adds significant meaning beyond the schema's minimal 'type: string' definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs batch addition/configuration of FX across tracks, which is a specific verb-resource pair. It distinguishes itself from sibling tools like fx_add and fx_set_param by noting it replaces many individual calls, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for batch operations where multiple fx_add and fx_set_param calls would otherwise be needed, providing context. However, it lacks explicit guidance on when not to use this tool (e.g., for single FX operations) or alternative tools beyond fx_add and fx_set_param.
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 convey behavioral traits. It implies a read-only operation ('Dump'), but does not explicitly state that no changes are made. It also lacks details on performance, error handling, or the format of 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The main purpose is stated in the first line, followed by usage context, then a clear list of parameters. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool dumps MIDI data but does not specify the output format or structure. With no output schema, the description should give more detail on what the returned data looks like (e.g., JSON structure). It is adequate but not fully complete for a complex data retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, leaving parameters unexplained. The description compensates with an 'Args' section that explains each parameter clearly: tracks accepts a JSON array or 'all', start_time is in seconds with default 0, end_time with default -1 meaning project end. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Dump current MIDI data: per-track notes, CCs, timing stats.' This clearly states the verb (Dump), the resource (current MIDI data), and the specific content (notes, CCs, timing stats). It distinguishes itself from siblings like midi_get_notes by offering a broad overview rather than specific note retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: 'Use this to inspect what's in the project before editing, or to verify what you just inserted.' It explains the context for using the tool, though it does not explicitly mention when not to use it or name alternatives, which prevents a perfect score.
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 of behavioral disclosure. It details the two processing paths, auto-detection of plugins (FabFilter vs. REAPER stock), track naming requirements for v2 catalog, and the default cleanup behavior. However, it does not mention potential side effects, error conditions, or performance implications, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose and then provides structured details in a readable format. While it is somewhat verbose (multiple paragraphs), every sentence adds value, and the clear separation of v2 vs. legacy paths aids readability. Minor redundancy could be trimmed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with no annotations and no output schema, the description covers the essential behavior: the two processing paths, plugin handling, track naming requirements, and parameter defaults. It lacks information on error handling, return values, or edge cases, but the coverage is strong for the tool's core functionality.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description fully compensates by explaining the 'style' parameter in depth: listing examples for the v2 catalog, explaining the legacy path, and detailing track naming conventions. The 'clean' parameter is also described as removing existing mix FX before applying. This adds complete meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool is a one-click professional mix pipeline applying volume, EQ, compression, reverb, and sidechain. It distinguishes itself from siblings by detailing two distinct processing paths (v2 catalog vs. legacy orchestral) and mentions specific plugin handling, making the purpose highly specific and unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by describing the two paths based on style, but it does not explicitly state when to use this tool over alternatives like engine_fix_mix or engine_master. No exclusions or comparative guidance is provided, leaving the agent to infer usage context from the detailed behavior 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 provided, so the description carries full burden. It discloses the value range (0.0-1.0) and indexing scheme but does not mention side effects, error conditions, or whether the operation is reversible. Minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a clear list of arguments. No fluff, every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While parameters are well-documented, the description lacks context about prerequisites (e.g., track and FX must exist), success/error behavior, and potential impacts on automation or undo. Given the tool's simplicity, it is minimally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by explaining each parameter: `track_index`, `fx_index`, and `param_index` are described as 0-based, and `value` as 0.0-1.0 normalized. This adds essential meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets an FX parameter by index, distinguishing it from the sibling `fx_set_param_by_name`. It also mentions `setup_fx_chain` for batch operations, providing differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to prefer `setup_fx_chain` for batch operations, giving clear guidance on when not to use this tool and suggesting 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?
Mentions fuzzy match and value range. No annotations. Lacks details on multiple matches 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise lines: purpose then parameter list. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential parameter meanings. Minor gaps: no output info, fuzzy match behavior not fully explained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage. Description adds meaning: 0-based indexes, partial match for name, normalized value range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Set FX parameter') and resource ('by name (fuzzy match)'). Distinct from sibling like fx_set_param which likely uses 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Parameter details provided. Implicitly when you want to set by name vs index, but no explicit when-not or 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 the full burden. It discloses that items include source_file and source_filename for audio, empty strings for MIDI, and a hard ceiling of 2000 for max_results. It also advises narrowing with track_index if truncated. However, it does not mention sorting or pagination 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, a note about item fields, and parameter details. It is front-loaded with the core purpose. While somewhat verbose, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 optional params, no output schema), the description covers purpose, parameters, and key behavioral notes about source files and result limits. It lacks error cases or return format details, but for a list tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds all meaning. It explains track_index as a track filter (-1 for all) and max_results with default and hard ceiling, including a practical tip about chop-heavy projects. This goes well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all media items' with a specific verb and resource. It distinguishes from sibling tools like item_get_info by indicating it returns a list of all items with source file details. The filtering by track is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does 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 item_get_info or item_select. It mentions filtering and max_results but lacks guidance on when to choose this over other item operations. The context signals show many item tools, yet no comparison 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 provided, so description carries full burden. It discloses the action ('list') and includes active status, but does not mention error handling, read-only nature, or return 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words: purpose, context, parameter description. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers core functionality for a simple list operation, but lacks output format details (e.g., list of take identifiers and active flags). With no output schema, this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage; description adds 'Args: item_index: Global item index.' This provides necessary context beyond the bare schema, though could be more detailed (e.g., range or how to obtain).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('all takes on an item with their active status'). It also provides use-case examples (vocal comping, MIDI performances), distinguishing it from sibling take tools that add, delete, or set active takes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context ('useful for vocal comping or alternate MIDI performances') but does not explicitly state when not to use it or mention 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?
The description implies a read operation and hints that this tool may be heavier than project_get_overview, but lacks details on performance, side effects, or permissions. 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences, no redundant words. Purpose stated upfront, followed by a helpful alternative suggestion.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters, the description is mostly sufficient. However, it does not describe the return format, which could be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4 applies. The description adds no param info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets all markers and regions, which is a specific verb+resource. It also distinguishes itself from project_get_overview, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance by suggesting project_get_overview for a cheaper alternative, but does not fully cover other scenarios 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, the description carries the full burden. It discloses that the active file changes and subsequent saves target the new path. However, it does not mention error conditions, permissions, or whether the original file remains unchanged (implied but not explicit). 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and an Args line. It front-loads the main action and provides essential details without any waste. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one required parameter, no output schema), the description covers the core behavior and parameter semantics. It also compares with a sibling tool. It could mention return value or side effects, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 specifies that `path` is an absolute .rpp path, adding format and extension context beyond the schema's bare property title. This is helpful for correct parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: saving the project to a new path and switching the active file. It distinguishes itself from the sibling tool `project_backup` by explaining the behavioral difference (active file switching).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool vs `project_backup`, which is a key alternative. It implies that `project_save` will target the new path later. No other exclusions are mentioned, but for a simple 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the outcome (bus creation, routing) and parameter impact (fast attack for tight pumping) but does not detail side effects, permissions, or potential destructive behavior beyond creating a bus.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, use context, and a parameter list. It is appropriately detailed for 8 parameters, but could be slightly more concise (e.g., merging some parameter notes).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers purpose, typical values, and usage. It omits prerequisites (e.g., existing tracks) and error handling, but is reasonably complete for a setup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly explains each parameter with typical values and purpose (e.g., 'send_db: Send level from each source to the bus (0 = unity)'. Since schema coverage is 0%, this fully compensates and adds significant meaning beyond type/default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb+resource: 'Create a NY-style parallel compression bus and route source tracks to it.' This clearly distinguishes it from sibling tools like setup_drum_bus or setup_vocal_chain, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a classic use case (crushing drums/vocals and blending) and explains the benefit (density/power without destroying transients). It implicitly tells when to use but lacks explicit when-not-to-use or 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 full burden. It discloses the read operation and scoped properties, but does not mention that the tool is read-only, non-destructive, or any performance implications. For a read tool, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 13 words fully conveys purpose and scope. There is no redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool, the description covers what is retrieved. However, it does not describe the return format (e.g., array of objects, units) or pagination. Given no output schema, a bit more detail on structure would improve completeness, but it is nearly sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), and schema coverage is 100%. The description adds value by listing the specific mixer properties returned, compensating for the lack of schema detail. Baseline 4 applies per rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Get' and resource 'mixer state for all tracks', listing key properties (volumes, pans, mutes, solos, sends). It clearly distinguishes from sibling tools like track_get_all or track_get_info which retrieve different track information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving global mixer state, but does not explicitly state when to use this vs alternatives such as track_get_info or fx_get_chain. It lacks exclusions or alternative tool names.
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 only states the action ('set track color') without additional behavioral details like side effects, permissions, or error conditions. The burden on the description is high due to missing annotations, but it adds no extra 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a clear bullet list of arguments. Every sentence adds value: purpose, usage guidance, and parameter details. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (set color) and the description covers action, usage context, and parameter details. Does not mention error handling or return values, but given no output schema and straightforward nature, it's mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% so description compensates by clarifying '0-based track index' and ranges '0-255' for RGB values, adding critical meaning beyond raw schema types and names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Set track color (RGB 0-255)' with a clear verb and resource, and distinguishes from the sibling 'configure_tracks' for batch operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly suggests 'Prefer configure_tracks for batch', guiding when to use this tool for single track color changes versus batch operations. No when-not-to-use but clear implicit 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 must fully disclose behavior. It does so by stating it saves to disk at a specific path (%APPDATA%/reaper_mcp/track_templates/<name>.template) and lists exactly what state is captured. However, it does not mention whether overwriting occurs or if there are any side effects, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs plus an Args list. Every sentence adds information: the first sentence explains the purpose and scope, the second gives the file path, and the Args list clarifies parameters. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool without an output schema, the description adequately explains the action and inputs, including naming restrictions and file location. However, it does not describe the return value or behavior on existing templates (overwrite vs error), leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0% coverage (no descriptions), so the description must add meaning. It provides clear parameter explanations: track_index is 0-based track index, name has allowed characters. This adds significant value beyond the schema types, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves a track's full state as a named template on disk, specifying exact components (FX chain, sends, volume/pan/color, automation). This distinguishes it from sibling template tools like track_template_apply or track_template_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not provide guidance on when to use it over alternatives (e.g., not specifying that it should be used for saving a template rather than applying or deleting one). No explicit when-not 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?
With no annotations, the description carries the full burden. It effectively communicates that this is a read-only tool retrieving multiple state aspects. However, it does not detail the return format or units (e.g., position in seconds or beats).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It immediately conveys the purpose and key state components.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless getter, the description covers the main state components. However, without an output schema, it could be more precise about the exact keys or units returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema already fully covers them. The description adds no further meaning, but this is acceptable given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves transport state, listing specific components (play/record status, position, BPM, time sig, repeat). It distinguishes from sibling action tools like transport_play or transport_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 Guidelines3/5Does 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. However, as the only getter for transport state among siblings, usage is implied. No guidance on exclusions 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.
- 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 it calls `item_get_info` per index, returns enriched info and summary stats, defines duration classes with exact thresholds, and imposes a 200-chop limit. It does not explicitly state read-only behavior but 'Inspect' implies no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main action followed by supporting details. The list of duration classes is well-structured. Minor improvement could be more consistent formatting, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could be more explicit about the return format (e.g., structure of enriched per-chop info and summary stats). It mentions these but leaves details unspecified. However, it adequately covers input and logic for a simple inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds critical meaning. It specifies that `item_indices` is a JSON array of indices with a maximum of 200, which is absent from the schema. This ensures the AI understands format and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Inspect a list of chops and classify each by duration', identifying the specific verb (inspect/classify) and resource (list of chops). It also distinguishes its purpose by noting it helps pick chops for musical roles without audio content analysis, differentiating it from other analysis tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by stating it helps avoid audio content analysis, but it does not explicitly state when to use this tool versus alternatives. It provides context but lacks explicit when-not-to-use or alternative 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?
No annotations provided, so the description carries full burden. It explains input semantics and value conversions but does not disclose side effects like whether points are appended or replaced, limits, or error conditions. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections but somewhat verbose. It front-loads the main purpose and uses clear formatting, though could be trimmed slightly without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 6 parameters and no output schema, the description covers all parameters, input format, special value conventions for volume/pan/mute/FX, and the create parameter. It is nearly complete for effective tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates fully. It explains the JSON array format, shape codes with meanings, value units for different envelope types, and the purpose of each parameter, adding substantial meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Batch-insert automation points into an envelope.' It uses a specific verb ('batch-insert') and resource ('automation points'), and distinguishes from sibling tools like envelope_clear_range and envelope_get_points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use (e.g., for various envelope types) but does not explicitly state when not to use or compare to alternatives. It does explain the parameter meanings thoroughly.
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 of disclosing behavior. It mentions max duration of 60s and that -1 keeps the value, but does not describe whether the modification is undoable or how it interacts with item selection or 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences for purpose and guideline, then a clear list of arguments. Every sentence adds value; there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple mutation tool, the description covers purpose, parameter semantics, and usage guidance. It lacks details about error handling or prerequisites (e.g., item existence), but is sufficient for typical use. The presence of an output schema would not add much here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains each parameter: item_index is the index, fade_in and fade_out are seconds with range 0+ and max 60s, and -1 means unchanged. Since the input schema lacks descriptions, this provides all necessary meaning, far exceeding the schema's bare type and title.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets fade in/out for a single item, with a note preferring items_apply for multiple items. The verb 'set' and resource 'fade in/out' specify the action and object distinctly, distinguishing it from sibling tools like items_apply.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Prefer items_apply for multiple,' offering a clear alternative for batch operations. It also explains the -1 value meaning 'unchanged,' but does not specify when not to use the tool or other 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 implies a write operation (setting volume) but does not disclose any additional behavioral details such as immediate application, undo behavior, or potential side effects. Given no annotations are provided, more transparency would be beneficial, but the core action is straightforward.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with only two sentences and a parameter list. Every part serves a purpose: the first sentence states the main action, the second provides usage guidance, and the args list adds parameter details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides sufficient context for a simple setter tool: it explains what it does, how to use it, and when to avoid it. However, it could mention that the change applies immediately or affects playback, but given its simplicity, the coverage is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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: 'item_index' is noted as the index, and 'volume_db' is clarified as dB with 0 meaning unity. This adds essential meaning beyond the type information in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set item volume in dB', specifying the action and resource. It distinguishes itself from the sibling 'items_apply' by noting a preference for the latter when dealing with multiple items, thereby clarifying its specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises 'Prefer items_apply for multiple', indicating when not to use this tool. While it doesn't elaborate on ideal scenarios beyond single-item usage, the guidance is clear and sufficient for distinguishing between similar 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, so the description must fully disclose behavior. It says 'Insert' but does not mention what happens if an existing CC event occupies the same position, whether the event is added to an existing sorted list, or any error/return behavior. This leaves significant ambiguity for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main action. The Args block is organized and each line provides distinct, non-redundant information. No filler words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-event insert, the description covers purpose, all parameter semantics, and alternatives. It does not mention return value, but there is no output schema and the tool likely returns nothing. Minor gap: no statement about prerequisites like an existing MIDI item or active take, but the parameter list makes this inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameter descriptions (coverage 0%), but the description fully compensates by listing every parameter with type, range, or unit: track_index 0-based, channel 0-15, cc_number 0-127, cc_value 0-127, position in Seconds. This gives the agent all necessary semantic details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Insert single CC event', using a specific verb and resource. It clearly distinguishes from the sibling tools by contrasting with rewrite_cc/compose_arrangement for whole curves, and the name itself matches the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when not to use this tool: 'For whole curves use the `ccs` array of rewrite_cc or compose_arrangement.' This gives clear context and names alternatives, which is exactly what an agent needs.
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 bears the responsibility. It states the single action, which is the entire behavior. No side effects or prerequisites are mentioned, but for such a straightforward operation it is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only three words, yet fully conveys the tool's purpose. No extraneous information, exemplifying ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given 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 output schema), the description is complete. The name and sibling context resolve any ambiguity about what 'items' refers to.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 meaning. Baseline score of 4 is appropriate as per instructions for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (deselect) and the resource (all media items), distinguishing it from sibling tools like selection_deselect_all_tracks which deselects tracks instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you want to clear the selection of media items. However, it does not explicitly state alternatives or when not to use it, but the context is simple enough that it is not critical.
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 indicates a destructive operation but does not disclose potential effects like cascade deletions or error handling for 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose and one line for the parameter. It is front-loaded with the main action and avoids unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema or annotations, the description adequately covers the action and parameter, including the prerequisite of obtaining the index from a sibling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds meaning by specifying '0-based marker index' and linking to 'tempo_list_markers', which helps the agent understand the parameter's role.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete a tempo/time-sig marker' and specifies the resource and verb. It distinguishes from siblings like 'tempo_add_marker' and 'tempo_clear_all' by focusing on deletion by 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies using 'tempo_list_markers' to obtain the index, providing clear usage context. However, it does not explicitly mention when not to use this tool or suggest 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 carries the burden. It describes the return fields but does not disclose other behavioral traits like performance or side effects, though it is a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff—front-loaded purpose and essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description covers all return fields. For a simple list tool, it is complete and fits well among sibling marker tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, the baseline is 4. The description adds value by detailing the return fields (time, measure, beat, BPM, time signature), which is helpful despite no params.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List all tempo + time-signature markers in the project' with a specific verb and resource, and differentiates from sibling tools like tempo_add_marker.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit usage context: 'Use this to see the project's tempo map before editing.' While it doesn't mention when not to use it, 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.
- 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 mentions that the tool 'replaces its FX chain + settings', indicating destructive behavior. However, it does not elaborate on side effects, reversibility, or prerequisites like whether the track must exist or if undo is supported.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct with two sentences plus a parameter summary. It front-loads the action and avoids any redundant information, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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, and high-level effect. However, it does not explicitly state that the tool returns nothing or mention error conditions (e.g., invalid track_index). With no output schema, a note about return values would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds clear meaning to both parameters: 'Template name (from track_template_list)' for name and '0-based target track index' for track_index. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Apply' and the resource 'saved template to a track', specifying that it 'replaces its FX chain + settings'. This distinctively separates it from sibling tools like track_template_list or track_template_save.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to apply a template to a track) and references track_template_list for valid template names. However, it does not explicitly state when not to use it or provide clear alternatives among siblings, such as using individual fx_* 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 mentions that positions outside range are silently ignored and returns specific info, but lacks details on destructiveness, undo, or permissions, 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded, but the 'Args' section adds slight verbosity; could integrate into prose without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with no output schema, the description covers usage, parameters, and returns adequately. Minor omission: no mention of behavior when positions list is empty.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by detailing both parameters: item_index as global 0-based, positions as JSON array in seconds with an example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Slice an item at a list of absolute project-time positions' and explicitly contrasts with transient detection, distinguishing it from sibling tool 'item_split_at_transients'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'For grid-based or hand-picked chopping where transient detection isn't right', explicitly guiding 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?
With no annotations provided, the description carries the full burden. It discloses detailed behavior: case-sensitive track matching, track creation, optional BPM setting, and per-entry error reporting. This provides sufficient transparency for a batch operation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an initial purpose sentence, then a detailed explanation of parameters and return value. It is front-loaded and organized, though slightly verbose. The Args and Returns sections help readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 2 parameters, no output schema, and no annotations, the description is fairly complete. It explains the input structure, the process, and the return value (summary with errors). It could mention expected error handling beyond per-entry errors, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 detailing the 'loops' parameter as a JSON array with required and optional fields (track_name, file_path, position_sec) and the 'project_bpm' parameter with its effect. This adds complete meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool batch-loads audio loops into REAPER with auto-creation of tracks by name. It uses a specific verb ('batch-load') and resource ('audio loops'), and distinguishes from siblings like item_insert_media and track_create by combining both actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (batch loading loops with track auto-creation). It implies alternatives by mentioning track creation and single media insertion, though it lacks explicit 'when not to use' guidance. 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses that non-empty fields are written, empty strings are ignored (preserving existing values), and repeat calls overwrite previous values. It also reveals the cross-format tag embedding behavior, a non-obvious side effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-sentence summary, a short explanatory paragraph, and a bulleted Args list. Every sentence adds information, and the most important behavior (non-empty fields written) appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description covers core behavior well, including edge cases like empty-string handling and overwrites. Minor gaps remain, such as explicit notes on return values or the effect of calling with all fields empty, but those are inferable from the described semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's Args list is essential. It provides concise but meaningful definitions for all 10 parameters (e.g., 'ISRC code', 'Year / date'), adding semantics absent from the raw schema. The definitions are adequate, though they could be more detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Set project render metadata fields,' using a clear verb and resource that distinguishes it from sibling tools like project_get_metadata and project_set_notes. The scope is unambiguous and specific to metadata tagging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is given, but the name and opening sentence imply its role as the setter for project metadata. The description focuses on mechanics (non-empty behavior, tag formats) rather than when to choose this over alternatives, 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks detailed info on exact return fields, performance, or side effects beyond listing examples.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose, second provides usage guidance. Front-loaded and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description gives examples of return info but not exhaustive. Sufficient for a straightforward list tool, but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Baseline of 4 applies as description adds no parameter info (not needed).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The tool name and description clearly state it returns selected media items with full info, distinguishing from sibling project_get_overview that returns only indices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly contrasts with project_get_overview, stating when to use this tool (when full detail needed) vs the cheaper 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 present, so description bears full burden. It explains parsing behavior, return values (detected_bpm, bpm_votes, confidence, hint), but does not disclose limitations like filename format assumptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence summary followed by structured Args/Returns. Every sentence serves a purpose, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, and returns well for a simple tool. Could mention edge cases (empty array), but handles 'None' case. Output schema lacking, but return values described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only parameter 'file_paths' is described as a JSON array of absolute paths, clarifying the schema's string type. Schema coverage is 0%, but description fully compensates with clear meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the most common BPM parsed from filenames, with a specific use case after scan_audio_folder, distinguishing it from sibling tools like transport_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: after narrowing down candidate loops to confirm tempo agreement before setting project BPM. Provides context but no explicit 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?
Annotations are absent, so description must bear full burden. Describes what it does (clear+replace) and modes, but lacks disclosure of side effects, destructiveness, or authorization requirements beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded with purpose. Uses clear bullet-like Args format without 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, 3 required, no output schema, description covers core purpose, parameter details, and sibling differentiation. Lacks some details like return behavior and error handling, but sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% coverage; description compensates with detailed explanations for all 5 parameters: tracks JSON structure, start/end time units, mode options, trim_item usage. Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Clear+replace' and resource 'notes/CCs in a time range'. Distinguishes from sibling 'rewrite_cc' by specifying its use case for CC-only fixes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool vs alternatives: 'For CC-only fixes, use rewrite_cc instead.' Provides clear context for different modes and 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?
With no annotations, the description carries full burden. It notes the read-only nature ('Read'), a cap on results (max_results=2000) to prevent context blow-up, and refers to fx_get_params for obtaining FX parameters. It does not cover error behavior or what happens if the envelope is missing, but the key behavioral aspects are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded: a one-sentence purpose, followed by a list of envelope names, a note about FX mode, and a clear Args list. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of two modes and lack of output schema, the description covers input semantics thoroughly and hints at return limits. However, it does not describe the structure of the returned points (e.g., array of time-value pairs), which would help agents anticipate the output. Overall, it is largely complete but has one gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed semantics for each parameter in the Args section, far beyond the schema titles and defaults. It explains the role of track_index, envelope_name (with list of valid names), fx_index and param_index (with -1 meaning track mode), and max_results as a cap. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads automation points from a track or FX parameter envelope. It lists specific track envelope names and distinguishes between track and FX modes, making its purpose unambiguous and distinct from sibling tools like envelope_add_points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use track envelopes vs FX parameter envelopes, explaining that envelope_name is ignored when FX parameters are set. However, it does not explicitly mention alternative tools (e.g., envelope_add_points for writing) or when not to use this tool, so guidance is good but not 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?
No annotations provided, so the description carries the full burden. It describes a read-only list operation with no side effects, which is transparent and sufficient for this simple tool. No contradictory behavior is indicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the action and resource, and 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description adequately explains the returned data (name and VSTi) and usage timing. It is fully complete for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%. Per guidelines, this earns a baseline score of 4. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists all tracks with detected VSTi names and item counts, specifying the resource (tracks) and the key fields. The verb 'list' is specific and distinguishes it from sibling tools that might manipulate tracks without focusing on instruments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends calling this 'before any composition work' for instrument identification and MIDI insertion. The usage context is clear, though no explicit exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 cloning preserves source and take properties, returns new clones with item_index, and describes spacing behavior. Could mention if it's destructive or requires permissions, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with paragraphs and bullet-like args. Not overly verbose, but each sentence adds value. Could be slightly more concise, but it's effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 parameters, no output schema, and no annotations, the description covers purpose, usage, parameter details, return behavior, and examples. It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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: item_index (0-based global), count (1-100), spacing_sec (0=back-to-back, examples given). Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool copies an item N times with fixed spacing, specifying verb (copy) and resource (item). It includes concrete use cases (Porter Robinson stutter) that distinguish it from siblings like item_delete or item_move.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use it (stutters, risers, repeats) and explains default and custom spacing. No explicit exclusions or alternative tools mentioned, 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 discloses critical behavior: non-delete changes applied first in input order, deletes last in descending item_index order, and errors do not abort the batch. It clearly indicates mutation (set/delete). A point deducted for not specifying authorization or undo 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a concise summary, then a structured Args section. Every sentence provides essential information (ordering, error handling) without redundancy. It is thorough yet efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a batch mutation tool with no output schema, the description covers parameter format, ordering, and error behavior. It mentions a 'response's errors array' but does not detail the full return structure. This is a minor gap given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description completely explains the 'entries' parameter: it is a JSON array with required item_index and optional fields, including delete. Examples clarify the format, adding immense value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it batch-sets properties (position, length, volume_db, mute, fade_in, fade_out) or deletes items. It specifies the verb 'apply' and resource 'items', distinguishing it from single-item tools like item_set_volume or item_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (for batch operations), and provides detailed ordering semantics to avoid index shift issues. It implicitly differentiates from single-item siblings, but does not explicitly state when not to use it or 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?
With no annotations, the description carries full responsibility. It discloses important behavior: empty strings are ignored, at least one field must be non-empty, and storage uses specific descriptors (PROJECT_TITLE, PROJECT_AUTHOR). It also clarifies the tie to GetSetProjectAuthor(). This exceeds typical descriptions, though it doesn't mention error handling or return 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and structured. The opening sentence states the purpose, followed by two concise behavioral rules, then a 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two optional parameters and no output schema, the description is reasonably complete. It covers purpose, parameter semantics, and key constraints. It does not describe error handling or confirm project context, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only types and defaults for title and author. The description enriches both parameters by explaining their meaning ('Project title', 'Project author') and the storage descriptors. It also explains the empty-string behavior, giving clear semantic distinction and usage guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the Title and Author fields of the Project Settings -> Notes tab. It uses the specific verb 'Set' and identifies the exact resource, distinguishing it from sibling tools like project_set_notes which likely set the notes body.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on what fields it modifies (Title and Author in Notes tab), making its use case apparent. It does not explicitly name alternatives or exclusion criteria, but the specificity of 'Title and Author fields' differentiates it from other project metadata tools. The behavioral rule about empty strings also guides correct 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 discloses read behavior: walks folder, parses filenames, returns list and summary, handles unparseable files with null fields, and respects max_files with truncation flag. Could mention non-destructive nature, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with summary, then args, then return details. Front-loaded with purpose. Minor redundancy in describing return structure twice, but overall concise for the amount of information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, yet description fully documents return fields (folder, total_files, truncated, summary, loops, hint). Also provides integration advice. Complete coverage for scanning a folder.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero descriptions, but description fully documents each parameter: path with example, recursive default, max_files default and maximum. Adds concrete meaning beyond schema titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool walks a folder for audio loops and parses metadata from filenames. Lists supported file formats and extracted metadata (BPM, key, role), distinctly separating it from siblings like load_loops or detect_common_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly mentions pairing with transport_set_bpm and load_loops to build a REAPER session, and explains that the summary helps AI decide on target BPM/key. Lacks 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses behavior: registers script as action, runs it, waits for result via SetExtState, and returns result_found: false if not reported or timeout. Also warns about arbitrary code execution, which is critical for safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured: purpose first, then details on script_path, behavior, and safety. It is fairly concise but includes necessary context. Could be slightly more compact, but no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% schema coverage and no output schema, description covers most needs: behavior, parameters, result convention, safety. Minor gap: it doesn't explicitly state the return format (e.g., JSON with result_found and result fields), but implies it. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no descriptions (0% coverage), but description adds meaning: script_path is relative path from script_list with example, wait_seconds is wait time 0-30 with default 5. This compensates well for missing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Run a ReaScript from REAPER's own Scripts folder and optionally read back a result.' The verb 'Run' and the resource 'ReaScript from REAPER's Scripts folder' are specific, and it distinguishes from sibling tools by focusing on executing arbitrary scripts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides important usage guidance: script_path must be from script_list, and warns about safety ('Confirm with the user before calling'). It explains the result convention and behavior for scripts that don't report. However, it doesn't explicitly compare against alternatives or say 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?
With no annotations, the description carries the full burden. It discloses the special '31=disabled' behavior and channel semantics (0=all, 1-16=specific), which adds meaningful behavioral detail beyond the schema. However, it omits details like whether the send must already exist or the index base.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: a clear purpose sentence, a brief use-case expansion, a one-line special behavior note, and a compact parameter list. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with four parameters and no output schema, the description covers purpose, usage, all parameters, and special disable behavior. Minor gaps include index base (0-based vs 1-based) and explicit return/confirmation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by fully documenting each parameter, including allowed values and meanings (e.g., midi_source_channel: '0=all channels, 1-16=specific, 31=disabled'). This is exemplary compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource ('Set MIDI source/destination channel on an existing send') and clarifies the routing scenario ('route MIDI from a source track to a specific channel on a multi-timbral VSTi'), which clearly distinguishes it from sibling send_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a concrete use case ('Use this to route MIDI...') and the disable behavior, but does not explicitly mention when not to use it or name alternative tools. The context is clear 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?
Discloses file paths for storage and that it overrides per-category. No annotations, so description carries burden. Could mention overwrite behavior or error handling, but covers key 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Starts with one-line summary, then file paths, then structured Args section with example. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, parameters, storage location, and usage hint. Lacks details on return value or error messages, but adequate for a simple save operation without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description adds full meaning: JSON object mapping categories to plugin names, with example and valid categories list. Greatly enhances schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Save user FX preferences — per-category plugin overrides.' Specific verb and resource, and distinguishes from siblings (no other tool does 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context: mix pipelines consult it before auto-picking. Includes important note to check plugin names with fx_list_installed. Lacks explicit 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. It discloses that there is no time change, that REAPER clamps extremes, supports half-semitone floats, and that pitch quality depends on the per-take pitch shift mode setting, with a recommendation for vocals. This is adequate 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (~120 words) and well-structured: a one-line summary, paragraphs on usage, quality settings, and a clean Args block. Every sentence adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description covers purpose, usage, parameter details, range, and behavioral notes on pitch shift mode. It is complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains all three parameters in the Args section: item_index as global 0-based, semitones as float with range, and take_index as 0-based or -1 for active. It adds meaning not in the schema, such as range for semitones and the purpose of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Pitch-shift a take by N semitones (no time change)' and explains the use case 'The core of tune a chop to a chord tone'. It uses a specific verb+resource and distinguishes from siblings like take_set_playrate and take_set_reversed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use (tuning a chop to a chord tone) and how to use (positive/negative values, range, half-semitones). It does not explicitly list alternatives or when not to use, but the context strongly implies differentiation from other 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 the burden. It transparently explains that a new reversed take becomes active and the original is kept, referencing the underlying REAPER action. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured with a summary, mechanism, use cases, and args. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description covers purpose, effect, parameter meaning, and reversion method. Complete and actionable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, but the description adds meaning by specifying 'Global 0-based item index,' which is necessary beyond the schema's 'integer' type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Reverse an item's audio' and explains the mechanism (uses REAPER's action, new take becomes active, original kept). It distinguishes from siblings like take_set_pitch or take_set_playrate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains how to revert via `item_take_set_active` and gives creative use cases. While it doesn't explicitly contrast with alternative tools, the usage is clearly 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?
No annotations are provided, so the description carries full burden. It discloses that it is a read operation, explains the output format (linear and dB ranges), and emphasizes that it only works during playback. This provides good transparency for a simple read 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it first states the purpose, then the critical usage condition, followed by use cases, return format, and argument definition. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one parameter and no output schema, the description covers all necessary context: what it does, when to use it, what values to expect, and how to supply the argument. It is complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only one parameter (track_index) with 0% schema description coverage. The description clarifies '0-based track index', which is exactly what the agent needs. While minimal, it is sufficient for understanding the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reads instantaneous peak level from a track's meter (L+R channels). It explains the purpose: checking clipping, comparing levels, verifying mix. No sibling tool reads peaks, so it 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Only meaningful DURING playback' and advises to start playback and wait before reading. It provides clear context for use, though it does not explicitly state when not to use it. Since no alternative exists, this 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?
No annotations are provided, so the description carries full burden. It explains the pan range but does not mention side effects, prerequisites, or whether it overrides existing settings. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short sentences for the body and two line arguments. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with no output schema, the description is mostly complete. It might miss how errors are reported (e.g., invalid track index), but overall covers necessary usage details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description fully explains both parameters: track_index as 0-based, pan with range -1.0 to 1.0. 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/5Does 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 'track pan', making the tool's purpose unambiguous. It also distinguishes itself from the batch alternative 'configure_tracks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends using 'configure_tracks' for batch operations, providing clear when-to-use context. The argument descriptions explain acceptable values, aiding correct 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?
Discloses that all times are raw seconds independent of tempo, and that there is no bpm parameter. Also reveals the blocking limits (max 2 tracks, 30 notes) to prevent accidental mass inserts. However, it doesn't specify whether the tool creates new MIDI items or modifies existing ones, which is a minor gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly long but well-structured: purpose statement, format details, time unit warning with sibling comparison, block limit info, then Args list. Every sentence adds value, though it could be slightly tightened without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations and only two parameters, the description covers input formats, time units, limits, and the effect of clear_existing. It also suggests alternatives for larger writes. It doesn't explain error handling or the exact arrangement impact (e.g., item creation vs. modification), but is otherwise comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds rich semantics: explains that 'tracks' accepts shorthand or JSON arrays with examples, and explains that 'clear_existing' wipes target tracks. Also clarifies the time unit convention and the absence of a bpm parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Batch-insert MIDI from shorthand or JSON — guarded for small edits only', which is a specific verb+resource combination that clearly distinguishes it from sibling tools like create_drum_pattern and create_chord_progression, which use quarter-notes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (small edits) and when not to (for larger writes, use batch MIDI tools). Also contrasts with create_drum_pattern and create_chord_progression by highlighting the difference in time units, and advises converting tempo using project_get_info for bar alignment.
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: it creates non-overlapping items, does not append to previous ones, and returns the item index, number of chords, and failures. The note about auto-creating items and section placement is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise purpose statement, followed by examples and clarifications. It is slightly lengthy but each sentence adds value; the front-loading is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 0% schema coverage and 8 parameters, the description is remarkably complete. It addresses return values, multi-section workflow, chord quality list, and default behaviors, leaving minimal gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description explains chords format, base_octave, chord_duration_qn, start_qn, and item_index in detail. It does not explain channel or velocity, but these are less critical defaults. Overall, it 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Insert a chord progression as voiced MIDI notes' with a specific verb and resource. It distinguishes itself from siblings like midi_insert_note by focusing on chord progressions with voicing and multiple delimiters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage: acceptable chord delimiters, default values for duration and octave, and how to use item_index and start_qn for multi-section arrangements. It does not explicitly list 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 full burden. It discloses all key behaviors: creates MIDI items on drum channel 9, returns item index and note count, does not append to previous items, and ignores unknown characters. Could mention whether previous items are overwritten, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with an example and separate sections for mapping and usage notes. Slightly lengthy but each sentence adds value. Front-loaded with the core concept.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For 8 parameters and no output schema, the description covers pattern input, defaults, return value, and multi-section behavior. Lacks details on velocity/bar_count but these are intuitive. Completeness is high given context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 pattern syntax in detail with character mapping, default values for channel, velocity, bar_count, steps_per_bar, and the special item_index=-1 usage. Adds meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates drum patterns from step-sequencer shorthand, specifying characters for GM drums and providing an example. It distinguishes itself from sibling tools like midi_insert_note by offering a dedicated shorthand syntax.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given for multi-section arrangements: use item_index=-1 and increasing start_qn for non-overlapping items. The description also explains that unknown characters are ignored, aiding correct 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 provided, so description carries full burden. Discloses that it creates tracks with ReaSynth and MIDI patterns, and that clean_first parameter wipes existing MIDI and markers. Missing details about whether it opens a new project or affects current state, but overall adequate given simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with core purpose, then usage example, then track listing, then parameters. Each sentence is purposeful, no fluff. Highly efficient for the amount of information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only 2 optional parameters and no output schema, the description covers all essential aspects: what it creates, how to use it afterward, and parameter details. Complete enough for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must add meaning. Describes clean_first as 'wipe existing MIDI + markers first' and bpm with default 140 and explanation of matching half-time feel. This adds significant value beyond the schema's type/default fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states specific verb 'scaffold' and resource 'minimal EDM test project' with 7 tracks. Lists tracks and MIDI. Distinguishes from siblings which are individual operations (track_create, midi_insert_notes, etc.) by creating a whole project. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: to verify end-to-end workflow of engine_mix, engine_master, setup_sidechain. Provides concrete follow-up commands. Does not explicitly mention when not to use or alternatives, but the context is clear for a test project 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 are provided, so the description carries full burden. It discloses cosmetic nature, version requirement (REAPER 6.37+), and clean error behavior. Lacks details on permission or side effects, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise paragraphs with a clear first sentence and an 'Args' list. No fluff, every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers purpose, usage, parameters, version requirement, and expected behavior. A complete and self-contained definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It explains track_index (0-based), fx_index (slot within chain), and new_name (max 1000 characters), adding meaning beyond schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'FX instance's display label', and specifies it's cosmetic (plugin unchanged). It distinguishes from sibling tools like fx_add or fx_remove.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a specific use case: tagging user-added FX for later cleanup. It also mentions internal usage by the mix engine. No explicit 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?
With no annotations, the description discloses key behaviors: it uses REAPER's native transient detection (action 40310), sensitivity is set once in project settings, and it returns detailed chop information. It lacks mention of undo behavior or error handling but is otherwise transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words. It uses clear structure with sections for Args and Returns, and front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description provides thorough context including behavior, external dependency, and return format. It covers all essential aspects 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully compensates by defining item_index as 'Global 0-based item index of the source audio item,' adding essential semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool slices an audio item at every detected transient, using a specific verb ('Slice') and resource ('audio item'). It differentiates from siblings like item_split_at_positions by focusing on transient-based splitting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool and notes that sensitivity is controlled externally in REAPER settings. It does not explicitly exclude alternatives but provides sufficient context for 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 discloses that the fields return their actual stored values and are not write-only, adding useful behavioral context. However, it does not describe the return format or any potential error conditions, which would further enhance 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences, front-loaded with the primary purpose, followed by useful clarifications. 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/5Given 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 output schema), the description is quite complete: it states what is returned, clarifies scope, and distinguishes from related tools. It could mention the expected return structure explicitly, but the high-level completeness is strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty). Per the baseline for 0 params, a score of 4 is appropriate; the description adds no param details because there are none to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get the Title and Author fields of the Project Settings -> Notes tab' with a specific verb and resource, and distinguishes from sibling tools by referencing project_get_notes and project_get_metadata. This clearly differentiates 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/5Does 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 by contrasting it with the notes free-text area and render metadata, and notes that these fields return actual stored values. This helps the agent select the correct tool among 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 explains the effect of ripple mode on editing (shifts subsequent items) and enumerates the mode values. It could mention potential side effects like impact on undo history, but overall it 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short paragraphs plus an Args line, with no redundant information. Every sentence contributes to understanding, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one integer parameter, no output schema), the description covers all necessary aspects: purpose, behavior, parameter meaning, and use case. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides no description for the 'mode' parameter (0% coverage). The description fully compensates by explaining each value: 0=off, 1=per-track, 2=all-tracks, adding essential meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 'REAPER's ripple edit mode', and explains what ripple mode does, distinguishing it from sibling tools that handle items, tracks, FX, 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (critical for dialogue/podcast editing) but does not explicitly state alternatives or when not to use it. Since no sibling tools serve the same purpose, the lack of exclusions is acceptable.
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 key behaviors: clones at same position on same track, simultaneous playback, use of take_set_pitch, and risk of overlapping items. It does not mention undo or performance beyond crowding, but is transparent enough 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear two-sentence introduction, then a usage note, then parameter definitions. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters and no output schema, the description covers purpose, behavior, parameter details, and usage advice completely. It is self-contained and informative for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 0%, the description fully explains both parameters: item_indices as JSON array up to 50, intervals_semitones as pitch shifts with default and unison example. This adds significant 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: creating overlay copies at pitch intervals for each chop, specifically for a classic future bass harmonized stack. It distinguishes from siblings by detailing a unique multi-voice cluster operation not provided by other item/take 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance on when to use (subset of chops) and why not all (mixer crowding). It also mentions how to achieve unison-only with empty array. No explicit alternatives or when-not conditions, 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.
- 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 parameter meanings (0-based index, dB values with examples) but does not disclose potential limitations, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus parameter details, front-loaded purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two parameters, the description covers purpose, usage context, and parameter semantics adequately. No output schema needed; documentation is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds essential semantics: track_index is 0-based, volume_db in dB with examples (0=unity, -6=half).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Set track volume' with a specific verb and resource. Also differentiates from siblings by naming 'configure_tracks' for batch operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer configure_tracks for batch, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. Describes destructive behavior, selective deletion by active take type, and side effect on markers/regions. Missing details on permissions, undoability, 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: 4 short sentences plus args section. No wasted words, front-loaded with main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter, no output schema, and low complexity, the description fully covers purpose, behavior, and parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter 'tracks' is fully explained: it's a JSON array of track indices, with example and meaning of empty string. Schema coverage is 0%, but description compensates excellently.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool wipes all MIDI items and resets composition state. Distinguishes from siblings by specifying it only affects MIDI items with active MIDI takes, leaving audio untouched. The verb 'wipe' and resource 'MIDI items' 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use: when wiping MIDI items while preserving audio. Describes side effect of full wipe clearing markers/regions. Lacks explicit when-not to use or mention of 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?
The description explains the internal process (walking chops, determining chord, picking tone, applying pitch shift via take_set_pitch) and notes that the result may sound unnatural. It also addresses the source_root behavior. However, it does not explicitly mention whether the operation is destructive (modifies existing items) or creates new ones, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a warning, then process explanation, then parameter details. Each sentence adds value, though the warning section is somewhat lengthy. 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (6 parameters, no output schema, no annotations), the description is highly complete. It covers all parameters, provides usage context, warns about alternatives, and explains the internal logic. The only minor gap is the lack of explicit mention of return value, but that is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains every parameter in full detail, including item_indices usage, chord_progression format, defaults for beats_per_chord and bpm, all layout options with examples, and source_root semantics. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the purpose: 'Retune each chop to a chord tone.' It immediately distinguishes itself from the sibling tool chop_pipeline, noting that this is a niche, experimental alternative. The verb 'retune' and resource 'chops' 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use and when not to use: it warns that this is not professional and recommends chop_pipeline as the correct default. It states 'DO NOT use it as your default chop workflow' and limits usage to stylized experimental effects like glitch/granular.
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 behavioral traits: silent ignoring of invalid field combinations, the order of operations to avoid index shifting, and error handling that doesn't abort the batch. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary sentence and detailed 'Args' section. It is front-loaded with the main purpose. Every sentence adds value, though it could be slightly more concise. Given the complexity, it is appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks an explanation of the return value. It mentions an 'errors array' in the response but does not describe the full return structure. For a batch operation, knowing the response format (e.g., success count, error details) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema has only one parameter 'entries' with 0% description coverage, the description compensates excellently. It provides detailed examples and semantics for each field, including marker_index, name, start, end, position, color, and delete, explaining constraints and behaviors (e.g., start/end only for regions).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Batch edit (name/position/start/end/color) or delete markers and regions in one call.' It specifies the exact attributes that can be edited and distinguishes this batch operation from individual marker tools like marker_edit or marker_delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides comprehensive usage guidance, including the exact format for entries, the behavior for mismatched fields (silently ignored), the order of operations (non-delete first, then deletes in descending order), and error handling (bad index recorded in errors, batch continues). It clearly implies this is for batch operations, contrasting with 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?
With no annotations, the description fully carries the burden and discloses the random behavior mechanism: each note shifted by ±timing_ms and velocity by ±velocity_amount. It also specifies defaults (timing_ms=15, velocity_amount=8), making the tool's mutational 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a one-sentence overview, a bulleted list of typical values, and a numbered 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While lacking output schema and annotations, the description sufficiently covers usage and parameters. It could clarify if it affects all takes or only the active take, and if there are side effects like undo state, but overall it is complete for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 each parameter: item_index is the global item index, timing_ms is max random shift in ms, velocity_amount is max random velocity offset. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds random timing and velocity jitter to MIDI notes, with the purpose of making programmed MIDI less mechanical. It uses a specific verb-resource pair ('Add random timing + velocity jitter') and distinguishes from sibling tools like midi_quantize which serves a different 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit typical values for strings/pads, drums, and piano, offering clear context for parameter selection. However, it does not explicitly state when not to use this tool or compare to alternatives like midi_quantize, though the usage examples imply the 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?
Despite no annotations, the description discloses a key behavioral trait: the backup does not change the active project file. This is important for safe usage. However, it does not mention overwrite behavior or return values, but for a backup tool, the behavior 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two paragraphs: first paragraph delivers the core purpose and usage guidelines succinctly; second paragraph lists the argument. No extraneous info, every sentence is valuable and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's purpose, when to use it, and the single parameter. Given the tool's simplicity and absence of output schema, it provides 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description defines the 'path' parameter as an absolute .rpp path for the backup copy, adding meaning beyond the schema's bare string type. With 0% schema description coverage, this compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (save a snapshot copy) and resource (to a path). Explicitly distinguishes from sibling tool 'project_save_as' by noting it does not change the active file, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use the tool: before risky/destructive changes like wiping MIDI, deleting tracks, or clean=True mix passes. Also contrasts with 'project_save_as' to clarify 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?
No annotations exist, so the description carries the full burden. It discloses that the tool is cheap, returns a monotonically increasing counter, and bumps on any edit. However, it doesn't specify what constitutes an 'edit' (e.g., all project modifications?). Still, the core behavioral trait 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two short paragraphs) and front-loaded with the primary purpose. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return value and how to use it. It is complete for a simple check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds meaning beyond the schema by explaining the counter's usage and monotonic nature. Baseline for zero params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: a cheap check for project changes. It uses specific verbs ('returns a monotonically increasing counter') and distinguishes itself from heavier data-fetching tools like track_get_all and item_get_all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: compare the returned counter against a previously saved value to decide whether to re-fetch heavier data, instead of blindly re-querying every turn.
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 returns project info (not modified), and explains the behavior of path (always present) and file_path (empty for unsaved projects). No mention of side effects or errors, but for a read-only info tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each serving a distinct purpose: purpose, usage guidance, and field clarification. No extraneous information. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no input parameters and no output schema, the description fully covers what the tool does, what it returns, and provides an alternative for post-production. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 input parameters, so baseline is 4. The description does not add parameter semantics but instead explains output fields (path, file_path) which is valuable context beyond the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Get' and the resource 'project info', listing specific attributes: name, BPM, time sig, tracks, length, markers, render settings. Distinguishes from sibling project_get_overview by explicitly recommending it for post-production work.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises to prefer project_get_overview() for post-production, explaining it combines this info with region list, change_count, and selection summary. Also clarifies the distinction between path and file_path, guiding correct 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?
Despite no annotations, the description discloses a major behavioral limitation: the API only exposes which fields are set, not their values, and explicitly notes values are write-only. It also explains the exact return structure (fields_set and tags_present) with an example, even specifying the REAPER version verified. This exceeds expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured: a one-sentence purpose, a brief context paragraph, and a crucial note on API limitations. Every sentence adds value, and the most important behavioral warning is clearly separated. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with no output schema, the description is fully complete. It covers what the tool does, where it fits in REAPER, what it returns (fields_set and tags_present with examples), and its key limitation. An agent has all necessary information to invoke and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline of 4 applies. The description adds no param details needed, but it does clarify the return payload, which indirectly helps an agent understand there are no inputs required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear, specific verb phrase: 'Get project render metadata' and lists example fields (title, author, album, comment). This distinguishes it from sibling tools like project_get_info (project properties) and project_set_metadata (the setter counterpart).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context by explaining these are fields REAPER embeds into rendered files and how they're used in filename templates, as well as where they appear in the GUI. It implicitly signals when to use this tool, though it doesn't explicitly name alternative tools like project_get_info or project_get_notes for exclusion.
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 it as cheap/lightweight, returns only indices and counts for selection (not full detail). With no annotations, this adequately discloses behavioral traits, though does not explicitly state it is read-only (implied by 'overview').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler. First sentence states purpose and output; second lists bundled alternatives; third clarifies selection summary scope. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description sufficiently explains return values (counts, region list, change_count, selection summary with indices and counts). Complete for an overview tool with this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema (0 params, 100% coverage baseline). Description adds no parameter info, but none needed; baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States tool provides a cheap overview for post-production awareness, listing specific data: counts, region list, change_count, selection summary. Distinguishes from siblings by naming 6 specific tools it replaces (project_get_info, marker_get_all, etc.).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (for overview/awareness) and when not to (if full detail needed on selection, use selection_get_selected_tracks/items directly). Provides clear alternative 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?
With no annotations, the description carries the full burden of behavioral disclosure. It transparently warns that malformed entries are skipped silently and that the success flag can be misleading ('ccs_inserted: 0'), advising to check that count. It also notes limitations like the absence of curve templates and that resolution is up to the user. These details go beyond what any annotation could provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with an opening summary, a brief how-to note, and a labeled Args section. Every sentence contributes value, including the warning about malformed entries. The length is appropriate given the complexity of the JSON parameter and the need to convey edge cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers most necessary context: explicit CC points, range parameters, and the silent-failure behavior. It mentions a 'success' flag and 'ccs_inserted' count, hinting at the return structure, but does not fully specify the return value or explicitly state that existing CC in the range are removed. Given no output schema, a bit more detail on the return format and replacement semantics would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly compensates. It explains the `tracks` parameter with an example JSON structure, clarifies that position is in seconds, allows 'all' as a value, and describes the silent-skip behavior. It also defines start_time and end_time as seconds. This adds substantial meaning beyond the bare schema names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Replace CC automation in a time range, leaving notes untouched.' It uses a specific verb ('replace') with a defined resource ('CC automation in a time range') and explicitly distinguishes itself from note operations, which sets it apart from sibling tools like midi_insert_cc or midi_delete_cc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does 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: to replace CC automation within a specified time range without affecting notes. It also gives practical guidance on how to construct curves (explicit CC points, no templates) and includes an example. However, it does not explicitly mention alternatives or when not to use the tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses the hard-coded folder path, return format (path + parsed description), result cap, filter semantics (path-only, case-insensitive), performance rationale for not filtering by description, and a potential pitfall for keyword searches. This is exceptional 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and efficiently structured with an Args section. The second paragraph slightly repeats the 'filter matches path only' statement, adding some redundancy, but overall every sentence contributes meaningful detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description fully explains return values (relative path and description), limits (300 cap), and filter behavior. It leaves no significant gaps for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only defines 'filter' with a default, but the description thoroughly explains its meaning: case-insensitive substring match against path only, not description, with reasoning and guidance on narrowing searches. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists ReaScripts (.lua/.eel only) from REAPER's Scripts folder, with a specific verb and resource. It distinguishes itself from script_run by focusing on enumeration rather than execution, and is unambiguous about 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives practical usage context: reveals hard-coded scope, 300-result cap, filter usage, and explicitly points to passing the path to script_run. It does not name alternative tools or state when not to use it, but the unique purpose makes this less critical.
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 adequately describes the tool as a read operation returning full track info, which is sufficient for a simple getter. No side effects 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. First sentence states purpose, second provides guidance. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and simple tool, description is complete. It covers purpose, usage, and return value. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, so baseline is 4. Description doesn't need to add param info. It does hint at output content (full detail) which adds context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets selected tracks with full info, using specific verb 'Get' and resource 'selected tracks'. It distinguishes from sibling project_get_overview by noting that this tool returns full detail vs indices only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use this tool (when full detail needed) and when to use alternative (project_get_overview for indices only), including cost 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?
With no annotations, the description carries the transparency burden. It reveals important behavior: MIDI routing requires paired channel parameters, and audio is separate and can be muted via send_set_mute. However, it doesn't mention side effects, prerequisites, or project mutation details beyond the obvious creation 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: main purpose, then batch alternative, then MIDI-specific usage, then structured args. Each sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given 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, the description covers the core functionality and parameter semantics thoroughly. Minor gaps include lack of index convention (0-based vs 1-based) and no mention of return value or error behavior, but these are not critical for basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. Every parameter is explained: source_track and dest_track are indexes, midi_source_channel/dest_channel have ranges (0=all, 1-16) and a pairing constraint. This adds significant meaning beyond the bare schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create send between tracks,' clearly identifying the verb and resource. It distinguishes itself from siblings by explicitly referring to setup_routing for batch operations, making it clear this tool handles individual send creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Prefer setup_routing for batch' indicates when not to use this tool. It also explains when to use MIDI parameters and references send_set_mute for muting audio, giving contextual direction for related operations.
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 aux sends, adjusts channel counts, finds or adds compressors, pin-maps sidechain inputs, and configures compressor parameters. It also clarifies how 'amount' translates to threshold/ratio when not explicit, and lists return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary, bulleted use cases, and detailed parameter explanations. While it is somewhat lengthy, every sentence adds value. Slightly more conciseness could be achieved by combining some arg descriptions, 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description lists return keys. All 10 parameters are documented with sensible defaults. The tool is complex (10 params, 2 required), but the description covers setup steps, use cases, and parameter interactions, leaving no major gaps for an AI agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (no property descriptions), so the description must compensate. It does so thoroughly: each parameter is explained with its role, default values, units, and how they interact (e.g., 'ratio: 0 = derive from amount'). 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets up sidechain compression with 'source pumps/ducks the target.' It explains the specific actions (aux send, channel setup, compressor configuration) and distinguishes from sibling tools like setup_parallel_compression and setup_drum_bus by focusing on sidechain routing and pumping character.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides concrete use cases (e.g., EDM kick → bass, vocal lead → pad) that imply when to use this tool. However, it does not explicitly state when NOT to use it or mention alternative methods (e.g., manual sidechain routing). The examples are helpful but leave some ambiguity about 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?
Despite no annotations, the description details critical side effects: source tracks are automatically muted, stems inserted below sources, and works with pre-fader+post-FX. It also notes undocumented REAPER behavior, fully disclosing what happens during invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with headers and bullet points, but somewhat lengthy. Each sentence adds value. Could be slightly more concise, but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, no annotations, and no output schema, the description is comprehensive: covers purpose, side effects, prerequisites (REAPER 5.x), and comparison with sibling. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description explains track_indices (JSON array of indices) and clarifies that output_dir and format are reserved/not currently used. This compensates well, though the schema could be improved with descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders tracks as individual audio stems in-project, using a specific REAPER action. It explicitly distinguishes from sibling tool project_export_audio, which is for exporting to disk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance, including side effects like auto-muting and the alternative export tool. Mentions the need to call track_set_mute(False) if originals are needed. This helps 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It transparently discloses that chops are contiguous, pitch is uniform, layers are separate tracks, and bar-level variation occurs. It also notes the requirement for user-configured pitch-shift mode, providing complete behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: a one-sentence summary, bulleted rules, mode descriptions, and an arg list. Every sentence adds value without redundancy. It is as concise as possible given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 11 parameters, no output schema, and no annotations, the description covers all necessary context: prerequisites, behavior, modes, and parameter details. It leaves no obvious gaps for a user to understand tool usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, the 'Args:' section in the description explains every parameter with defaults, examples, and context (e.g., mode differences, chord_progression format, source_key/target_key defaults). This adds substantial 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'End-to-end vocal-chop arrangement' and details the two modes (slice-preserve and melody) along with specific rules (contiguous, uniform pitch, separate tracks, bar-level variation). It distinguishes itself from siblings like analyze_chop_set or arrange_chops_to_chord_tones by covering the full workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each mode (e.g., melody requires chord_progression) and lists a prerequisite (REAPER's pitch-shift mode). However, it does not explicitly state when not to use this tool or suggest alternatives, which keeps it from being a 5.
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 fully discloses the corrective EQ per track (HP filter, narrow cuts, high-shelf air boost) and optional master chain (bus glue comp + brick-wall limiter). No hidden behaviors or 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose first, then process, then usage. Every sentence adds value, but slightly verbose with detailed EQ list. 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/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but tool is a mutation that applies effects. Description covers what it does, when to use, parameters, and process. No missing critical information for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description explains both parameters: style (optional v2 catalog style for better classification) and include_master (apply emergency master chain, default True). Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool rescues a muddy/harsh/unbalanced mix with specific corrective EQ processing per track. It distinguishes from sibling tool engine_mix by specifying this is for fixing a poorly mixed track, not replacing engine_mix.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance: 'Call this when a mix sounds stuffy or harsh and you want a quick corrective pass before fine-tuning.' Also warns it doesn't replace engine_mix and should be used to fix something already mixed poorly by someone else.
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. Explains the cap on the raw list and the rationale. Notes that rack plugins are detected but the MCP does not configure them, warning against routing auto-mixing through them. Also mentions user_overrides from preferences. This provides clear behavioral context for a read-only query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is comprehensive but somewhat lengthy, including rationale for the cap and detailed explanations. While well-structured with sections and a clear docstring, it could be slightly more concise without losing key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description details the return structure (all_installed, best_* picks, racks_detected, user_overrides). It explains the cap logic and parameter usage. The tool is moderately complex, and the description covers all needed aspects for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description provides detailed docstrings for both parameters: category with allowed values (eq, compressor, etc.) and full_list with explanation of when to use it. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists every FX plugin installed in REAPER, grouped by category. It specifies the verb 'list' and the resource 'FX plugins'. It distinguishes from siblings like fx_get_chain and other FX tools by focusing on the installed plugin inventory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'Use this BEFORE running mix pipelines to know what the user has.' Provides guidance on preferring premium plugins over REAPER stock. Also explains when to use the full_list parameter: 'Only needed if you're hunting for something the built-in category rankings don't cover.'
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, but description fully discloses behavior: time-stretch effect with pitch preservation, speed change without pitch preservation, and that item length does not auto-resize. 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded with purpose. Uses clear bullet-style for args. Minor redundancy but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity (3 params, no output schema, 40+ siblings), description is complete. Explains effect, post-conditions (length not resized), parameter details, and usage scenarios. No need for more.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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: item_index (global 0-based), rate (playback rate with range 0.05-16.0 and examples), preserve_pitch (default True, effect explained). Adds meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Time-stretch a take by changing its playrate.' Distinguishes from siblings like transport_set_playrate, take_set_pitch, and take_set_reversed by specifying the behavior and use cases (fitting chop to beat grid, vinyl-style speed change).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use (fitting chop to beat grid, vinyl-style) and what not to expect: 'item's visible length does NOT auto-resize. Call item_set_length afterwards.' This guides the agent to use another tool after, providing clear context for 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 are provided, so the description bears full responsibility. It discloses the destructive nature (deletes markers), clarifies what it does NOT affect (base BPM), and implies no other side effects. This is sufficiently transparent for a simple parameterless 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences convey all necessary information. Each sentence serves a purpose: the first states the action and result, the second clarifies a common misconception. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description covers all needed context: what it does, what it doesn't do, and a pointer to an alternative tool. It is fully sufficient 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.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100% (empty). Baseline is 4, and the description adds no parameter info because none is needed. The description focuses on the tool's action rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete every tempo/time-sig marker') and the effect ('resets the project to its base tempo'). It distinguishes itself from sibling tools like tempo_add_marker and tempo_delete_marker by using specific verb+resource phrasing. The added note about not changing base BPM further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly indicates when to use this tool (when you want to clear all markers and reset to base tempo) and provides a direct alternative: 'use `transport_set_bpm` for that' to change the base tempo itself. This offers clear guidance on choosing between 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 explains the behavioral effect: 'Freezing bypasses the live FX chain and plays back rendered audio'. It mentions the action used (REAPER action 41223) and the consequence. No annotations are provided, so the description carries full burden and does so 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief yet comprehensive: 4 sentences, each earning its place. It is front-loaded with the primary action and efficiently covers purpose, usage, behavior, and parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is fully complete. It explains what the tool does, when to use it, what to expect, and how to undo. No gaps are apparent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter track_index is described as '0-based track index', which adds meaningful clarification beyond the schema (type integer, title). Given 0% schema coverage, the description compensates adequately, though it could be slightly more detailed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Freeze a track to stereo audio (pre-fader render of FX + VSTi)'. It uses specific verb and resource, distinguishes from sibling tool track_unfreeze by mentioning the inverse operation, and references the REAPER action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'use when a track's VSTi or FX chain is CPU-heavy and you're done editing that part'. It also provides a clear alternative by referencing track_unfreeze for restoring the original state.
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 carries the full burden of behavioral disclosure. It details the underlying REAPER API call (TrackFX_AddByName), explains fuzzy resolution, notes that plugin format cannot be selected, and warns that REAPER's 'vst:'/'vst3:' prefixes and raw .dll filenames fail. This is highly transparent about how the tool behaves.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, followed by a well-structured paragraph explaining naming nuances, and ends with a clear Args list. Although it is longer than typical descriptions, every sentence carries essential information for correct usage, making it appropriately sized and well organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (fuzzy naming, format ambiguity) and lack of annotations/output schema, the description covers all critical aspects needed for correct invocation. It explains what failures look like, how to avoid them, and how parameters should be formed. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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: 'track_index' is defined as '0-based track index', and 'fx_name' is defined as 'Bare plugin name' with concrete examples and a detailed explanation of what formats are acceptable. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Add FX plugin to track', which is a specific verb+resource statement that clearly states what the tool does. It also distinguishes itself from the sibling tool setup_fx_chain by noting 'Prefer setup_fx_chain for batch operations', making it clear this tool is for single operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names an alternative tool ('Prefer setup_fx_chain for batch operations') and provides extensive guidance on naming conventions, including what prefixes fail and how to interpret fx_list_installed output. This gives the agent clear direction on when to use this tool and how to avoid pitfalls.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/xDarkzx/Reaper-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server