reaper-reapy-mcp
Server Quality Checklist
Latest release: v0.1.4
- Disambiguation2/5
Several tools have unclear boundaries, especially the time signature cluster (get_time_signature, get_project_time_signature, set_project_time_signature, set_time_signature) which appear to overlap. get_selected_midi_item and get_selected_items also partially overlap, leading to potential misselection.
Naming Consistency5/5All tool names follow a strict verb_noun snake_case pattern (e.g., create_track, set_tempo, get_midi_notes). There are no mixed conventions or vague verbs, making the naming predictable and self-documenting.
Tool Count2/5With 47 tools, the server is far above the typical well-scoped range. While REAPER is a complex DAW, this count feels excessive and likely overwhelms agents, especially with many specialized query and manipulation tools.
Completeness2/5Core DAW operations are missing: no delete_track, no per-track volume/pan/mute/solo controls, and no get_marker_list. These gaps force agents to use workarounds or fail when performing basic track management and marker retrieval.
Average 3.5/5 across 47 of 47 tools scored. Lowest: 1.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 10 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior1/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. Instead of explaining what happens when creating a track (e.g., where it is added, return value, side effects), it only discusses index conventions. This is irrelevant to the tool's behavior and fails to disclose any operational traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
The text is concise in word count but entirely off-topic. It does not follow a typical tool description structure; it is a standalone note about indexing. Every sentence is wasted on irrelevant information, making it the opposite of a well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (one optional name parameter) and the existence of an output schema, a complete description would explain the tool's purpose and any relevant index conventions if they apply. This description provides none of that. It is incomplete for basic understanding, let alone for proper tool selection and 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?
The schema has one parameter 'name' with zero description coverage. The description does not mention 'name' at all, so it adds no meaning beyond the bare property name. The user cannot tell what the name parameter represents, its format, or whether it is required in practice.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description does not state what create_track does. It only provides a note about track indices in the REAPER API versus the UI, which is unrelated to the tool's purpose. There is no verb indicating creation or any resource being acted upon, making it effectively missing.
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 rename_track or get_track_list. The note about indexing might be tangentially related to working with tracks, but it does not explain usage context, preconditions, or selection criteria.
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It does not mention whether adding an FX replaces existing ones, whether it is reversible, requires any permissions, or has side effects. The bare statement 'Add an FX to a track' reveals nothing beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, but it is under-specified rather than concise. It lacks critical details about parameters and behavior, making it inefficient for an agent to correctly invoke the tool. Every sentence should earn its place, and this one provides minimal value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation tool with no annotations, the description is severely incomplete. It does not explain how to specify fx_name (e.g., from get_available_fx_list), whether track_index is zero-based, or any error conditions. The presence of an output schema does not compensate for missing parameter semantics and usage context.
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 input schema has 2 parameters (fx_name, track_index) with 0% description coverage. The description provides no additional meaning for these parameters—it doesn't clarify expected formats, valid values, or indexing conventions. Since schema coverage is 0%, the description must compensate, but it completely fails to do so.
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 clear verb ('Add') and specifies the resource ('FX') and target ('track'). It distinguishes itself from sibling tools like remove_fx, toggle_fx, and set_fx_param by clearly indicating a creation/insertion 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?
The description provides no guidance on when to use this tool versus alternatives, nor any context about prerequisites, parameter selection, or behavior in edge cases. It simply states the action without usage conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description itself must convey behavioral traits. It implies a mutating operation but does not disclose side effects, requirements (e.g., valid fx_index), or response format. This is a significant gap for a setter 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?
The one-sentence description is concise with no fluff, but it is severely under-specified for a tool with four parameters. It restates the tool's name almost verbatim and does not earn its place as a useful explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (four required parameters, no annotations, and an output schema whose semantics are not described), the one-line description is completely inadequate. It fails to explain indexing conventions, value formats, or even that the FX must already exist, leaving the agent to guess.
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 input schema has four required parameters with zero descriptions (0% coverage), and the description adds no parameter explanations. The agent is left without any guidance on what values are valid or how parameters relate, making this dimension very weak.
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 'Set an FX parameter value' clearly states the action (set) and the resource (FX parameter), distinguishing it from related tools like get_fx_param or toggle_fx. However, it does not explicitly mention scope or differentiate from siblings by name, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 prerequisites such as needing an FX to exist on the track. The description provides no contextual usage information beyond the basic action.
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?
With no annotations, the description carries the full burden of behavioral disclosure. It merely restates the tool name and provides no context on consequences (e.g., index shifting), error behavior, or irreversibility. The word 'Delete' implies mutation but adds no transparency beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently conveys the core action, though it is under-specified in other dimensions.
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 simple delete operation, the description is too thin. It does not clarify the meaning or range of marker_index, nor any side effects. An output schema exists, but this alone does not compensate for the lack of parameter guidance and behavioral context.
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 schema has one required parameter (marker_index) with 0% description coverage. The description never mentions this parameter, leaving ambiguity about whether indexing is zero-based or one-based and which marker is targeted.
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 ('Delete a marker from the project') with a specific verb and resource. It distinguishes from sibling tools like delete_region by the resource type, but does not explicitly contrast with create_marker or other marker-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 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, index validity, or compare with related tools like delete_region. The agent must infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits beyond the fact that it creates something. It does not mention whether the operation overwrites existing markers, what units 'time' uses, what the return value indicates, or whether it is reversible. The description only states the intent without revealing side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant wording, making it concise and front-loaded. However, it is so sparse that it might be considered under-specified rather than efficiently written, so a small deduction is appropriate.
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 two parameters, zero annotations, and an output schema, the description must provide enough context for correct invocation. It does not explain parameter units, expected values, relationship to other tools, or any edge cases. The description is complete only in the most trivial sense.
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 to the 'time' (number) or 'name' (string) parameters. It leaves ambiguous whether 'time' is in seconds, milliseconds, or project beats, and whether 'name' is a required label or can be empty. The tool description fails entirely to compensate for the schema's missing parameter descriptions.
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 identifies the action (create) and target (marker) with a scope (in the project). This distinguishes it from sibling tools like create_region and delete_marker, though it doesn't elaborate on what a marker represents in the project.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 create_region or create_track. The description does not mention prerequisites, exclusions, or typical use cases, leaving the agent to infer when a marker is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get an FX parameter value' and omits important details such as parameter index base, matching behavior for param_name, error handling, or whether the value is returned as a number or string. These gaps are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundancy, making it highly concise. However, it is so terse that it borders on under-specification, missing useful details that could be included 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 three-parameter getter with an output schema, the description is incomplete. It lacks usage context, parameter semantics, and behavioral notes. The output schema may cover return format, but the description does not address other essential aspects of using the tool correctly.
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%, and the description adds no meaning to the parameters. It does not explain track_index, fx_index, or param_name, nor how they determine the returned value. The parameter names are somewhat self-explanatory, but the description fails to compensate for the lack of schema documentation.
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 ('Get') and the resource ('FX parameter value'), identifying it as a getter for a single FX parameter. It is distinguishable from sibling tools like set_fx_param (write) and get_fx_param_list (list all params), though it does not explicitly state 'single' vs. multiple values.
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 related tools like set_fx_param or get_fx_param_list, 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.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden of behavioral disclosure. Merely stating 'Set the project tempo' reveals no side effects, constraints, reversibility, or prerequisites. It does not indicate what happens if bpm is out of range, whether the operation is destructive, or if any confirmation is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence of five words with no filler or repetition. Every word earns its place, and it is effectively front-loaded with the action and resource.
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 low complexity and a single parameter, the description is inadequate for a tool with no annotations, no output schema, and zero parameter documentation. It fails to explain what 'project tempo' means, what bpm values are acceptable, or what the caller can expect after execution. The presence of an output schema (implied) is not leveraged.
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%, yet the description adds no meaning to the single 'bpm' parameter. It does not explain that bpm stands for beats per minute, nor provide any range or format guidance. The parameter semantics are entirely unimplemented.
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 ('Set') and resource ('project tempo'), clearly distinguishing from siblings like get_tempo (read) and set_time_signature (time signature). It is unambiguous and easily mapped to the intended 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that get_tempo should be used for reading the current tempo or that set_time_signature is for a different concept. No explicit contextual clues or exclusions 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 such as destructiveness, undoability, or side effects on project items. It simply states 'Delete a region' without addressing what happens to items within the region or whether the operation is destructive in a particular way. This is a minimal statement of 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 a single, direct sentence that is easy to parse and front-loads the primary verb. It is concise, though it sacrifices detail that might be expected for completeness.
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 an output schema but no parameter descriptions, the description is incomplete for an agent to use correctly—it doesn't explain how to obtain a valid region_index or any side effects. For a one-parameter tool, the parameter semantics gap is significant.
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 schema has no descriptions (0% coverage), and the description does not explain what 'region_index' refers to (e.g., zero-based vs one-based, or that it indexes into the region list). The parameter name is somewhat suggestive but lacks the necessary context for correct invocation.
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 the specific verb 'delete' and clearly identifies the resource ('a region') and the scope ('from the project'). This distinguishes it from sibling tools like create_region or delete_marker.
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 over alternatives, nor any prerequisites. For instance, it doesn't mention that the region must exist or that region indices come from get_region_list. The sibling tools imply context but 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?
With no annotations provided, the description carries the full burden for behavioral disclosure. It only states what the tool does, but does not mention that it is read-only, any side effects, limitations, or return behavior. The name implies a read operation, but the description adds no explicit 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 a single, front-loaded sentence with zero filler. It states the core purpose efficiently and has no unnecessary detail, making it highly concise and well-structured.
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 list tool with an output schema, the description is minimally adequate but lacks essential context. It doesn't specify what 'parameters' includes (names, values, metadata), nor does it clarify usage relative to sibling FX tools. While output schema may cover return values, the description misses opportunities to provide an agent with decision context.
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%, and the description does not explain the two required parameters (track_index, fx_index) or how they identify the target FX. The parameter names are somewhat self-explanatory, but the description adds no additional meaning beyond the schema's titles.
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 function: 'Get a list of all parameters for an FX.' The verb 'Get' and resource 'list of all parameters' are specific, and it distinguishes from get_fx_param (which implies a single parameter) by including 'all'. However, it doesn't explicitly compare with sibling tools or mention the required track/fx indices.
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 get_fx_param or set_fx_param. There is no mention of prerequisites, context, or exclusions, 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning range, side effects, or return behavior, which 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 a single clear sentence without redundancy. It is appropriately concise for a simple tool, though it could add a bit more detail 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?
While the tool is simple, the lack of parameter details or behavioral context makes it insufficient for correct usage. The output schema exists but does not negate the need for parameter semantics or usage guidance.
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 defines a single 'pan' parameter with no description, and the tool description does not elaborate on it, leaving the expected value range or format unspecified. With 0% schema coverage, the description should compensate but does not.
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 ('Set') and the resource ('the master track pan'), which distinguishes it from sibling tools like set_master_volume and toggle_master_mute.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided, such as when to use this tool versus alternatives, prerequisites, or exclusions. The description simply states what it does without any context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the core action without warning that this is a destructive, likely irreversible operation, nor does it explain behavior on invalid inputs or whether it affects other item properties. For a mutation tool, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple tool, though the conciseness comes at the cost of missing important 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?
Although an output schema exists (so return values may be described elsewhere), the description fails to provide essential context for this destructive tool: no parameter semantics, no usage guidance, and no behavioral warnings. It is complete only for the simplest 'what does it do' question, not for safely invoking the tool.
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 description provides no meaning for the two required parameters, item_id and track_index, and the schema description coverage is 0%. The agent gets no guidance on what these integers represent or how they relate to each other, leaving the agent to guess the correct invocation.
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 ('Clear') and a specific resource ('all MIDI notes from a MIDI item'), making the tool's exact function immediately clear. It clearly distinguishes itself from sibling tools like delete_item (which removes the whole item) or add_midi_note (which adds 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 when to use the tool: when you want to remove all MIDI notes from an item. However, it does not explicitly discuss when not to use it, such as for deleting only specific notes (which would use find_midi_notes_by_pitch and delete or similar), nor does it mention any prerequisites like having a valid track_index and item_id.
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 behavioral disclosure. It only explains input formats and does not describe what 'properties' are returned, error conditions, or whether the operation has any side effects. The 'get' verb implies read-only, but no additional context is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise and structured with a heading and bullet-point style. However, there is slight redundancy where item_id is described both in the list and in the args block, which could be tightened.
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, the description covers the necessary input identification well. But it lacks information about the output format (despite an output schema existing) and does not provide usage context or alternatives. It is adequate but leaves gaps in behavioral and usage 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, so the description must compensate. It thoroughly explains both parameters: track_index as 'Index of the track' and item as either an integer track_pos_idx or string direct_item_id, with examples. This provides meaningful context beyond the bare schema types.
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 'Get properties of a media item', specifying the verb and resource. It is distinct from sibling tools by focusing on item properties, though it doesn't explicitly differentiate from other item-specific getters like get_item_position or get_item_length.
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. It explains how to identify items (via track_pos_idx or direct_item_id) but does not mention any exclusions or when this tool is preferred over similar getters.
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 destructive effects. 'Remove' implies deletion, but it does not state whether removal is permanent, what happens to parameter automation, whether FX indices shift after removal, or any error conditions. This is a significant transparency gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no fluff. It front-loads the action and object, making it easy to parse, though it trades away behavioral detail.
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 parameter descriptions, and the presence of sibling FX tools, this description is too sparse for full contextual understanding. It does not cover destructive semantics, index conventions, or use-case context, but the output schema may cover return values.
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 adds no parameter details. It does not explain whether indices are zero-based, how track_index is resolved, or how fx_index maps to the FX chain. The parameter names are self-explanatory but add no semantic 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 uses the specific verb 'Remove' and identifies the resource as 'FX' on a 'track', clearly distinguishing it from sibling tools like add_fx or toggle_fx. It is concise 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 guidance is given about when to use this tool versus alternatives such as toggle_fx (which likely enables/disables rather than removes) or get_fx_list. The description only states the operation, with no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states the action without mentioning read-only nature, performance implications, or operating requirements. No additional context beyond the tool's basic function is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that communicates the tool's purpose without any waste. It is appropriately sized for a simple listing operation.
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 is simple with no parameters and has an output schema, so the description doesn't need to detail return values. However, it lacks any context about how this differs from get_fx_list or whether it requires a running Reaper project, making it minimally 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 tool has zero parameters and the schema is empty, so there are no parameter semantics to document. According to the rubric, a zero-parameter tool receives a baseline score of 4.
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 function: obtaining all available FX plugins in Reaper. The verb 'Get' and resource 'all available FX plugins' are specific. However, it does not explicitly differentiate from sibling tool get_fx_list, which could also list FX plugins, albeit likely per-track.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 like get_fx_list or add_fx. There is no mention of prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 says 'Get information' which implies a read-only operation, but does not disclose return format, potential errors, or any other behavioral characteristics. This is minimally 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 a single short sentence, front-loaded with the verb and resource, containing no redundant phrases. Every word contributes to the core meaning.
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 presence of an output schema reduces the need to describe return values, but the description still leaves 'information' undefined. For a master track getter, the agent would benefit from knowing whether it returns all properties or a specific subset. The description is adequate but has a clear gap in scope.
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 input schema is empty, so there is nothing to explain. The description's reference to 'the master track' adds context but aligns with the tool name. Baseline for 0 params is 4.
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 uses the specific verb 'Get' and identifies the resource as 'the master track', clearly distinguishing it from sibling getters that target other tracks or properties. However, 'information' is vague and does not enumerate which properties are returned, so it is not fully specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 like get_track_color or set_master_volume. It simply states what it does without any context about prerequisites, use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It only says 'Get', implying a read operation, but doesn't mention return format, possible errors, or any nuances about what 'default' means. No side effects are disclosed (though likely none).
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, perfectly sized for a simple getter operation. It conveys the essential information without any fluff or repetition.
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 is simple (0 params) and has an output schema, which lessens the burden on the description. However, the description is incomplete in that it doesn't differentiate from the sibling get_time_signature or clarify what 'default project time signature' means versus a general time signature. No return details are given, but the output schema may cover that.
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 takes no parameters (0 params, 0 required), so the baseline is 4 as per the rubric. The description correctly doesn't attempt to explain nonexistent parameters, and no additional semantic guidance is 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 clearly states the action ('Get') and the target resource ('default project time signature'). It distinguishes itself from siblings like get_time_signature by specifying 'project' and 'default', but doesn't explicitly explain the difference from get_time_signature, which could be ambiguous.
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 get_time_signature or set_project_time_signature. The description gives no context for selection 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Set' without revealing side effects, reversibility, or what 'default' means for existing items or future changes. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the core action in the first sentence and clearly listing arguments with brief explanations. 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 simple two-parameter setter, the description provides a minimal viable level of detail. However, it leaves ambiguity about what 'default' implies and does not clarify how this relates to the sibling 'set_time_signature'. The existing output schema may cover return values, but behavioral side effects are unaddressed.
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 explicitly defines both parameters with real-world examples ('4 in 4/4'), which is essential given the schema has no descriptions and 0% coverage. It compensates well, though it does not include constraints like valid ranges or denominator power-of-two requirements.
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 uses a specific verb ('Set') and a specific resource ('the default project time signature'), which makes the tool's purpose clear. However, it does not explicitly distinguish this tool from the sibling 'set_time_signature', so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 like 'set_time_signature' or 'get_project_time_signature'. The description provides no contextual framing or exclusionary statements, 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?
The description indicates a mutating operation but does not explain the exact behavior when the 'solo' parameter is null versus a boolean. It does not mention side effects, return values, or any additional behavioral traits. With no annotations provided, the description carries full burden but provides only minimal 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 a single, concise sentence. It is front-loaded with the action and resource, and every word contributes to the meaning. No unnecessary detail or repetition.
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 one optional parameter, the description is minimal but adequate for basic understanding. However, it omits the crucial distinction between toggling and setting, leaving the parameter behavior ambiguous. Given existing output schema, return values are not needed, but the tool docs still lack important contextual guidance about parameter semantics.
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 tool description adds no explanation of the 'solo' parameter. The mapping between null (toggle) and boolean (set) is not described, leaving the parameter meaning entirely to inference. The description fails to compensate 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's action ('Toggle or set') and its resource ('the master track solo state'). It distinguishes this from sibling tools like toggle_master_mute by naming the specific track and property being modified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of conditions for toggling versus setting, nor any reference to sibling tools for other master track controls. The usage context is purely implicit in the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It does not disclose behavioral details such as whether the returned list includes disabled FX, the order of FX, or what error occurs if the track_index is invalid. The description adds minimal context 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 a single, clear sentence with no redundant words. It is appropriately sized for the tool's simplicity and front-loads the essential 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?
Given the simple nature of the tool (one parameter, output schema available), the description is mostly complete. It clearly states the action and object. However, it lacks explicit guidance on prerequisites or relationship to sibling tools, slightly reducing completeness.
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% and the description does not mention the track_index parameter. The schema only provides type and required flag, leaving ambiguities like zero-based indexing and how to obtain a valid index (e.g., from get_track_list) undocumented.
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 a list of all FX on a track' with a specific verb (Get) and resource (FX on a track). It distinguishes this from sibling tools like get_available_fx_list (which lists available plugins) and get_fx_param_list (which lists parameters).
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 get_available_fx_list or get_fx_param_list. The description only states what the tool does, leaving the use case 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states that the tool sets the volume but does not explain the effect on current volume, units, or range. This is a significant transparency gap for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no filler. It is appropriately concise for the tool's simplicity and front-loads the key action and target.
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 low schema coverage and missing annotations, the description is too sparse. It omits critical details like volume scale (e.g., 0.0–1.0, dB) and does not clarify whether the value is absolute or relative. The output schema exists, but that does not compensate for the lack of parameter context.
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 zero description coverage for the 'volume' parameter, and the description does not compensate. It simply repeats the word 'volume' without explaining its meaning, units, or accepted range. The description fails to add 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 'Set the master track volume' clearly identifies the action (set) and the resource (master track volume). It is unambiguous and distinguishes itself from sibling tools like 'set_master_pan' and 'toggle_master_mute'.
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?
Usage context is implied by the tool's name and description, but there is no explicit guidance about when to use it or alternatives. It does not mention any exclusions or prerequisites, such as acceptable volume values or whether the track must exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states that the tool toggles or sets an FX's enable state, but it does not explain the difference when the 'enable' parameter is null versus a boolean, how invalid indices are handled, or what the output/return value looks like. This is insufficient for a mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 12 words that directly states the tool's purpose. Every word is informative, with no redundant or vague filler, earning a perfect score for 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 zero annotations, 0% schema description coverage, and the presence of an output schema, the description is too sparse to fully support correct invocation. It lacks essential details such as toggle/set semantics, index conventions, and behavior in edge cases, leaving the agent to guess at critical aspects.
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 clarifies that the tool can toggle or set the enable state, giving some meaning to the 'enable' parameter, but it leaves 'track_index' and 'fx_index' undefined—no indication of indexing base, bounds, or expected format. The partial clarification is not enough.
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 or set') and the resource ('enable/disable state of an FX'), which is specific enough to distinguish this from sibling tools like add_fx, remove_fx, and set_fx_param. It precisely communicates the tool's core function.
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 enabling, disabling, or toggling FX state, but it provides no explicit guidance on when to prefer this tool over alternatives, nor does it mention any exclusions or prerequisites. The context from sibling names is not leveraged in the 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?
With no annotations, the description carries the full burden of behavioral disclosure. It states the operation is 'set' (implying mutation) but does not disclose potential side effects, error behavior on invalid track_index, or the expected color format. It also doesn't clarify if the operation can be undone or if it requires special permissions. This minimal disclosure leaves the agent unsure about consequences.
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 core purpose in the first sentence. The 'Args:' section is slightly redundant with the input schema but serves to explain parameter semantics. No unnecessary filler; each 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?
For a simple setter with two parameters and an output schema, the description is minimally adequate but lacks crucial details. The color parameter's format is unspecified, which could cause misuse. The tool's behavior on out-of-range track_index is also unclear. Given the low schema coverage and absence of annotations, the description does not fully compensate for these gaps.
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 valuable meaning to track_index by explaining it is 0-based with examples, which goes beyond the schema's bare integer type. However, color is only described as 'Color value,' providing no additional context about the acceptable format (e.g., hex string, RGB tuple). Since schema coverage is 0%, the description partially compensates but leaves a significant gap for the color 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 the tool's function with a specific verb and resource: 'Set the color of a track.' This distinguishes it from sibling tools like get_track_color (which retrieves) and rename_track (which changes a different property). The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when you want to change a track's color, but it does not explicitly state when to use it versus alternatives like get_track_color. No exclusions or prerequisites are mentioned, such as requiring an existing track or using get_track_color to verify the change.
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?
There are no annotations, so the description carries the burden. It only states the getter action without discussing return format, error conditions, or confirming it's a safe read. Yet for a simple getter, the behavioral disclosure 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, efficiently front-loaded, 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?
The description is adequate for a simple 0-param getter with an output schema, but it fails to mention the relationship to get_project_time_signature, leaving a gap in contextual 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 zero parameters, so the baseline is 4. The description adds no parameter semantics, but that's not 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 clearly states the tool gets the project's current time signature with a specific verb and resource. However, it doesn't distinguish itself from the sibling tool 'get_project_time_signature', which likely performs the same function.
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 context or alternatives are mentioned. The description doesn't explain when to prefer this over the similarly named sibling or indicate any preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It adds useful detail about 0-based indexing, but it does not state what happens for invalid indices, whether the operation is strictly read-only (other than the 'get' implication), or any error behavior. For a simple getter, this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly efficient: a single sentence stating the purpose, followed by a direct parameter explanation. There is no redundancy or fluff, and the core information is front-loaded.
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 existence of an output schema, the return format is already handled. The description adequately covers the tool's purpose and the critical input semantics. A minor gap is the lack of error-handling behavior for out-of-range indices, but overall it is sufficient for a simple getter 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 schema provides only the type and title for track_index with no description (0% schema coverage). The description fully compensates by explaining the parameter as '0-based track index (0 = first track, 1 = second track, etc.)', giving the agent precise semantics beyond the structured data.
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' and the resource 'track color', making the tool's purpose unambiguous. It distinguishes this tool from siblings like set_track_color, get_track_count, and get_track_list, which perform different operations 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 Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool, prerequisites, or alternatives. There is no mention of when one might prefer get_track_list or get_track_color, nor any constraints or exclusions. The agent is left without direction 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?
There are no annotations, so the description bears full responsibility for disclosing behavior. 'Test connection' implies a non-destructive read-only check, but it does not state what happens on success or failure, whether it throws exceptions, or what the output represents. The description adds minimal behavioral context beyond what the tool name already implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single five-word sentence with no fluff. It is front-loaded and every word earns its place, delivering the core purpose without unnecessary elaboration. For a zero-parameter tool, this is appropriately sized.
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 extreme simplicity (no parameters, no annotations, and an existing output schema), the description is nearly complete for its intended purpose. It would benefit from a brief statement about the successful/failed connection result, but the output schema likely covers return values, so 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?
This tool has zero parameters and the schema coverage is 100%, so there is nothing for the description to add about parameter meaning. The baseline for zero-parameter tools is 4, and the description does not need to elaborate further.
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 ('Test') and a clear resource ('connection to Reaper'), making its purpose immediately obvious. It also stands apart from all sibling tools, which focus on tracks, regions, MIDI, and other DAW operations, so there is no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 explain that this should be a first-step connectivity check or mention any conditions where another tool would be more appropriate. With no exclusions or context, the agent is left to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states the destructive action without elaborating on irreversibility, side effects on the project, or error handling, leaving significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose, followed by a focused, well-structured explanation of item identification. The minor redundancy between the bulleted list and the Args block does not detract significantly.
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 delete tool with two parameters and an output schema, the description covers the essential invocation details. However, it lacks context about side effects, undo behavior, or when to prefer this tool over siblings, leaving it only minimally 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 schema has no parameter descriptions (0% coverage), but the description fully compensates by explaining both parameters: track_index as the track's index, and item as either an integer track_pos_idx or a string direct_item_id, with concrete examples for each.
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 with a specific verb and resource: 'Delete a media item from a track.' This distinguishes it from sibling deletion tools like delete_region and delete_marker, which target different resources.
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 when to use the tool (when you need to delete a media item) and explains the two accepted item identification methods, but it does not explicitly mention alternatives or when not to use it, such as pointing to delete_region or delete_marker for other object types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden. It communicates that the search is non-local ('across the project'), but it does not disclose behavioral details such as whether the pitch range is inclusive, how results are ordered, or any performance implications. As a read-only find operation, the risk is low, but the description adds no extra disclosure beyond the stated scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no filler or redundancy. It front-loads the action and resource, making it immediately understandable.
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 with two parameters and an existing output schema, so the description does not need to detail return values. It captures the essential purpose and project-wide scope, but it lacks usage guidance and parameter bound details that would make it fully self-contained. Given the simplicity, this is nearly complete.
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 for parameter meaning. It mentions 'pitch range' but does not explain that pitch_min and pitch_max correspond to the lower and upper bounds, nor does it convey the valid MIDI pitch range (0-127) or that the parameters default to 0 and 127. The parameter names are self-descriptive, but the description adds little meaningful 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?
The description states a specific verb ('Find'), a clear resource ('MIDI notes'), and a defining scope ('within a specific pitch range across the project'). This distinguishes it from sibling tools like get_midi_notes, which likely operate on a single MIDI item rather than project-wide by pitch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching notes by pitch across the whole project, but it does not explicitly state when to use it over alternatives like get_midi_notes, nor does it mention exclusions or prerequisites. The context is clear enough to infer when it applies, but not stated as a guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does add context by listing the supported file formats and explaining the mutual exclusivity between time and measure-based start/end parameters. However, it omits side effects (e.g., file overwriting), required project state, error behavior, and any confirmation of the render result. These gaps are notable for a tool that creates a file and may involve lengthy processing.
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 one-sentence purpose followed by a compact Args list. It avoids fluff and front-loads the essential information. The only minor issue is the slightly messy formatting of the file format list (trailing spaces, odd codes), but this does not detract from overall clarity.
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 gives thorough parameter semantics, which is the core requirement for a render tool. However, it lacks situational context: no mention of prerequisites (like an open project), whether the output file is overwritten, or what the tool returns. Since an output schema exists, return details are covered, but the absence of annotations makes the missing behavioral context more noticeable. Overall, it is adequate but not fully complete for a tool with eight parameters and no annotation shortcuts.
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 is the only source of parameter meaning. It explains every parameter: output_file is a path, start_time/end_time are in seconds, start_measure/end_measure use 'measure:beat,fraction' format, and file_format lists all valid values. The optional relationships between time and measure parameters are clearly spelled out, going well 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's function with a specific verb and resource: 'Render project to audio file.' This uniquely distinguishes it from all sibling tools, which focus on track, item, or parameter manipulation. No ambiguity remains about what the tool accomplishes.
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, nor any exclusion criteria. While the name implies its purpose, the description does not explicitly state usage context such as 'use this to export a final mix' or mention that it is the only rendering tool. Parameter constraints are detailed, but these are parameter semantics, not usage guidelines.
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 disclosing behavior. It explains that times are in seconds and measures use 'measure:beat,fraction', and hints that start_time/end_time are optional if the corresponding measure is provided. However, it does not clarify behavior when both time and measure are supplied, or what happens if neither is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by a structured Args list. It avoids unnecessary prose, though the parameter list duplicates schema field names in a way that is acceptable but not minimal.
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 has 5 parameters, no annotations, and no schema descriptions. The description covers the parameters well and provides an output schema, so return values are not needed. However, it lacks explicit guidance on tool selection and leaves some ambiguity around the exact start/end position requirements, making it slightly 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?
Schema description coverage is 0%, and the description compensates by adding units ('seconds', 'measure:beat,fraction') and dependency information for all five parameters. This is meaningful and goes beyond what the schema provides, though it could be more explicit about 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 states 'Create a region in the project' with a specific verb and resource. It clearly distinguishes from sibling tools like delete_region and get_region_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (creating a region) and provides parameter-level guidance (e.g., 'optional if start_measure is provided'), but it does not explicitly explain when to choose this tool over alternatives or mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description must disclose behavioral aspects. It does detail the return structure with property names, which is helpful, but it does not explain the 'status' field, behavior when no items are selected, or any side effects. This leaves notable gaps in behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single clear sentence stating the purpose, followed by a useful list of return fields. Every part adds value and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fairly complete for a simple getter: it fully specifies the return structure and properties. However, it omits context about the 'status' field and edge cases like an empty selection, and it does not mention any prerequisites or state, so it is not a 5.
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 schema already provides complete parameter semantics. The description adds no parameter details, but none are needed. A baseline of 4 is appropriate 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 that the tool retrieves all selected media items along with their properties. It distinguishes itself from sibling tools like 'get_selected_midi_item' by covering all media items, not just MIDI, and from 'get_items_in_time_range' by focusing on selection rather than time range.
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 'get_selected_midi_item' or 'get_items_in_time_range'. The intended use is implied by the name but not explicitly stated, and no exclusions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 conveys the two modes (toggle when no parameter, set when provided) but does not explain what 'toggle' means precisely (e.g., reverses current state) or any side effects. Minimal but not misleading.
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, grammatically clear sentence that front-loads the action. No filler or redundant information, making it highly concise and well-structured.
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 optional parameter and an output schema, the description covers the essential behavior. It lacks a brief note on what the toggle does exactly (e.g., 'reverses current state'), but given the simplicity and existing schema, it is sufficiently 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 the description must compensate. It adds meaningful semantics by explaining that the optional 'mute' parameter either toggles (when null/absent) or sets the state (when boolean). This goes beyond the bare schema and clarifies how the parameter controls behavior.
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 toggles or sets the master track mute state, using a specific verb and resource. It distinguishes from sibling tools like toggle_master_solo or set_master_volume by targeting the mute property of the master track specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The description only states the action without mentioning prerequisites, exclusions, or alternative tools, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior, but it only states that it duplicates an item and describes identifiers. It does not explain what happens to the original item, where the duplicate is placed if no new_time/new_measure is given, whether the duplicate is selected, or any other side effects, leaving significant 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 front-loaded with a clear one-sentence purpose and then organized into sections. However, the item identification information is repeated: 'track_pos_idx (integer)' and 'direct_item_id (string)' appear in the Item Identification section and then are restated in the Args list, adding some 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 has an output schema, so return values don't need describing, but the description leaves ambiguities about the interaction of new_time and new_measure (e.g., which takes precedence) and the default duplicate position when neither is supplied. It also gives no error or edge-case guidance. Overall it's mostly complete but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions, so the description compensates fully: it explains track_index as the track index, item_id as either an integer track position or a string internal ID with examples, new_time as seconds, and new_measure using a 'measure:beat,fraction' format. This gives the agent necessary 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's action: 'Duplicate an existing item on a track.' This is a specific verb and resource, distinguishing it from sibling tools that create, delete, or query 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 gives clear context on how to identify items (track_pos_idx or direct_item_id) and how to set the new position via optional times. However, it does not explicitly discuss when to use this tool over alternatives or any exclusions, though none are obvious.
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 the full burden of behavioral disclosure. It explains item identification and length formats, but does not state whether setting the length mutates the item destructively, what happens if both length_time and length_measure are provided, or what error conditions exist (e.g., nonexistent track/item). This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the main purpose, followed by compact bullet lists for item identification and arguments. It is appropriately sized for the tool's complexity, though a minor typo ('item(optional') and slight redundancy ('from start of item') could be cleaned up.
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 4 parameters with dual ID types and optional length specifications, the description covers the core usage patterns well. However, it omits edge cases such as behavior when neither length_time nor length_measure is supplied, or when both are supplied. The output schema exists, so return values are handled externally, but behavioral edge cases remain unaddressed.
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%, and the description fully compensates by clearly explaining track_index, item_id (including both valid types), length_time (seconds from start), and length_measure (measure:beat,fraction format). It also clarifies the optional relationship between length_time and length_measure, which is impossible to derive from the schema alone.
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 begins with 'Set the length of a media item,' a specific verb+resource combination that clearly defines the tool's function. It also distinguishes itself from sibling tools like set_item_position (which deals with position) by specifying 'length' as the target attribute.
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 for when to use the tool: whenever you need to change a media item's length. It also explains how to specify length via two alternative parameters (length_time and length_measure) and how to identify items using either an integer index or a string ID. It does not explicitly mention alternatives or exclusions, but the scope is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It discloses the 'first' behavior but does not specify what happens when no item is selected or clarify the ordering criterion. This is a minimal addition 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 a single, clear sentence that directly states the operation. No redundant information, and the key details are front-loaded.
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, the description is mostly complete. It could clarify what happens when there is no selection or define 'first' more precisely, but the output schema covers return values, so the gap is minor.
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 there is nothing to document. The description does not need to add parameter semantics, aligning with the baseline score of 4 for parameterless 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 uses a specific verb 'Get' and a specific resource 'the first selected MIDI item in the project', clearly distinguishing it from siblings like get_selected_items which returns all selected items. The scope is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit alternatives are mentioned. The description implies usage when a single MIDI item is needed from the current selection, but it does not state when not to use it or mention the sibling get_selected_items for multiple items.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It indicates a read-only action ('Get'), which implies no side effects, but it does not explicitly state that it does not modify the project or require any special permissions. For a simple getter, this is minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no wasted words. It is front-loaded with the verb and resource, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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) and that an output schema exists, the description is adequately complete. It defines the purpose clearly, and the output schema covers return values, so the lack of detail 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 tool has zero parameters, so the baseline is 4. The description correctly adds no parameter information because none exist, and the input schema confirms this.
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: 'Get the current project tempo.' It uses a specific verb ('get') and resource ('current project tempo'), distinguishing it from sibling tools like set_tempo and get_time_signature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you need the project tempo), but it does not explicitly mention alternatives or exclusions. Since it is a simple getter, context is somewhat clear, but no guidance is given about when not to use it or when to use related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clarifies the relationship between start_time and start_measure and their formats, but does not disclose what happens if both or neither are provided, nor mention file format validation or failure modes. This is a moderate but incomplete disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a single-sentence purpose followed by a brief Args list. Every line adds valuable information; no fluff or repetition. It is appropriately front-loaded with 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?
The tool is relatively simple, and the description covers purpose, parameters, and some behavior. However, the mutually exclusive nature of start_time/start_measure is only implied, not explicitly stated, and the default behavior when both are omitted is missing. Given no annotations, these gaps leave the description slightly incomplete for an 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's Args section explicitly defines all four parameters, including units for start_time ('seconds') and the exact format for start_measure ('measure:beat,fraction'). It also explains optionality conditions, adding 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 uses a specific verb 'Insert' with a clear resource ('audio file as a media item') and target ('on a track'). This distinctly separates it from siblings like create_midi_item, which handles MIDI instead of audio.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the resource type ('audio file'), which contrasts with MIDI-oriented siblings, but no explicit alternatives or exclusions are mentioned. It does provide parameter usage guidance (start_time vs start_measure optionality), but not tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explains the accepted item ID types and the measure:beat,fraction syntax, which is helpful. However, it does not disclose behavior when both position_time and position_measure are provided, what happens on invalid inputs, or any side effects. This is partial behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with a one-line summary, an 'Item Identification' section, and an 'Args' section. It is reasonably concise, but there is redundancy: the item identification section repeats the info in the item_id parameter explanation. Minor confusion with track_pos_idx as a non-parameter name, but overall it 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?
The description covers all four parameters and their optionality, which is good given the tool has moderate complexity. It does not clarify precedence when both position_time and position_measure are supplied, and it omits error behavior. Since an output schema exists, the description doesn't need to cover return values. Overall, it is fairly complete but with some edge-case gaps.
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 fully. It does: track_index is defined as 'Index of the track', item_id as 'EITHER integer track_pos_idx OR string direct_item_id', position_time as 'New position in seconds', and position_measure with an explicit format and example. This adds significant meaning beyond the plain 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 opens with a clear, specific statement: 'Set the position of a media item.' It specifies the resource (media item) and the action (set position), distinguishing it from sibling tools like set_item_length. Additional details about item identification methods further clarify the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on how to use the tool, including two item identification methods and two position formats, but it never mentions when to prefer this tool over alternatives or when not to use it. For example, it doesn't compare with get_item_properties or set_item_length. Usage context is implied but no explicit exclusions or alternatives are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently conveys a read-only operation that returns a count. Since no annotations are provided, the description carries the burden, and for this simple getter it is sufficient, though it does not specify nuances like whether the master track is included.
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, front-loaded sentence with no filler. Every word 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?
For a simple tool with no parameters and an output schema already present, the description fully covers the purpose. No additional context or disambiguation is 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?
The tool has no parameters, so the baseline is 4. The description adds context by specifying that the count is for tracks in the project, which is clear and sufficient given the zero-parameter 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 gets the number of tracks in the project, using a specific verb and resource. It implicitly distinguishes from the sibling get_track_list by indicating a count rather than a 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 is provided on when to use this tool versus alternatives like get_track_list. The description does not mention usage context, exclusions, or criteria for choosing this tool over other track-related 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 carries the full burden. It discloses the position format and the optionality of position/time, but does not explain side effects, error conditions, or whether the change is reversible. This covers the basic operation but leaves behavioral details unstated.
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 Args section, each line earning its place. It uses examples to clarify formats without unnecessary fluff, making it both concise and informative.
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 setter tool with no annotations, the description covers all parameters and presents clear examples. It does not discuss return values (though an output schema exists) or project-level alternatives, but overall it provides sufficient context for basic use. A small gap is the lack of explicit distinction from set_project_time_signature, but the 'at specified position' phrase partially addresses this.
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 every parameter with examples (e.g., numerator/denominator in 4/4, position format '1:1,500'), fully compensating for the 0% schema description coverage. It adds significant meaning beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a time signature at a specified position, which distinguishes it from sibling tools like set_project_time_signature that operate at the project level. The verb 'set' plus the resource 'time signature' and the scope 'at specified position' provide a precise purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the phrase 'at specified position' but does not explicitly contrast with alternatives such as set_project_time_signature. It does give usage guidance for parameters (position/time optionality) but lacks when-to-use versus sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It adds valuable behavioral context by explaining the 0-based vs 1-based indexing discrepancy between the API and REAPER UI. However, it does not address error handling (e.g., invalid track_index) or potential side effects beyond the rename itself.
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 appropriately sized: a one-line summary followed by a structured Args block. Every sentence serves a purpose with no redundancy or filler. The layout is clear and easy to scan.
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 (rename operation) and the presence of an output schema, the description covers the essential aspects: purpose, parameter semantics, and the key indexing nuance. It could be improved by adding usage alternatives or notes on error behavior, but it is largely complete for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates with detailed parameter explanations. The track_index parameter is thoroughly described, including the UI mapping, while new_name is given a brief but adequate description. This goes well beyond the schema's basic type 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 'Rename an existing track' with a specific verb and resource. This distinguishes it from sibling tools like create_track and set_track_color, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for renaming existing tracks via the phrase 'existing track', but it does not explicitly discuss when to use this tool versus alternatives or mention any exclusions. The sibling list includes other track operations, but no comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that track_pos_idx 'may become invalid if items are deleted/reordered,' discloses the default relative_start behavior, and warns about extending notes beyond item bounds. It doesn't mention error handling or reversibility, but the key behavioral traits are covered 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 well-organized with bold sections, bullet points, and a concrete example. It is longer than strictly necessary, but the structure makes it easy to scan. Every major section earns its place, though the Args list could have been more succinctly mapped to the actual parameter names.
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 has an output schema (not shown), so return values don't need explanation. The description covers item identification, parameter formats, and critical constraints (item length). It lacks details about atomicity, partial failure behavior, or how the track_index relates to item extraction, but for a MIDI editing tool, the description is quite 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 description compensates for 0% schema coverage with extensive parameter details, including note fields (pitch, start_time, length_measure, etc.) and an example. However, there is a significant naming mismatch: the schema declares a parameter named 'item,' but the description's Args section refers to 'track_pos_idx' as the parameter name. This could confuse the agent about which schema field to populate. Additionally, relative_start is only mentioned as a per-note override, not clearly as a top-level 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 begins with a specific verb and resource: 'Add multiple MIDI notes to a MIDI item in one operation.' It clearly distinguishes itself from the sibling tool add_midi_note (singular) by emphasizing 'multiple' and 'one operation.' This provides unambiguous purpose and 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 gives explicit usage guidance, including an important prerequisite warning about checking MIDI item bounds before adding notes. It also details two item identification methods and recommends when to use each: 'Use track_pos_idx for quick scripts, direct_item_id for reliability.' This is clear when-to-use guidance with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the return format (Dict with status and a list of regions containing index, start, end), which is meaningful behavioral context. It does not mention edge cases like empty lists or error handling, but for a simple getter 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?
The description is concise and well-structured: a one-sentence purpose followed by a bulleted return format. Every line earns its place with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, simple read-only operation with an existing output schema and a clear return format description, this is complete. No additional context about state changes or prerequisites is 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?
The tool has zero parameters (schema is empty), so baseline 4 applies. The description correctly does not need to compensate for missing parameter semantics, as 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 clearly states 'Get a list of all regions in the project' with a specific verb and resource, and distinguishes itself from mutation siblings like create_region/delete_region. It is unambiguous and scoped correctly.
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?
Usage is implied by the read-only nature and function name, but there is no explicit guidance on when to use this versus alternatives like get_track_list or other list/query tools. No exclusions or alternative comparisons are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the tool creates an empty item, returns two referencing mechanisms, and warns about overlapping items. It does not mention undo behavior, auth requirements, or exact behavior if both start_time and start_measure are provided, but the essential side effects are 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 front-loaded with the core purpose, followed by an important warning, return value documentation, and parameter details. It is somewhat long, especially the length_measure explanation, but the complexity of the measure format justifies the length. No content is redundant.
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 five parameters, no annotations, and an output schema, the description covers nearly everything needed: parameter semantics, return values, and a usage caution. A notable gap is that it doesn't state what happens if both start_time and start_measure (or neither) are supplied, since only track_index is required in the schema. Overall, it is complete enough for correct 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 must compensate for all parameters. It fully explains track_index (including 0-based vs UI labels), start_time, start_measure (with format 'measure:beat,fraction'), length_time, and length_measure (with detailed examples). This is far beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Create an empty MIDI item on a track.' This clearly distinguishes the tool from siblings like insert_audio_item, create_track, and add_midi_note, and also explains the returned IDs, reinforcing its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: it returns IDs for 'subsequent operations like add_midi_note,' implying this is the first step before adding notes. It also warns against creating overlapping items. However, it does not explicitly name alternatives (e.g., duplicate_item or insert_audio_item) or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the burden of behavioral disclosure. It explains the important distinction between visible and invisible notes, the default filtering, and playback implications. It also clarifies the dual item identification schema. Return format is not mentioned but is covered by output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with the core purpose, but it repeats the invisible-notes concept twice and the item_id type explanation twice. Minor redundancy prevents a perfect score.
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 read-oriented tool with an output schema, the description covers the key context: purpose, default behavior, item identification, and parameter effects. It lacks potential error scenarios or explicit when-to-use guidance, but overall it is sufficiently complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description fully compensates by explaining track_index, item_id (including the dual integer/string types), and include_invisible with its default and effect. Concrete examples for item_id formats are provided, adding 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 retrieves all MIDI notes from a MIDI item, using the specific verb 'get' and resource. It distinguishes itself from sibling tools like find_midi_notes_by_pitch by focusing on full note retrieval, and the visible/invisible note detail adds clear 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?
It provides clear context on how to use the tool, including the two item identification methods and the include_invisible flag, but it does not explicitly contrast with alternatives such as find_midi_notes_by_pitch. The context is sufficient for an agent to know when to use it, but exclusions are not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure burden. It provides valuable behavioral detail about the two identification methods (track_pos_idx vs. direct_item_id) and their stability characteristics. However, it does not disclose edge-case behaviors such as boundary inclusivity or what happens when no time range is 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?
The description is well-structured with clear sections for the main action, ID semantics, arguments, and returns. Every sentence adds value, and the bulleted explanation of ID methods is concise yet informative.
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 return format, parameter meanings, and usage guidance effectively. However, it omits some edge-case behavior (e.g., overlap vs. containment, missing range) that an agent might need to know for unambiguous invocation. Overall, it is fairly complete for a read-only 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 must compensate. It fully documents all five parameters, including the measure string format 'measure:beat,fraction' and the optionality relationships between time and measure arguments. This adds essential meaning beyond the raw 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 states 'Get all items on a track within a time range' with a specific verb and resource scope. It clearly differentiates from sibling tools like get_selected_items or get_item_properties by specifying the track and time-range filtering.
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 that returned IDs can be used in subsequent operations like add_midi_note, giving a concrete use case. However, it does not explicitly mention alternatives or when not to use this tool, though the context is strong enough to guide an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral transparency. It discloses the return structure (dict with status and list of tracks), includes field details (index, name, color), and notes the conditional nature of color ('if available'). This is meaningful context beyond the empty schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one main sentence plus a bulleted return format. It is front-loaded with the primary action, and every detail (return format, fields) is useful and non-redundant.
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) and the presence of an output schema, the description adequately covers what the agent needs: purpose, return structure, and field meanings. It is complete for a straightforward list operation.
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 schema is empty and 100% covered. No parameter descriptions are needed. The baseline for 0 params is 4, and the description appropriately focuses on return values instead.
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 with a specific verb and resource: 'Get a list of all tracks in the project.' It distinguishes itself from siblings like get_track_count (count only) and get_track_color (single track) by specifying '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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool when you need the full list of tracks. It doesn't explicitly mention alternatives or exclusions, but the scope ('all tracks') makes usage clear relative to track-specific or count-based siblings.
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 carries the burden of behavioral disclosure. It explains important nuances: REAPER format conversion, notes positioned before the item won't be added, and the critical distinction between absolute and relative positioning. It also documents that item identification can be unstable with track_pos_idx but stable with direct_item_id, providing essential 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but well-structured with sections, headers, and bullet points. It uses clear formatting to separate the item identification method from positioning notes. While some sentences could be tightened (e.g., the 'Important' paragraph repeats some content), the detail is mostly necessary given the complexity of the tool. It is appropriately front-loaded with the core purpose and critical warnings.
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 9 parameters, no schema descriptions, and no annotations, the description is remarkably complete. It covers all parameters, edge cases like item bounds, position validation, and format conversion. It even explains the output schema indirectly via the item identification examples. There is no missing information needed for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It does so thoroughly by explaining every parameter: track_index (with UI vs API indexing note), item (both forms), pitch, start_time/start_measure (absolute positioning), length_time/length_measure (with nuance on measure format), velocity, and relative_start. It gives concrete examples for ambiguous parameters, making the tool highly usable.
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: 'Add a MIDI note to a MIDI item.' It distinguishes itself from the sibling 'add_midi_notes' (plural) by focusing on adding a single note. The specific verb 'add' and resource 'MIDI note' provide clear purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives detailed usage guidance, such as checking item length, ensuring the note doesn't extend beyond item bounds, and verifying item position. It also explains the two methods for identifying the item (track_pos_idx vs direct_item_id). However, it does not explicitly contrast with the sibling tool add_midi_notes, which could create ambiguity about when to use the singular vs plural version.
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/wegitor/reaper-reapy-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server