ReaMCP

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap in MIDI and envelope editing tools that could cause confusion. For example, 'set_midi_note' and 'set_midi_notes' are very similar, and 'insert_envelope_point' vs 'insert_envelope_point_at_beat' differ only in timing units. Descriptions help clarify, but an agent might misselect between closely related tools.
Naming Consistency5/5
Tool names follow a consistent snake_case verb_noun pattern throughout, such as 'add_fx', 'create_track', 'get_project_info'. There are no deviations in naming conventions, making the set predictable and easy to parse for an agent.
Tool Count2/5
With 57 tools, the count is excessive for a single server, even for a comprehensive DAW interface like REAPER. This many tools can overwhelm an agent and increase complexity, making it harder to navigate and select the right tool efficiently. A more focused subset would be more appropriate.
Completeness5/5
The tool set provides complete coverage for REAPER project management, including track, item, FX, MIDI, envelope, and transport operations. It supports full CRUD/lifecycle actions (e.g., create, get, update, delete) across all major domains, with no obvious gaps that would hinder agent workflows.
Average 3.6/5 across 57 of 57 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description bears full responsibility for behavioral disclosure. It fails to specify whether the underlying media file is deleted or merely removed from the track, whether the operation is undoable, or what the output schema contains. 'Delete' implies destruction but remains ambiguous about scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (6 words) with no structural issues, but undersized given the lack of schema documentation and annotations. Front-loaded with the action, yet sacrifices necessary context for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for a tool with zero schema descriptions and no annotations. While an output schema exists (reducing some burden), the description fails to explain critical DAW-specific semantics like index numbering schemes or destructive behavior scope, leaving significant operational gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (only titles 'Track Index' and 'Item Index'). The description adds no semantic context: it does not clarify if indices are 0-based or 1-based, valid ranges, or the hierarchical relationship (whether item_index is track-relative or global).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb (delete) and resource (media item from a track). Effectively distinguishes from siblings like delete_track, delete_marker, and delete_midi_note by specifying 'media item' scope. Lacks explicit scope boundaries (e.g., removes from timeline vs. deletes source file).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use versus alternatives like delete_track (when user wants to remove the track entirely) or move_media_item (when repositioning is preferred). No mention of prerequisites or index sourcing.
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 behavioral burden. It states 'Remove' implying destruction, but fails to disclose whether the action is undoable, if automation data for the FX is deleted, or what occurs if indices are invalid (exception vs silent failure).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficiently structured sentence with no redundancy. However, given the 0% schema coverage and destructive nature of the operation, this brevity is inadequate; the description is under-specified rather than appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (reducing the need to describe return values), the description is insufficient for a destructive mutation tool with zero input schema documentation. It lacks error behavior, parameter validation details, and side-effect disclosure expected when annotations are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%—neither parameter has a description field. While the single sentence implies track_index identifies the track and fx_index identifies the plugin position, it does not explain indexing schemes (0-based vs 1-based) or valid ranges, which is critical information for integer indices in audio software.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (Remove) with clear resource (FX plugin) and scope (track's FX chain). However, it does not explicitly distinguish this permanent deletion from the sibling tool set_fx_enabled (which presumably bypasses/disables without removing), a critical distinction in DAW workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus alternatives (e.g., set_fx_enabled for temporary bypass), nor prerequisites (e.g., track/FX must exist). The agent must infer usage solely from the verb.
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?
Adds valuable unit context for volume (linear amplitude, 1.0 = 0 dB) and pan (-1.0 to 1.0) that the schema doesn't provide. However, missing critical behavioral details like mutation confirmation, atomicity (all-or-nothing updates), or validation rules for the required track_index parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The structure is logical (purpose first, then parameter specifics) and avoids redundancy, but the overall length is insufficient for a 7-parameter tool with zero schema coverage. The brevity becomes under-specification given the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for the tool's complexity. Despite having an output schema (relieving return-value documentation duties), the description fails to document 5 of 7 parameters and omits safety/validation context for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description only compensates for 2 of 7 parameters (volume, pan). The required track_index and optional parameters (name, mute, solo, arm) receive no semantic explanation, leaving the majority of inputs undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
States the basic action (Modify) and resource (track properties) clearly, but fails to differentiate from sibling tools like set_track_input or set_track_send that also modify track attributes. The scope of 'properties' is only partially illustrated through the volume/pan examples.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives (e.g., set_track_input, set_track_send) or prerequisites (e.g., track must exist). No mention of error conditions or partial update behavior.
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. While 'Move' implies a mutation, the description lacks critical behavioral details: error handling for invalid indices, whether the move respects snap/grid settings, if overlapping items are allowed, or whether the operation is undoable (relevant given the 'undo' sibling tool).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded with the verb and contains no wasted words. However, given the 0% schema coverage and mutation behavior, the description is likely too concise rather than appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool requiring specific integer indices to locate target objects, the description is insufficient. It fails to explain the addressing scheme (how tracks and items are indexed) or reference the output schema's return value, leaving significant gaps despite the existence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring the description to compensate. It only partially succeeds: '(seconds)' adds crucial unit semantics for the 'position' parameter, but 'track_index' and 'item_index' are completely undocumented, leaving users without guidance on how to obtain or format these required identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Move') and resource ('media item') and clarifies the positioning unit ('seconds'). It implicitly distinguishes from siblings like 'resize_media_item' and 'duplicate_item', though it could explicitly state this operates on existing items versus creating new ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., 'nudge_midi_notes' or 'resize_media_item'), nor does it mention prerequisites like obtaining valid track_index and item_index values from 'get_track_items' before invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It fails to disclose where the duplicated item appears (immediately after the original? at the play cursor?), whether the original remains selected, or if the operation is undoable. 'Duplicate' implies mutation but specifics are absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of six words is appropriately front-loaded with the action and object. However, given the lack of schema documentation and annotations, extreme breveness here contributes to under-specification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists (covering return values), and the operation is conceptually simple. However, with zero parameter schema coverage and no annotations, the description should have elaborated on parameter semantics and placement behavior to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% - neither track_index nor item_index have descriptions. The description mentions 'media item' and 'track' which conceptually map to the parameters, but provides no explanation of what these indices represent (0-based vs 1-based), valid ranges, or how they identify the specific item.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Duplicate' and resource 'media item'. The phrase 'on its track' distinguishes it from sibling tools like duplicate_track and duplicate_time_range, though it could clarify whether the duplicate remains on the same track or is placed elsewhere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus duplicate_track, duplicate_time_range, or copy-paste workflows. No prerequisites or constraints mentioned (e.g., whether the item must be selected first).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only discloses the indexing scheme (0-based). It omits error behavior (out-of-bounds handling), return structure details despite having an output schema, and side effects (though 'Get' implies read-only, explicit confirmation would help).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence wastes no words and leads with the verb. However, given the complexity (48+ sibling tools in a DAW domain) and 0% schema coverage, the extreme brevity leaves significant gaps that additional structured sentences could have addressed without violating conciseness principles.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for a complex audio production domain. With zero input schema descriptions and numerous sibling track operations, the description should clarify relationships (e.g., 'use after list_tracks'), valid index sourcing, and domain-specific constraints. Output schema existence mitigates need to describe returns, but input guidance is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds critical '0-based' semantic information entirely missing from the 0% coverage schema, explaining the nature of track_index. However, fails to compensate for lack of schema descriptions regarding valid ranges (0 to N-1?), bounds checking, or whether index refers to visual order or creation order.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb (Get) and resource (track) with specific scope (detailed info, single track). The '0-based index' qualifier helps distinguish from bulk retrieval (list_tracks) and name-based lookup, though 'detailed info' remains somewhat vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this versus list_tracks or get_track_items. The '0-based index' hints at the addressing scheme but doesn't clarify prerequisite steps (e.g., obtaining valid indices from list_tracks) or error conditions for invalid indices.
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 disclosure. While 'Insert' implies mutation, the description fails to clarify whether this overwrites existing content, creates a new media item, validates file existence, or specifies the return value structure (despite an output schema existing).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at 11 words with zero redundancy. The sentence is front-loaded with the verb 'Insert' and immediately identifies the object and location parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutative nature, 0% schema description coverage, and lack of annotations, the description is insufficient. It omits essential operational context like file format support, error handling behavior, and interaction with existing track content.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the critical unit '(seconds)' for the position parameter and implicitly maps 'audio file' to file_path and 'track' to track_index. However, with 0% schema description coverage, it should specify whether paths must be absolute, if track_index is 0-based, and validation constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (insert), resource (audio file), and target location (track at given position in seconds). It effectively distinguishes from sibling tools like `create_midi_item` or `insert_midi_event` by specifying 'audio file' versus MIDI operations, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings like `duplicate_item`, `move_media_item`, or `create_midi_item`. It omits prerequisites (e.g., track must exist) and file format requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'change' implies mutation, it fails to disclose whether this stretches audio, trims content, affectsRipple/follow-on items, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence that is front-loaded with the action. However, given the 0% schema coverage and lack of annotations, this brevity becomes under-specification rather than efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Insufficient for a 3-parameter mutation tool. Despite having an output schema, the description omits critical context: how to locate valid indices (should reference get_track_items), whether indices are 0-based, and what happens to audio material when resized.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by clarifying the unit for 'length' (seconds). However, it leaves track_index and item_index completely unexplained despite these being critical identifiers; adding context that these indices locate the item within the project would improve this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (change length), target resource (media item), and unit (seconds). The mention of 'seconds' distinguishes temporal duration from positional moves (e.g., vs move_media_item), though it could explicitly clarify this changes duration rather than position.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use versus alternatives (e.g., when to use this vs move_media_item or duplicate_item), and fails to mention prerequisites like obtaining valid track_index/item_index values from get_track_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 carries the full disclosure burden. It successfully communicates the normalized value constraint (0.0–1.0), but lacks information on error handling (invalid indices), idempotency, return value structure, or whether changes are immediately applied or require additional steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action verb and includes the essential value constraint without filler. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero schema coverage and no annotations, the description is insufficient for a 4-parameter addressing tool. While the output schema covers returns, the input parameters (especially the three indices) require documentation that is missing here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring the description to compensate. It adds critical semantic information for normalized_value (the 0.0–1.0 range), but provides no guidance for track_index, fx_index, or param_index (e.g., zero-indexed vs one-indexed, valid ranges), leaving three of four parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Set') and resource ('FX parameter'), and distinguishes itself from siblings like get_fx_params or set_fx_enabled by specifying the mechanism ('by normalized value'). However, it could more explicitly contrast with set_fx_preset to clarify this manipulates individual parameters versus loading presets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like set_fx_preset or how to determine valid indices. It only states what the tool does, not when to prefer it over other FX manipulation tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses what data is returned (the specific properties listed), which is helpful given no readOnlyHint exists. However, it omits error behavior (e.g., invalid indices), whether properties are returned as objects/arrays, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, efficiently front-loaded with the action and resource. No redundant words. The colon-separated list of properties is scannable and appropriate for the context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 2 simple integer parameters and an output schema existing, the description appropriately focuses on what properties are returned. However, the complete lack of parameter documentation (0% schema + no description coverage) leaves a gap for users unfamiliar with the indexing scheme.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (neither track_index nor item_index have descriptions). The description fails to compensate by explaining what these indices identify or how they relate to the 'media item' concept. The description only covers output semantics, not input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Return' and specific resource 'properties of a media item' with enumerated property list (position, length, mute, lock, take name, playrate, pitch). Implies distinction from sibling get_track_items by focusing on detailed properties rather than listing items, though could explicitly differentiate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this versus get_track_items or how to obtain the item_index/track_index. No mention of prerequisites or workflow context within the DAW toolset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Remove' implying destruction but fails to disclose side effects (e.g., whether connected receives are affected), reversibility, or what the output schema contains. No mention of failure modes for invalid indices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, 9 words. Action-fronted with zero redundancy. Every word serves the core definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimally adequate for a 2-parameter destructive operation. Given zero schema descriptions and no annotations, it should explicitly document both parameters' semantics and valid ranges. The existence of an output schema mitigates the need for return value description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring description compensation. It clarifies 'send_index' is '0-based' and implies 'track_index' via 'from a track'. However, it lacks explicit confirmation that track_index is also 0-based (implied but not stated) and omits valid ranges or formats for both parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Remove' targeting resource 'send' from 'track'. Explicitly mentions '0-based send index' which distinguishes the indexing scheme. However, it does not explicitly differentiate from sibling tool 'set_track_send' (which modifies vs removes).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides indexing hint ('0-based') but lacks explicit prerequisites (e.g., track must exist, send must exist at index), error conditions, or guidance on when to use 'remove' versus 'set_track_send' (disable) or 'create_track_send'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States the action but omits critical behavior: whether current project is closed, what happens if file doesn't exist, or if this triggers UI dialogs. 'Open' implies mutation of application state without clarifying scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action verb, zero redundancy. Efficiently communicates file type requirement and path constraint without extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a single-parameter tool with output schema present. Description identifies the domain-specific file format (.rpp) which is essential context, but gaps remain in behavioral coverage given zero annotation support.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (file_path property lacks description). Description compensates by specifying 'absolute path', adding crucial semantic constraint that distinguishes it from relative paths. Strong value-add for the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Open' with specific resource 'REAPER project file (.rpp)'. Mentioning the file extension distinguishes it from generic project operations and implies it works with existing files (vs sibling new_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this vs new_project, no mention of prerequisites (file must exist), and no warnings about closing current projects or overwriting unsaved changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It successfully documents the value encoding scheme (0-based for audio, REAPER I_RECINPUT formula for MIDI), which is critical behavioral context. However, it omits safety details like error handling when indices are out of range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with efficient bullet-point formatting. The core purpose is front-loaded in the first sentence, and the technical details follow without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the encoding explanation provides necessary domain-specific context and an output schema exists (removing the need to describe returns), the description is incomplete due to the missing track_index documentation and lack of guidance on valid ranges or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. It provides substantial semantic detail for input_index (explaining the audio vs MIDI encoding schemes), but fails to document track_index at all, leaving one parameter completely undefined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set') on a specific resource ('recording input') for a clear target ('track'). It distinguishes the intent from siblings like set_input_monitoring (which handles monitoring, not recording source), though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., set_track_properties), nor any prerequisites mentioned (e.g., that the track must exist). Agents must infer usage from the command name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds valuable default behavior (auto-naming as 'Track N', appends to end if index omitted), but omits what the output contains (track ID? full track object?), error conditions, or side effects like auto-selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded purpose statement followed by efficient bullet parameter documentation. No redundant text, though bullet format blends parameter docs into main description rather than using schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has only 2 parameters with simple types (string/null, integer/null) and output schema exists. Description covers input behavior adequately but could mention return value structure briefly given this is a creation operation where track identification matters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (titles only). Description compensates by documenting both parameters: name explains the 'Track N' default pattern, and index clarifies 0-based positioning and append behavior, adding necessary semantic context missing from schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (Insert/create) and resource (track). Uses 'new' which implicitly distinguishes from sibling 'duplicate_track', though lacks explicit contrast with alternatives like using 'duplicate_track' on an empty track.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use versus alternatives (e.g., 'duplicate_track' for copying existing tracks), prerequisites (project must be open), or when to prefer default appending versus specific index insertion.
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 carries the full burden. It discloses the mutation ('Create') and the return value ('new send index'), but omits error handling behavior, side effects on audio routing, and whether this operation is idempotent or reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: the first states the operation, the second states the return value. Every word earns its place and the core action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 0% schema coverage and lack of annotations, the description covers the essential operation and return value (sufficient since output schema exists), but omits domain-specific context that would aid an agent, such as explaining what 'sends' are used for in audio production or collision behaviors if a send already exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description partially compensates by mapping the directional relationship ('from one track to another') to the src/dst parameters, though it does not explicitly document each parameter's role or constraints (e.g., valid index ranges).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the verb ('Create'), resource ('send'), and scope ('from one track to another'). It distinguishes this from siblings like 'remove_track_send' and 'set_track_send' by specifying this creates a new send and returns its index.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this versus 'set_track_send' (which might update existing sends), nor does it mention prerequisite conditions such as the requirement for both tracks to exist beforehand.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the destructive 'delete' operation and the 0-based indexing scheme, but omits safety context (e.g., whether changes are reversible via the 'undo' sibling tool), error behavior for invalid indices, or concurrency implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 12 words. Every word earns its place: the action, the target, the container (MIDI item), and the key addressing constraint (0-based index) are all efficiently packed without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema (reducing the need to describe return values) but 0% input schema coverage and no annotations, the description is minimally adequate. It identifies the resource clearly but should have cross-referenced get_midi_notes for obtaining the index and clarified the addressing scheme for all three parameters given the complexity of nested DAW object addressing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (only titles provided). The description compensates partially by specifying that note_index is '0-based', which is critical semantic information not in the schema. However, it fails to document track_index or item_index (whether they are also 0-based, their relationship to the project structure, etc.).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Delete') and resource ('MIDI note') and clarifies the addressing method ('by its 0-based note index'). However, it does not explicitly distinguish from siblings like set_midi_note (update vs delete) or indicate the relationship to get_midi_notes (typically needed first to obtain the index).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the '0-based note index' requirement but provides no explicit guidance on when to use this tool versus alternatives, nor does it mention that one must typically call get_midi_notes first to obtain the note_index. There are no prerequisites, warnings, or workflow hints.
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 clarifies that 'bypass' means disable, which is helpful domain terminology. However, it omits behavioral details like whether changes are immediate, idempotent, or what error conditions exist (e.g., invalid indices). No contradiction with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action. No redundant words. Appropriate length for the tool's scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple 3-parameter toggle operation, but gaps remain given 0% schema coverage. It does not leverage the existence of an output schema (mentioned in context) to explain what success returns, nor does it document the index numbering convention crucial for DAW APIs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no parameter descriptions). The tool description maps domain concepts to parameters implicitly: 'track' → track_index, 'FX plugin' → fx_index, 'Enable or bypass' → enabled. However, it fails to clarify critical semantics like whether indices are 0-based or 1-based, or what constitutes a valid fx_index.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verbs ('Enable or bypass') and resource ('FX plugin on a track'). Implicitly distinguishes from siblings like add_fx, remove_fx, and set_fx_param by focusing specifically on the enabled/bypass state, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this versus remove_fx (deletion) or set_fx_param (configuration). Does not mention that bypassing preserves the plugin in the chain while disabling processing, which is the key distinction from removal.
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 documents the three mode states (0=off, 1=on, 2=not when playing), explaining what the system does in each state, but omits other behavioral traits like error handling, persistence across sessions, or side effects on audio processing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient lines with zero filler content. The first sentence states purpose; the second uses a clear bullet format to document mode values. Every element earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters and an output schema exists (per context signals), the description need not explain return values. However, with 0% schema coverage and no annotations, it minimally compensates by documenting only the mode parameter, leaving track_index semantically undefined.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. It successfully documents the enum semantics for mode (0, 1, 2 meanings), but provides no clarification for track_index such as whether it is zero-indexed, required track state, or valid ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set input monitoring mode for a track' provides a specific verb (Set), resource (input monitoring mode), and scope (for a track). It implicitly distinguishes from siblings like set_track_input (which likely configures hardware input) by focusing specifically on monitoring behavior, though it does not explicitly contrast with alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus set_track_properties or set_track_input, nor does it mention prerequisites like track existence or project state. It purely states the operation without contextual selectors.
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 partially compensates by previewing the output fields (position, length, take info), but fails to disclose safety characteristics, error conditions (e.g., invalid track_index), or performance characteristics for tracks with many items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single 12-word sentence is efficiently front-loaded with the action verb 'List' and contains no redundancy. Every word contributes to understanding the scope (media items), location (track), and output characteristics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter and an output schema (per context signals), the description is sufficiently complete. It appropriately previews key output fields without replicating the full schema, though it could benefit from noting the REAPER-specific 'take' terminology.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. It provides minimal semantic context by mentioning 'on a track,' which clarifies that 'track_index' identifies the container track for the query, but offers no further details on constraints, indexing (0 vs 1-based), or valid ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the resource 'media items on a track' and details the output content (position, length, take info). It effectively distinguishes from sibling 'get_item_properties' (which implies retrieving properties of a single specified item) by emphasizing the bulk listing nature and specific data returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implied context that this tool is used to enumerate media items on a specific track, but offers no explicit guidance on when to use this versus 'get_item_properties' for single-item lookups, or prerequisites like track existence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It successfully defines the valid parameter domain via the supported list, but lacks information on validation behavior, atomicity, side effects on playback, or failure modes when invalid values are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first declares purpose, second lists valid inputs. Every word earns its place. Appropriate density for a simple setter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has output schema (exempting return value documentation) and only 2 parameters, but the 'value' parameter remains semantically opaque despite being critical for successful operation. Missing behavioral context expected for a state-mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. The description compensates significantly by enumerating valid values for the 'parameter' argument (loop_start, loop_end, etc.), acting as implicit documentation for what would typically be an enum. However, it completely omits type/format expectations for the 'value' parameter (e.g., numeric vs boolean, time formats).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Set) and resource (project parameter) and distinguishes scope by listing five supported parameter names (loop_start, loop_end, etc.). However, it doesn't explicitly differentiate from sibling tools like 'set_tempo' or 'transport' which may overlap in functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists supported parameter names which provides implicit scope, but contains no explicit when-to-use guidance, prerequisites, or named alternatives. Doesn't clarify relationship with 'get_project_parameters' or when to use specialized tools like 'transport' versus this generic setter.
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 successfully explains the value ranges and units for volume and pan (linear amplitude, -1.0 to 1.0 range), but fails to mention error behavior, what happens with invalid indices, or what the output schema contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief and front-loaded with the main action. The bullet points efficiently convey parameter semantics without verbosity, though the formatting (markdown bullets in a string) is slightly informal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a 4-parameter mutation tool with an output schema, the description adequately covers the optional parameters' semantics but leaves significant gaps regarding required parameters (track/send indices) and makes no mention of the return value or error conditions despite output schema being present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate. It provides excellent semantic detail for the optional volume and pan parameters (units, reference values, ranges), but completely omits semantic guidance for the required track_index and send_index parameters (e.g., whether they are 0-indexed).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (Set), the exact resource (track send), and the specific attributes modified (volume and/or pan), distinguishing it from sibling tools like create_track_send or set_track_properties through precise resource specification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states what the tool does but provides no guidance on when to use it versus alternatives (e.g., when to use this versus creating a new send), nor does it mention prerequisites like the send needing to exist first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. While 'Delete' implies destruction, lacks crucial behavioral details for a destructive operation: whether deletion is permanent, if it shifts indices of subsequent markers, error behavior on invalid index, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste. Front-loaded with the action verb, immediately followed by the resource and parameter explanation. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a single-parameter destructive tool. The critical dependency on list_markers is documented. Since an output schema exists (per context signals), the description doesn't need to explain return values. Could mention error cases for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no property descriptions), but the description compensates effectively by explaining 'enum_index' is '0-based' and sourced from list_markers, adding critical semantic context missing from the schema title alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Delete') and resource ('marker or region'). Distinguishes from sibling delete operations (delete_track, delete_media_item) by specifying the target resource. Referencing 'list_markers' clarifies the data source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies workflow dependency by stating the index comes 'from list_markers', hinting that tool should be called after listing. However, lacks explicit 'when to use vs alternatives' guidance or prerequisites (e.g., project must be open).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds essential behavioral context by specifying 'currently open' project, implying state dependency and temporal scope. However, it omits error behavior (what happens if no project is open), performance characteristics, or specific metadata categories covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no waste. The information is front-loaded with the action ('Return') followed by the specific resource scope. Every word serves the definition without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero input parameters and an output schema exists (not shown but indicated in context), the description is appropriately scoped. It adequately covers the tool's purpose for a simple getter, though it could benefit from noting error states or specific metadata fields returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters. Per the rubric, zero parameters establishes a baseline score of 4. The description appropriately does not invent parameters, maintaining consistency with the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('Return') and resource ('metadata about the currently open REAPER project'). It implicitly distinguishes from track/item-level siblings (get_track, get_item_properties) by focusing on project scope, though it doesn't explicitly differentiate from the similar get_project_parameters tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_project_parameters or prerequisite conditions (e.g., requiring an open project). There are no explicit when/when-not statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It reveals what values are returned, but does not explicitly state that this is a read-only operation, whether values are cached or real-time, or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At seven words, the description is extremely concise with no redundancy. It front-loads the action verb and immediately specifies the return values, with every sentence earning its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and an output schema exists (per context signals), the description appropriately focuses on stating what data is retrieved rather than duplicating return value documentation. A slight gap remains in not addressing the relationship to `set_project_parameter`.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, which establishes a baseline of 4. No additional parameter guidance is needed or provided in the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ("Return") and explicitly names the three resources retrieved (loop range, cursor position, loop-enabled state). However, it does not explicitly differentiate from siblings like `get_project_info` or clarify when to use this versus other getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like `get_project_info`, nor are there any prerequisites, conditions, or exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full behavioral disclosure burden. It successfully indicates partial-update behavior but omits details about error handling (invalid indices), atomicity, or what the output schema contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured with a clear opening sentence, partial-update clarification, and concise bullet points for parameter constraints. Every element earns its place, though a brief mention of the addressing scheme would have improved completeness without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description appropriately omits return value details. However, for a 10-parameter mutation tool with zero schema coverage, documenting only half the parameters (and omitting the required identifiers) leaves significant gaps in contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for all 10 parameters. While it excellently documents value ranges and units for the 5 musical properties (pitch, velocity, etc.), it completely omits the three required addressing fields (track_index, item_index, note_index) and the two boolean flags (selected, muted), leaving critical gaps in how to identify and select the target note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Modify an existing MIDI note' provides a specific verb (modify) and resource (MIDI note) that clearly distinguishes it from sibling tools like delete_midi_note, get_midi_notes, and insert_midi_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Only the supplied fields are changed' effectively documents the partial-update pattern (PATCH semantics), which is critical for understanding the nullable parameter defaults. However, it lacks explicit guidance on when to use this single-note tool versus the plural set_midi_notes or nudge_midi_notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'optionally' indicating optional parameters, but lacks critical behavioral details: valid BPM ranges, transport state requirements, undo implications, or effect on existing audio/MIDI items.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise two-sentence structure. Main purpose front-loaded, followed by bullet-style parameter clarification. Zero redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Parameters are documented and output schema exists (covering return values). However, given no annotations and the destructive/mutating nature of tempo changes, the description lacks behavioral completeness regarding side effects and constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description compensates by defining 'bpm' as 'beats per minute' and providing clear examples for time signature parameters (e.g., '3/4 time'). However, it omits valid ranges and explicit optionality notes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb 'Set' plus resource 'project tempo'. The verb distinguishes this from sibling 'get_tempo'. The parenthetical '(and optionally time signature)' clarifies the scope extension.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this versus get_tempo, prerequisites (e.g., transport state), or side effects on existing media 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?
No annotations provided, so description carries full disclosure burden. Adds valuable domain context ('REAPER color integer') and业务 logic constraints (region_end requirement). However, lacks disclosure of failure modes, side effects, or persistence guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Structure is efficient: single-sentence purpose followed by bulleted parameter semantics. No wasted words; every line conveys necessary constraint information. Appropriate length for the parameter count.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 0% schema coverage and no annotations, the description adequately covers most parameters but has a notable gap with the undocumented 'name' parameter. Presence of output_schema satisfies output documentation needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description successfully compensates for 4 of 5 parameters, explaining units (seconds), conditional requirements, and domain-specific values (REAPER color). Only misses explaining the 'name' parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Add') and resources ('marker or region') clearly. Implies domain context (REAPER) via the color parameter description. Distinguishes from sibling delete_marker and list_markers by action verb, though doesn't explicitly reference them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains conditional logic between is_region and region_end ('also requires'), guiding when to use region_end. However, lacks explicit when-not-to-use guidance or comparison to sibling tools like list_markers for retrieval.
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?
Reveals crucial behavioral detail that time bases are mixed (start/end in seconds, but note timestamps in PPQ). No annotations provided, so description carries full burden; it lacks safety info (failure modes, idempotency, destructiveness) and error handling despite being a creation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient structure: one sentence for purpose, bullet points for parameter details. No wasted words; every element conveys necessary information not present in schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Medium complexity tool with nested object structures. Description partially covers parameters (missing track_index semantics) and lacks safety/error context. Output schema exists (per context signals), relieving the need to document return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description compensates substantially by documenting 3 of 4 parameters: start/end units (seconds) and notes structure with field names and defaults. Only `track_index` remains undocumented (0-indexed? bounds?).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (Create) and resource (MIDI item) with clear scoping (on a track). Distinguishes from audio insertion and track creation siblings, though could clarify distinction from `insert_midi_event` or `set_midi_notes`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through 'optionally pre-populate,' suggesting it can create empty items or pre-filled ones. Lacks explicit when-to-use versus alternatives or prerequisites (e.g., whether track must exist first).
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 disclosure burden. It successfully documents the return format ({name, type} objects with total count) and filter matching logic (case-insensitive substring against name/type). However, it omits safety context (read-only nature, performance characteristics of scanning plugins) that annotations would typically cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with clear structure: purpose statement, bullet-point parameter details with examples, and return value specification. No wasted words, though the return value description could be slightly more integrated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one optional parameter and an output schema, the description provides sufficient completeness by explaining the return structure and enumerating valid type values ('VST', 'VST3', 'CLAP', 'JS'). Missing only explicit differentiation from the 'list_fx' sibling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description excellently compensates by documenting the 'filter' parameter in detail: it is optional, case-insensitive, matches against plugin name or type, and provides concrete examples ('fabfilter', 'vst3', 'clap', 'rea', 'comp').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the verb (List), resource (installed FX plugins), and supported formats (VST, VST3, CLAP, JS). However, it does not distinguish from the sibling tool 'list_fx', which likely lists active FX instances on tracks rather than available system plugins.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'list_fx' or how it relates to 'add_fx'. There are no prerequisites, exclusion criteria, or workflow positioning hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Return' implies read-only/idempotent behavior but lacks explicit safety confirmation or details about data freshness (cached vs real-time). Output schema existence excuses detailed return value description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of seven words with zero redundancy. High information density: verb (Return), scope (current), and dual return values (BPM, time signature) packed efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple getter with existing output schema. Mentions the two key return values. Could strengthen by noting relationship to 'set_tempo' or project tempo changes, but sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present. Per rules, baseline score of 4 applies. Description wisely avoids inventing parameter details when schema confirms none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Return') and specific resources ('current BPM and time signature'). Implicitly distinguishes from sibling 'set_tempo' by using 'Return' vs implied mutation, though explicit contrast with 'get_project_parameters' or 'transport' is absent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives named (e.g., when to use vs 'get_project_parameters'). However, usage is implied by the zero-parameter design and 'current' keyword indicating a state snapshot query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Documents parameter constraints (ranges like 0-127, -8192 to 8191) but lacks critical behavioral details: side effects, whether events are overwritten, failure modes, or what the output schema contains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient bullet-point structure front-loaded with the core purpose. Parameter documentation is necessary given schema lacks descriptions. No redundant text, though parameter docs in description are unconventional.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Handles 9-parameter complexity and conditional logic (different fields per event_type) effectively. Since output schema exists, description needn't explain returns. Lacks only prerequisite context (how to obtain indices).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (only titles). Description compensates well by documenting valid enum values for event_type, explaining PPQ semantics, and specifying conditional parameter requirements (cc/value vs bend vs program). Minor gap: track_index and item_index semantics not explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Insert' + specific resource 'MIDI CC, pitch-bend, or program-change event' + target 'into a MIDI item'. Distinguishes from siblings like set_midi_note (handles note events) and insert_audio_file by specifying event types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists applicable event types (CC, pitch-bend, program-change) but provides no explicit when-to-use guidance, prerequisites (e.g., item must exist), or contrast with alternatives like set_midi_note or insert_envelope_point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses the return structure (fields returned) and the special parameter value behavior (-1 for master track), but lacks information on error handling, read-only nature, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence establishes purpose and return values; second provides essential parameter semantics. Efficiently structured and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a simple read operation with existing output schema. Covers the single parameter's special case. Could be enhanced with error behavior or explicit distinction from similar FX listing tools, but sufficient for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (no parameter descriptions). Description compensates by explaining the critical semantics of track_index=-1 for the master track, though it does not elaborate on valid ranges or format beyond that special case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool lists FX plugins on a track and specifies what information is returned (name, fx_index, n_params, enabled). Uses specific verb and resource. Does not explicitly distinguish from sibling 'list_available_fx', though the distinction is implied by 'on a track' versus available FX.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific usage guidance for accessing the master track (track_index=-1), but lacks explicit when-to-use guidance versus alternatives like 'get_fx_params' or 'list_available_fx'.
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. While 'Create' implies mutation, the description fails to disclose critical side effects: whether the current project is closed, whether unsaved changes are discarded or prompted, or what the output schema contains. This omission is significant for a project-switching operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is optimally concise with two efficient fragments: the core action statement and the helpful parenthetical analogy. Every element earns its place without redundancy or wasted words, presenting information in a front-loaded manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema, the description appropriately omits return value details. However, for a project lifecycle tool with no annotations, the description minimally suffices by stating the action but omits important lifecycle context (project switching behavior, unsaved change handling) that would make it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters (empty object), which per the rubric establishes a baseline of 4. The description appropriately does not attempt to invent parameter semantics where none exist, satisfying the requirement for this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Create') and resource ('REAPER project'), with the adjective 'blank' clearly distinguishing it from sibling tool open_project. The parenthetical '(equivalent to File > New Project)' adds valuable context for users familiar with the application's menu structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers implied usage guidance through the File > New Project analogy, but lacks explicit when-to-use guidance or contrasts with alternatives like open_project. It does not mention prerequisites (e.g., handling unsaved changes in the current project) despite being a project lifecycle operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full disclosure burden. It successfully documents special parameter conventions (-1 for master track, FX name format acceptance) and the Input FX vs FX chain behavior. However, it omits critical behavioral details: whether the FX is appended or prepended to the chain, what occurs if the FX name is invalid, or the nature of the output return value (despite an output schema existing).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately compact with zero filler content. The structure is front-loaded with the core action, followed by parameter-specific details in a bulleted format. While the bullet points deviate from pure prose, they are highly scannable and efficient for an AI agent parsing the definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema (covering return values) and the complexity (3 parameters), the description adequately covers inputs despite the 0% schema coverage. It successfully documents all parameters, but a perfect score would require mentioning error conditions (e.g., invalid track indices) or the append/prepend behavior in the FX chain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates by documenting all three parameters with precise semantics: track_index explains the 0-based indexing and master track convention (-1), fx_name provides concrete format examples ('ReaComp', 'VST: Serum'), and input_fx clarifies its effect on routing (input chain vs standard FX chain). This is exemplary parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Add') and target ('FX plugin' to 'a track'), using precise domain terminology. It effectively distinguishes the tool from siblings like remove_fx or set_fx_param through the verb choice, though it could more explicitly differentiate from insert_audio_file or clarify that this instantiates the plugin rather than configuring existing ones.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance through the parameter explanations (e.g., distinguishing input FX chain from regular FX chain via the input_fx flag), but lacks explicit when-to-use guidance or references to complementary tools like list_available_fx for finding valid fx_name values. No prerequisites or side-effect warnings are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'all' implying unfiltered retrieval, but lacks disclosure on safety profile (though implied by 'List'), performance characteristics, or whether markers/regions are returned in a unified structure. Output schema exists per context signals, reducing some burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero redundancy. Front-loaded with action verb. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for tool complexity: 0 parameters with 100% schema coverage and existing output schema. Description adequately covers the dual scope (markers + regions) without needing to detail return values. Could benefit from noting the unfiltered nature explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero properties. Per calibration rules, 0 params = baseline 4. Description appropriately does not fabricate parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'List' + clear resources 'markers and regions' + scope 'in the project'. Critically mentions 'regions' alongside markers, distinguishing it from sibling tools like add_marker or delete_marker that might handle only markers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use versus alternatives (e.g., vs get_project_info which might include marker data) or prerequisites. While the operation is straightforward, there is no 'when to use' or 'when not to use' instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. 'To disk' indicates persistent I/O and mutation, but lacks critical behavioral details: failure modes if project is unsaved, whether it performs 'Save' or 'Save As' semantics, and return value structure despite output schema existing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste. Verb-fronted ('Save') with clear direct object and prepositional phrase. Optimal length for the operation's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter state-mutation tool where output schema exists (covering return documentation). Could benefit from noting filename/path handling behavior, but sufficient given the straightforward nature of the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present. Per rubric, 0 params = baseline 4. Description appropriately omits parameter discussion as none exist to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb (Save) + specific resource (current REAPER project) + scope (to disk). Implicitly distinguishes from siblings like `new_project` (creates), `open_project` (opens files), and `get_project_info` (reads metadata) by emphasizing the 'current' project and persistence action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no explicit guidance on when to use versus alternatives (`new_project`, `open_project`) or prerequisites (e.g., requiring an open project). Simply states what the tool does without contextual selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses valid action values and that position uses seconds, but fails to describe side effects (e.g., does 'record' arm tracks or start recording immediately?), state changes, or whether actions are idempotent. The unit disclosure ('seconds') adds value beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely efficient two-line structure. First line establishes purpose; second line documents parameters. Zero redundant prose. Inline parameter documentation is appropriate given the lack of schema descriptions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a simple 2-parameter tool with output schema (which handles return value documentation). Despite 0% schema coverage, the description successfully documents the parameter enums and requirements, which is sufficient for this operational command tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description effectively compensates by documenting the enum values for 'action' inline and clarifying the conditional requirement and unit (seconds) for 'position'. However, it doesn't describe boundaries, precision, or semantic meaning of the position value (e.g., timeline location).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('Control') and resource ('REAPER's transport'). The enumerated action values (play/stop/pause/record/goto_start/goto_position) precisely scope the functionality and implicitly distinguish it from siblings that manipulate tracks, items, or effects rather than playback transport.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides parameter constraints ('position: required when action == goto_position') but lacks guidance on when to use specific actions (e.g., when to use goto_start vs goto_position) or when to prefer this over other temporal navigation methods. No mention of prerequisites or state requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Excellent disclosure of clamping behavior ('Velocity is clamped to 1-127'), randomization nature, and return value ('Returns the per-note changes applied'). Missing only destructiveness disclosure (whether original notes are overwritten).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly structured with high information density. Front-loaded action sentence followed by bullet-point parameter details. The PPQ conversion example ('At 960 PPQ, 20 PPQ ≈ 1/48th note') adds concrete value without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, describing the return value is appropriate. However, for a 5-parameter editing tool with 0% schema coverage, leaving 2 required parameters (track_index, item_index) undocumented creates significant ambiguity about how to target specific items despite rich documentation of the algorithmic parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, description must compensate. It excellently documents 3/5 parameters (timing_range_ppq with PPQ conversion example, velocity_range with clamping note, seed with reproducibility note) but completely omits documentation for required parameters 'track_index' and 'item_index', leaving critical selection criteria undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Humanize' with clear resource (MIDI notes) and mechanism (random timing/velocity offsets). The term 'humanize' clearly distinguishes this from sibling 'set_midi_notes' (precise control) by implying probabilistic/randomized modification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear parameter-level guidance (e.g., '0 = no timing change') and explains the seed parameter for reproducibility. However, lacks explicit guidance on when to use this versus 'set_midi_notes' or prerequisites like selecting the correct track/item.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the destructive 'Delete' operation and default scope (entire timeline), but omits critical behavioral details: recoverability (can this be undone?), interaction rules (what happens if both name and index provided?), and units for the time range (seconds/beats?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. First sentence states the action and scope; second sentence explains identification method. All information earns its place. Appropriately front-loaded with the core destructive action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Considering 5 parameters with 0% schema coverage and a destructive operation, the description covers the main usage patterns well (envelope identification, time range defaults, indexing basis). Output schema exists so return values needn't be explained. Minor gaps remain: track_index basis, time units, and parameter precedence rules when both identification methods provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates well: it specifies envelope_name examples ('Volume', 'Pan'), notes envelope_index is '0-based', and implies t1/t2 via 'time range' with default. However, it omits track_index semantics (0-based vs 1-based?) and time unit clarification, which are critical for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states specific verb 'Delete' with resource 'automation envelope points' and scope 'given time range (default: entire timeline)'. It clearly distinguishes from siblings like get_envelope_points (read) and insert_envelope_point (add).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage guidance on how to identify envelopes (name vs 0-based index) and default time range behavior. However, lacks explicit when-to-use guidance versus alternatives (e.g., when to use clear vs insertion/deletion of individual points) or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses critical behavioral detail: insertion occurs 'immediately after the original.' However, omits whether track properties (FX, sends, envelopes) are duplicated or if the new track becomes selected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single 10-word sentence with zero waste. Front-loaded action (Duplicate), followed by resource, then behavioral qualifier (insertion position)—every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a single-parameter mutation tool. Output schema exists (noted in context), absolving description from detailing return values. Could mention copied properties but covers core insertion behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% with no property descriptions. Description mentions 'a track' implying the target but does not explicitly map to track_index parameter or clarify indexing scheme (0-based vs 1-based). Single parameter has clear name, preventing lower score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Duplicate' paired with resource 'track' and distinguished from siblings by 'inserting the copy immediately after the original'—clearly differentiates from create_track (new empty track) and duplicate_item (media items vs tracks).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through the word 'duplicate' (copy existing vs create new) and clarifies positioning behavior, but lacks explicit when-to-use guidance or references to siblings like create_track or duplicate_time_range.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It successfully indicates this is a read-only operation ('Return') and crucially documents the output structure ('Each entry includes: param_index, name...'), providing transparency into return format. Missing explicit error conditions or indexing conventions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first states purpose, second documents return structure. Every word earns its place. Appropriate density for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given existence of output schema, description appropriately focuses on high-level purpose while still previewing return structure (param_index, normalized values, etc.). Complete for a 2-parameter read operation, though could mention indexing conventions or valid ranges for full marks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (only titles 'Track Index', 'Fx Index'). Description compensates by establishing semantic context: 'FX plugin on a track' maps the indices to their domain entities. However, lacks specifics on indexing scheme (0-based vs 1-based), valid ranges, or parameter constraints that would fully compensate for absent schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Return' with clear resource 'all parameters for an FX plugin' and scope 'on a track'. Effectively distinguishes from siblings: contrasts with set_fx_param (single parameter mutation), list_fx (listing plugins not parameters), and add_fx/remove_fx (plugin management).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit 'when to use' guidance or alternative recommendations provided. However, usage is reasonably implied by the descriptive output format (enumerating return fields), suggesting this is for inspection/introspection of plugin state before modification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden and successfully discloses return format (list with start_ppq, end_ppq, pitch, velocity, channel) and scope limitation (active take only). Missing details on failure modes (invalid indices, non-MIDI item).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first defines operation, second defines return structure. Front-loaded with action verb. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Good coverage given output schema exists; description proactively lists return fields which aids agent interpretation. With only 2 simple indices and a clear read operation, nearly complete except for error handling documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (titles only). Description partially compensates by referencing 'media item' (clarifying item_index) but never mentions track_index or explains the track+item coordinate system. Baseline 3 acceptable but could document parameter relationship.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Read' with clear resource 'MIDI notes from a media item's active MIDI take'. Scope is well-defined (ALL notes from the ACTIVE take) and implicitly distinguishes from siblings like set_midi_notes (write) and delete_midi_note (delete).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage scenario (retrieving existing MIDI data) but lacks explicit guidance on prerequisites (e.g., verifying item exists, has MIDI take) or when to prefer this over get_track_items. No mention of error conditions when indices are invalid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full behavioral burden. Adds crucial REAPER-specific context: visibility/arming requirements, linear amplitude scaling (including dB mapping for Volume), and shape interpolation semantics. Does not disclose error behavior or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with clear front-loaded purpose sentence followed by identification logic and parameter bullets. Efficient use of space explaining domain-specific enums (shape codes) and value ranges without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a 7-parameter specialized audio tool with empty schema. Covers critical domain knowledge (envelope arming, dB mapping, interpolation shapes) that schema cannot express. Output schema exists, so omission of return value details is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (titles only). Description compensates by detailing 6 of 7 parameters: time (seconds), value (amplitude/dB mapping), envelope identifiers (name preference, 0-based index), shape (enum mapping), and tension (range). Omits semantics for track_index (0-based? master track?).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action (Insert) and resource (automation envelope point). Clarifies two methods of envelope identification (name vs 0-based index). Implies temporal domain (seconds) which distinguishes from sibling 'insert_envelope_point_at_beat', though it does not explicitly name that alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit internal guidance: 'Using envelope_name is preferred and works even if the envelope is not yet visible/armed in the REAPER UI.' This clarifies selection between envelope_name and envelope_index parameters. However, lacks explicit cross-tool guidance distinguishing from 'clear_envelope_points' or 'get_envelope_points'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds valuable context by enumerating the specific track states returned (volume, pan, mute, solo, arm), which supplements the output schema. However, it omits safety/profile information (e.g., read-only nature, performance characteristics).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action ('List'), and efficiently enumerates the returned track properties without waste. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists, the description appropriately focuses on enumerating the key return fields (volume, pan, etc.) rather than redundant return value documentation. It could improve by explicitly contrasting with 'get_track', but is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters. Per the rubric, 0 parameters warrants a baseline score of 4, as there are no parameter semantics to describe beyond what the empty schema already communicates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the clear scope 'every track in the project.' It effectively distinguishes itself from the singular sibling 'get_track' by emphasizing 'every' (comprehensive listing vs. individual retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'List every track' provides implied contrast to 'get_track' (singular), suggesting this is for bulk retrieval. However, there is no explicit guidance on when to prefer this over 'get_track' or other track-related tools, nor are prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses return values (bridge_version, reaper_version) which helps predict output. 'Check' implies read-only safety, but lacks explicit non-destructive/idempotent confirmation or error behavior (what happens if unreachable).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste: first states purpose, second states return values. Appropriately front-loaded and sized for a trivial health-check tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a zero-parameter health check. Mentions return values (complementing the unspecified output schema content). Could explicitly state 'safe to call anytime' given lack of safety annotations, but adequate for simple ping.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters per schema. Baseline 4 applies. Description correctly implies no inputs needed for a ping operation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Check' + resource 'bridge' clearly defines the reachability test. Distinct from 40+ operational siblings (add_fx, create_track, etc.) which manipulate the DAW rather than testing connectivity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use as a health check via 'reachable', but lacks explicit when-to-use (e.g., 'call first to verify connection') or when-not-to-use guidance. No alternatives named, though 'ping' conventionally stands alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds useful behavioral detail that it 'Returns the name of the action that was undone' (output transparency). However, lacks safety disclosure (modifies project state by reverting) and error conditions (behavior when undo history is empty).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Front-loaded with action, followed by return value. Every word earns its place. Perfect efficiency for a parameterless tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for low complexity (0 params) with output schema available. Covers execution effect and return value hint. Minor gap: no mention of empty undo stack behavior, but acceptable given output schema handles return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters present. Per rubric, baseline is 4 for 0-param tools. Description correctly implies no configuration needed via concise 'Trigger REAPER's undo' statement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('Trigger') and resource ('REAPER's undo'), plus return value disclosure. Distinguished from 40+ sibling mutation tools by its specific undo purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage through 'Trigger REAPER's undo' but lacks explicit 'when to use' guidance, prerequisites (e.g., requires prior actions), or named alternatives (e.g., redo would be a sibling not listed here).
Agents often have multiple tools that could apply. Explicit usage guidance like "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, description carries full burden and effectively discloses critical safety info: operation is permanent but reversible via REAPER's undo system. Could improve by mentioning side effects (e.g., whether media items are deleted or moved to root).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Front-loaded with action, second sentence delivers essential safety warning. Efficient structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for tool complexity. Covers action, indexing scheme, and safety profile. Has output schema so return values need less explanation. Could mention validation behavior (invalid index handling) but adequate as-is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Compensates effectively for 0% schema description coverage by specifying '0-based index'—critical semantics for API correctness that the schema title 'Track Index' omits. Single parameter is well-documented given schema constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('Delete') + resource ('track') + scope ('by 0-based index'). Distinguishes clearly from sibling operations like create_track, duplicate_track, or remove_track_send.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies caution via 'permanent' warning but lacks explicit when-to-use guidance or alternatives (e.g., mute vs delete, or what happens to media items on the track). No contrast with similar deletion tools like delete_media_item or delete_marker.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses output structure (time, value, shape, tension) and important REAPER-specific visibility constraint. However, lacks explicit read-only safety confirmation, error conditions, or side effects beyond the visibility note.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficient, front-loaded sentences. Opens with purpose, followed by parameter identification guidance, then preference rationale and return value summary. Zero redundancy despite 0% schema coverage burden.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, the summary of return values is sufficient. Despite complete lack of schema descriptions, the tool provides enough context for correct invocation including track indexing and envelope identification strategies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, description effectively compensates by providing concrete name examples ('Volume', 'Pan', 'Mute'), noting '0-based' indexing, and explaining the relationship/preference between envelope_name and envelope_index parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'Read' with resource 'automation envelope points' and distinguishes clearly from mutation siblings like 'clear_envelope_points' and 'insert_envelope_point' by scope (all points vs single) and action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly documents two identification methods (name vs index) and provides clear preference: 'Using envelope_name is preferred'. Explains specific UI constraint workaround that name 'works even if the envelope is not yet visible/armed'.
Agents often have multiple tools that could apply. Explicit usage guidance like "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 significant behavioral weight: it documents the return value format ('resolved time in seconds'), value scaling for Volume (0.0 to 2.0 mapping), shape interpolation codes (0-5), and beat unit semantics relative to time signatures. Minor gaps include lack of explanation for the 'tension' parameter and whether inserting a point overwrites adjacent points.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description employs an efficient structure: a single declarative sentence stating purpose, followed by envelope identification guidance, then bullet points for complex parameters. Every line conveys essential timing or value semantics without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter DAW automation tool with specific domain concepts (time signatures, envelope shapes), the description adequately covers the complex interacting parameters. Despite the presence of an output schema, it helpfully previews the return value format, though completion would require documentation of the 'tension' parameter and track indexing convention.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Given 0% schema description coverage, the description compensates exceptionally well by documenting critical semantics: bar/beat are 1-based (with specific examples), value uses linear amplitude with concrete dB mappings, and shape enumerations are decoded. Only 'track_index' (0-based vs 1-based?) and 'tension' are left undocumented in the description text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action ('Insert') and resource ('automation envelope point'), and immediately distinguishes this tool from sibling 'insert_envelope_point' by emphasizing the 'project beat grid' alignment. This specificity allows an AI agent to confidently select between the two insertion methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implicitly distinguishes this tool via the beat-grid alignment and bar/beat parameters, it does not explicitly state when to use this versus 'insert_envelope_point' (which presumably uses time in seconds), nor does it clarify whether 'envelope_name' or 'envelope_index' takes precedence when both are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Excellently discloses return structure—distinguishes factory_presets (CLAP/VST banks with indices) from file_presets (.ffp/.fxp files with paths). Explains the semantic differences between the two list types and their usage patterns. Could mention read-only/safety nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficiently structured with clear header sentence followed byOutput format details using dashed list items. Every sentence serves a purpose. No wasted words. Front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Rich explanation of output schema semantics (factory vs file distinction, source fields, loading mechanisms). Given output schema exists, description appropriately focuses on how to interpret and act on the returned data rather than repeating structural syntax. Links well to sibling set_fx_preset tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (only titles). Description fails to compensate—it does not mention track_index or fx_index parameters at all, though they are somewhat inferable from the phrase 'FX already on a track'. With zero coverage, the description should explicitly document these required identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb ('List') + resource ('presets') + scope ('for an FX already on a track'). Effectively distinguishes from sibling tools like list_available_fx (plugins vs presets) and set_fx_preset (loading vs listing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear workflow context by explaining how to use the returned data (load factory presets by name with set_fx_preset, file presets via path field). States prerequisite that FX must already be on a track. Lacks explicit 'when not to use' or alternative approaches (e.g., manual parameter setting).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Critically discloses partial-update behavior ('Omitted fields keep their current values'). Missing mutation side-effects, error handling for invalid note_index, or idempotency details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste. First sentence establishes purpose, second provides usage guidance, third explains parameter semantics and behavior. Well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present, description appropriately focuses on input requirements. Comprehensive coverage of the complex nested notes structure. Minor gap: could reference how to obtain track/item indices from sibling tools like get_track_items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, requiring description to compensate. Excellent documentation of complex 'notes' array structure (required fields, valid subset fields, omission behavior). However, track_index and item_index lack semantic explanation despite being required identifiers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Batch-edit multiple MIDI notes' with clear verb, resource, and scope. Explicitly distinguishes from sibling tool set_midi_note() by stating efficiency advantage for batch operations vs repeated single calls.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly compares to set_midi_note() stating this is preferable for batch operations. Lacks explicit 'when not to use' guidance (e.g., single-note edits) or prerequisites for track/item indices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden excellently: explains the dry-run render mechanism, explicit safety guarantee (no file creation), and comprehensively documents all 5 return values including units (LUFS, dBTP) and raw_stats format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose front-loaded in sentence one, safety in sentence two, then return documentation. The return list is lengthy but necessary given the rich output details provided; no tautology or wasted phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 0% input schema coverage and no annotations, the description succeeds in covering tool purpose, operational safety, and output semantics. Minor gap: parameter units and range constraints are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (only titles). Description mentions 'over a time range' implying the parameters, but fails to document critical semantics like units (seconds vs beats) or constraints, leaving parameter interpretation to the schema titles alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: 'Measure the loudness of the full master mix' uses precise verb+resource, and 'master mix' clearly distinguishes this from sibling tool 'analyze_track_loudness'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Strong safety context with 'non-destructive dry-run render' and 'No tracks or files are created,' but lacks explicit guidance on when to prefer this over analyze_track_loudness (e.g., 'use this for the final stereo master vs individual tracks').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. Excellently discloses: internal mechanism (dry-run render), specific mutation target (track fader), return value structure (measured_lufs_i, gain_applied_db, old/new volumes), and critical side effect (registered in REAPER's undo history). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences with zero waste: purpose/mechanism front-loaded, followed by parameter guidance, return values, and side effects. Every sentence earns its place with domain-specific precision (LUFS, EBU R128).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Excellent behavioral and domain coverage given the complexity of loudness normalization. The 0% schema coverage and missing parameter semantics for time ranges and track indexing prevent a 5, but output schema existence and rich mechanism description provide sufficient context for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, requiring description to compensate. It provides exemplary semantic detail for target_lufs (units, default, broadcast standards) but completely omits track_index (0-indexed?), start_time, and end_time (units? project time vs. item time?), leaving 3 of 4 parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb (normalize), resource (track), and detailed mechanism (measuring LUFS via non-destructive dry-run render, adjusting track fader) that clearly distinguishes it from sibling analyze_track_loudness which presumably only measures without adjusting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides excellent domain-specific guidance for target_lufs values (-14.0 streaming, -23.0 EBU R128, -16.0 podcast). Lacks explicit 'when not to use' or direct sibling comparisons, but the mechanism description implies this is for final output leveling vs. simple analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Explains REAPER's format handling ('uses current render format'), documents return values (output_path, file_size_bytes), and implies file system side effects. Could improve by mentioning overwrite behavior or resource requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Excellent structure: single-sentence purpose upfront followed by bullet-point parameter documentation, return value disclosure, and post-action guidance. No wasted words; every sentence earns its place despite explaining 5 undocumented parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a medium-complexity file I/O tool. Despite bare schema, all 5 parameters are documented. Acknowledges return values (output_path, file_size_bytes) and includes practical workflow instruction for the conversation context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description fully compensates: output_path includes format example and extension guidance; start_time/end_time specify units (seconds); sample_rate explains special value 0; channels maps integers to mono/stereo semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear specific verb 'Render', resource 'time range to an audio file', and scope 'using REAPER's render pipeline'. Distinguished from sibling insert_audio_file (importing existing files) and analysis tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides post-render workflow guidance ('attach the file to this conversation'), but lacks explicit when-to-use vs alternatives like insert_audio_file or when to choose rendering over other export methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, yet description excellently discloses behavioral traits: explicitly states 'non-destructive dry-run render', clarifies 'No items, tracks, or files are created', and guarantees 'project state is completely unchanged'. Also documents complete return value structure (LUFS values, true peak, raw stats).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly structured with zero waste. First sentence establishes purpose and mechanism, second sentence provides safety guarantees, followed by a clear structured list of return values. Every sentence earns its place and critical safety info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With rich output structure implied by the return documentation and zero schema coverage, the description successfully covers: purpose, operational method (dry-run), safety guarantees, and complete output format. No gaps remain for a tool of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage. Description partially compensates by mentioning 'single track' (mapping to track_index) and 'time range' (mapping to start/end_time), providing semantic meaning. However, lacks critical details like time units (seconds?) or track indexing scheme (0-based vs 1-based) that the schema should have provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Measure the loudness') on specific resource ('single track over a time range'). The phrase 'single track' effectively distinguishes this from sibling tool 'analyze_master_loudness', clarifying this is per-track analysis rather than master bus analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes the non-destructive 'dry-run' nature which implies safe usage without side effects. The 'single track' qualifier implicitly guides selection against the master loudness alternative. Lacks explicit 'when not to use' exclusions but provides clear operational context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, description carries full behavioral burden effectively. It specifies exact mechanics (overlapping items detection, insertion point 'immediately after end_time'), units (seconds), and return value ('new project end time'). Could enhance further by noting that existing content after end_time is shifted to accommodate pasted material.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Perfectly structured: front-loaded operational sentence followed by use-case context, then targeted parameter annotations. No redundancy; every phrase adds value beyond the schema. Bullet format for parameters aids scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive coverage for a 3-parameter mutation tool. Acknowledges output schema existence by documenting return value. Musical domain context (chorus/outro) enriches completeness. Minor gap: doesn't clarify if operation is atomic or handles edge cases (zero items selected).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Excellent compensation for 0% schema description coverage. Provides units for temporal parameters ('seconds'), clarifies the inclusive-exclusive nature of the time range '[start_time, end_time)', and explains repeat_count semantics ('how many copies') plus its default value (1). Adds essential meaning entirely absent from schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with specific action 'Copy all items overlapping... and paste them immediately after end_time' clearly identifying the verb (copy/paste), resource (time range with overlapping items), and scope. Distinguishes from siblings like duplicate_item and duplicate_track by specifying time-range-based operation vs single-item or track-based duplication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear contextual guidance with 'Useful for extending song form (repeating a chorus, creating an outro)' helping agents recognize musical use cases. While it doesn't explicitly name alternative duplication tools, the specific resource description (items overlapping a time range) clearly delineates appropriate selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Excellent disclosure: documents specific file extensions (.ffp/.fxp/.fxb), pinpoints four distinct failure modes with semantic error codes, and describes exact failure return structure ('loaded=false with a failure_reason').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient three-section structure: purpose statement, input format specification with clear bullet hierarchy, and error return documentation. No redundant words; every sentence provides actionable information front-loaded for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a 3-parameter state-changing tool. Despite output schema existing (per context signals), description proactively documents failure responses. Preset loading complexity and file path requirements are thoroughly covered, leaving no ambiguous gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage (titles only). Description extensively compensates for complex preset_name parameter, detailing three distinct input formats (plain name, index-based, absolute file path) and cross-referencing list_fx_presets(). track_index and fx_index rely on schema titles, but these are relatively self-evident in the DAW context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Load') with clear resource ('named preset') and context ('for an FX plugin on a track'). Clearly distinguishes from sibling set_fx_param (individual parameter control) and list_fx_presets (discovery).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly references sibling tool list_fx_presets() as the source for path values ('Use the path field from list_fx_presets()'). Documents three input formats for preset_name, guiding correct invocation. Could slightly improve by explicitly stating when NOT to use (e.g., vs set_fx_param).
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:

[![ReaMCP MCP server](https://glama.ai/mcp/servers/danielkinahan/ReaMCP/badges/card.svg)](https://glama.ai/mcp/servers/danielkinahan/ReaMCP)

Score Badge

Copy to your README.md:

[![ReaMCP MCP server](https://glama.ai/mcp/servers/danielkinahan/ReaMCP/badges/score.svg)](https://glama.ai/mcp/servers/danielkinahan/ReaMCP)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/danielkinahan/ReaMCP'

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