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 usefully reveals that matching is fuzzy and that the tool returns the new FX index. It does not discuss error behavior or edge cases such as invalid track indices, but for a straightforward add-operation this is reasonable coverage.

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

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

Two tight sentences convey the action, examples, return value, and matching behavior with zero filler. The most important usage information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

For a two-parameter tool with no output schema or annotations, the description covers the core purpose, the plugin naming scheme, fuzzy matching, and return value. The only notable gap is explicit documentation of track_index semantics, though the property name and minimum constraint give an agent enough grounding to call the tool correctly.

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

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

The description adds meaningful semantics for fx_name through examples and the fuzzy-matching note, going beyond the schema's bare 'Plugin name' text. However, track_index is left entirely to the schema's type/minimum constraints, so with only 50% schema coverage the description does not fully compensate for the missing parameter explanation.

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

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

The description clearly states the action ('Add an FX/plugin to a track'), the target resource, and the input method (by name). It also provides concrete examples like 'ReaEQ' and 'ReaComp', which distinguishes it from sibling tools that list, get, or set FX.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives a clear operational context: use this when adding an effect to a track and when you need the resulting FX index. It does not explicitly discuss alternatives or when not to use it, but the purpose is unambiguous enough that an agent would not confuse it with the FX inspection/manipulation siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the key measurement unit (beats relative to item start) and the concept of 'active take', which are important. However, it does not disclose whether notes are appended to existing notes, whether the item's length changes, error handling for non-existent items, or any side effects. It is a mutation tool, but the description does not elaborate on impacts beyond adding notes. This is a moderate level of transparency.

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

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

The description is three concise sentences, each adding critical information: the action and target, the measurement unit, and the batching capability. It front-loads the core purpose and avoids any fluff or redundancy. Every sentence earns its place, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

For a mutation tool with 3 parameters (one a complex array) and no output schema, the description leaves significant gaps. It does not explain how to specify the target item (track_index and item_index), the meaning of 'active take', or the expected return value. Error conditions and behavior when notes are added to an existing item are unaddressed. The description is not complete enough for an agent to call the tool correctly without additional knowledge.

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

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

Schema description coverage is low (33%), with only the 'notes' parameter having descriptive text in the schema. The description adds meaning for start_beat and length_beat by specifying beats relative to item start, and it clarifies the batching of notes. However, it does not explain how to identify the target item – track_index and item_index lack any guidance beyond integer ranges. The description partially compensates for the low coverage but leaves the indexing semantics ambiguous.

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

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

The description clearly states the action ('Add MIDI notes'), the target ('active take of an existing MIDI item'), and the scope (positions/lengths in beats relative to item start). It distinguishes from siblings like reaper_create_midi_item by emphasizing 'existing' item, and the batching hint ('Insert many notes in one call') clarifies a key capability. The verb-resource pair is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies usage on existing MIDI items but does not explicitly mention alternatives or when not to use it. It notes that many notes can be inserted in one call, which is a batching hint, but it lacks explicit direction such as 'use reaper_create_midi_item to create a new item first.' The prerequisite of an existing item is clear, but no exclusions or alternative routing are provided, so guidance is only implied.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently reveals that pointers are returned as 'handle:N' strings valid only within the current session and must be passed back verbatim—critical for correct usage. It also implies the tool's powerful and potentially unsafe nature by calling it an 'escape hatch.' It could mention side effects or error behavior, but given the context, this is sufficient.

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

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

The description is compact (two sentences plus an example) and front-loaded with the core purpose. Every sentence earns its place—the purpose, example, and usage directive are all included without redundancy or fluff. It is well-structured for quick consumption by an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

Given the tool's nature as an escape hatch, the description covers essentials: how to call any function, how to handle pointers, and how to choose between this and dedicated tools. No output schema exists, so return value details are not required. It is sufficiently complete for an agent to invoke correctly, though it could briefly note potential error scenarios; however, that is not critical for basic usage.

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

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

The input schema already describes both parameters: 'func' as the function name and 'args' as positional arguments with the handle-string convention. The description echoes these details and adds a concrete example, but it does not significantly extend the schema's coverage. Since schema coverage is 100%, a baseline of 3 is appropriate; the description adds marginal value only through the example.

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

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

The description explicitly states it is an 'escape hatch' to call ANY ReaScript API function by name, and clarifies its role as a fallback when dedicated tools do not cover the operation. It includes a concrete example (CountTracks) and contrasts with the sibling reaper_* tools, making the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives an explicit directive: 'Prefer the dedicated reaper_* tools when one exists.' This clearly tells the agent when not to use this tool and points to alternatives. Additionally, it explains how to chain calls via handle strings, providing practical usage guidance beyond the basic directive.

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

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

Since no annotations are provided, the description carries the burden of behavioral disclosure. It does mention the tool's core behavior (creating an empty item and returning its index) and clarifies that the item is positioned/sized in beats. However, it does not address failure conditions (e.g., invalid track/when track position is invalid), persistence/undo state, or any effects beyond the creation, leaving gaps in transparency.

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

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

The description is two dense sentences, with no filler or redundency. It starts with the primary action and resource, adds the positioning in beats, and concludes with the workflow-essential return value, making excellent use of space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

Given the simple input schema (3 params, one required), the description covers the major context: what the tool creates, position unit, and the meaningful return value needed by the next step. It does not mention edge-case behavior or detailed error handling, but for a basic creation tool with no output schema and no annotations, it provides enough information for correct invocation in the common case.

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

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

The description partially supports parameter understanding by clarifying that 'beats' are in quarter notes, which supplements the schema descriptions for start/length. The track_index parameter is left unexplained by both schema and description, and the 67% schema coverage means at least one parameter is undocumented in the schema. The description elsewhere adds minimal extra meaning (creating an 'empty' item) but does not compensate for the missing parameter description.

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

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

The description uses a specific verb ('Create') and clearly identifies the resource ('empty MIDI item') and its scope ('on a track'). It explicitly distinguishes from the related reaper_add_midi_notes by describing the function's role as a step preceding note addition, mentioning the returned item index for that tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives implicit usage context by stating that the returned item index should be passed to reaper_add_midi_notes, suggesting a intended workflow. It does not explicitly mention when not to use this tool, but the workflow cue is clear enough for an agent to infer the typical invocation sequence.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It reveals the destructive core action, 'Delete', but does not mention irreversibility, what happens to subsequent track indices, whether the operation can be undone, or what occurs on an invalid index.

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

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

The description is a single, front-loaded sentence with no padding. It conveys the tool's verb, resource, and the key parameter semantics inline while remaining highly scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

For a destructive one-parameter tool, the description is mostly self-sufficient, but the absence of annotations and any information about side effects, error behavior, or return values leaves notable gaps. An agent can call it correctly for a valid index, but not fully understand the consequences of deletion.

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

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

The schema describes the parameter 'index' only as an integer with minimum 0, but the description clarifies that this integer is a 0-based index into the track list, which is essential semantic context. This compensates for the 0% schema description coverage, even though edge-case behavior (e.g., invalid indices) is not covered.

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

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

The description clearly states a specific verb ('delete') and resource ('the track... at the given 0-based index'). It distinguishes this destructive action from siblings like reaper_insert_track or reaper_set_track_volume, and there is no other delete tool among the siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The use case is implied: use it when you need to remove a track. However, the description gives no explicit when-to-use or when-not-to-use guidance and does not point to any alternative (e.g., undo or reaper_call) for zero-based destructive operations.

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

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

No annotations are provided, so the description carries the full behavioral burden. It adds useful context by warning that values are 'normalized as the plugin reports them' — a genuine caveat. But it does not explicitly confirm the operation is read-only (the 'List' verb implies it), nor does it explain edge behavior such as invalid indices or whether an FX with zero parameters returns an empty list.

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

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

Two sentences with zero filler: the first states the operation and its output fields, the second adds the normalization caveat. The signal is front-loaded and every clause contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

For a low-complexity tool (2 simple required integer params, no nested objects, no enums), the description covers the return fields (index, name, value, min, max) and value semantics well enough for an agent to call it and interpret results. It leaves minor gaps: no explicit statement that the call has no side effects and no mention of behavior when an index is out of range, but these are matters of edge-case robustness rather than core usability.

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

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

Schema description coverage is 0%, so the description must compensate, but the parameter names (track_index, fx_index) are already self-explanatory and the phrase 'an FX on a track' loosely maps the two indices to their roles. The description adds no indexing details (e.g., 0-based, which the schema's minimum: 0 confirms) and does not clarify the order of track vs FX indexing. It provides only marginal value over the schema.

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

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

The description uses a specific verb ('List') with a distinct resource ('parameters of an FX on a track') and enumerates the expected return fields (index, name, current value, min, max). This clearly differentiates it from siblings like reaper_list_track_fx (which lists FX objects, not their parameters), reaper_set_fx_param (a write counterpart), and reaper_set_track_volume (a different resource entirely).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The usage context is implied rather than stated: the tool reads parameters, so one reaches for it when needing current FX parameter state, and reaper_set_fx_param when a change is wanted. However, it never names the alternative read tool, does not exclude any sibling explicitly, and does not mention prerequisites such as the track/FX existing or 0-based indexing.

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

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

No annotations are provided, so the description carries full responsibility for disclosing behavior. It explicitly says 'Return', implying a non-destructive read operation, and lists the exact output fields. It does not explicitly state it has no side effects, but the read-only nature is strongly implied. It also does not contradict any annotations (there are none). This is transparent enough for a read-only getter, but a 5 would require an explicit statement that it does not modify the project.

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

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

The description is a single sentence that is both concise and information-dense. It lists all returned fields and immediately follows with a clear usage hint. Every word earns its place, and the essential 'return' and usage guidance are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

For a zero-parameter read-only getter with no output schema, the description covers everything needed to call it correctly: what it returns and when to use it. There is no missing information about parameters, prerequisites, or side effects. The tool is fully self-contained.

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

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

The tool has zero parameters, so the schema coverage is trivially 100%. The baseline for 0 parameters is 4, and the description adds no parameter-related information because there are none to describe. This is appropriate.

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

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

The description clearly states a specific verb ('Return') and a specific resource ('current project's state'), enumerating the exact data returned (tempo, length, transport play state, track list with specific fields). This unambiguously distinguishes it from sibling getters like reaper_get_fx_params, which target a different resource. It is not a tautology and provides a concrete purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives an explicit usage context: 'Use this to orient before making changes.' This tells the agent when to invoke it (before modifications), but it does not explicitly name alternatives or state when not to use it. Since there are other getters in the sibling set (e.g., reaper_get_fx_params), the guidance could be stronger, but the clear 'before making changes' cue is sufficient for a 4.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states that the action is an insert, that it is index-based, and that it returns the new track's index. However, it does not mention side effects such as shifting existing tracks, project mutation, or any prerequisites. This leaves some behavioral transparency gaps.

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

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

The description is two sentences that deliver all key information upfront: the action, the parameter behavior, and the return value. Every clause earns its place with no padding or ambiguity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

Even with no output schema and no annotations, the description provides enough for calling this simple two-parameter tool: insertion point, append behavior, and return value. Minor gaps remain (e.g., whether existing tracks shift), but nothing critical prevents correct invocation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the index parameter's semantics (0-based, omit to append), but this is redundant with the schema description. It adds no extra meaning beyond what the schema already provides.

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

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

The description states a concrete verb and resource—"Insert a new track"—and specifies the index location, distinguishing this from sibling tools like reaper_delete_track and reaper_set_track_name. It is unambiguous what the tool does and what it returns.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives clear contextual guidance on the key usage decision: "Omit index to append at the end." It explains how to control insertion position, though it does not explicitly name alternative tools or exclusions. The context is clear and sufficient for a simple create operation.

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

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

With no annotations and no output schema, the description carries the full burden. It conveys that this is a listing operation and names the returned fields, which implies a non-mutating read. It does not explicitly disclose side-effect safety, error behavior, or what happens with an invalid track_index, but for a simple list operation this is a minimal but acceptable level of transparency.

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

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

The description is a single, front-loaded sentence with no filler. It names the operation, the target, and the output fields in a compact parenthetical. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

For a one-parameter read-only listing tool, the description is mostly complete and provides the essential return shape. However, because the schema offers no parameter documentation and there is no output schema, the description should have explained track_index semantics and perhaps noted that the operation has no side effects. These omissions leave minor but real gaps.

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

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

The schema has no parameter description and 0% schema description coverage. The tool description says 'on a track' but does not explain what track_index means, whether it is zero-based, or how it relates to the project's tracks. The meaning is somewhat inferable from the parameter name and the minimum value of 0, but the description adds no real semantic value beyond the schema.

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

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

The description uses a specific verb ('List') and specifies the resource ('FX on a track') plus the information returned (index, name, enabled state). This clearly distinguishes it from sibling tools like reaper_add_fx, reaper_get_fx_params, and reaper_set_fx_param.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The verb 'List' implies this is the read-only operation for inspecting FX, and sibling names suggest alternatives for adding or modifying FX. However, there is no explicit statement about when to use this tool versus get_fx_params or set_fx_param, so guidance is only implied rather than stated.

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

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

No annotations are provided, so the description carries the burden. It discloses that the tool checks connectivity and returns the version, implying a non-destructive read-only operation. While it doesn't explicitly state 'no side effects', the nature of a ping makes this obvious and the description is honest about its outputs.

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

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

Two sentences, no wasted words. The core purpose ('check that the bridge is alive') is front-loaded, followed by the return value and usage directive. Ideal brevity for a trivial tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

For a zero-parameter health check, the description is fully sufficient: it states the operation, the return value, and the recommended ordering relative to other tools. Nothing an agent needs to invoke it correctly is missing.

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

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

The tool has zero parameters, so according to the rubric the baseline is 4. There is nothing for the description to add beyond what the schema already implies (an empty parameter set).

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

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

The description clearly states the tool checks that the REAPER bridge is alive and returns the version. It uses a specific verb ('check') and resource ('REAPER bridge'), distinguishing it from the other REAPER tools which perform state changes or queries.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly states 'Call this first to confirm the connection', providing clear when-to-use guidance. It doesn't mention when not to use it, but for a health check this is self-evident and not necessary.

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

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

With no annotations, the description carries the burden and does disclose key behavior: 24-bit WAV output, returns path and size, renders headlessly with no dialog. It doesn't mention overwrite behavior or whether rendering requires a saved project, but the disclosed traits are the most decision-relevant ones.

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

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

Three sentences, no fluff, front-loaded with the action and resource, then the key option, then the return value. Every sentence adds information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

For a simple write-to-disk tool with 0 required params and full schema coverage, the description covers what it does, how bounds work, the return value, and a headless behavior caveat. Not mentioning overwrite semantics is a minor gap, not a blocker.

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

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

Schema coverage is 100%: both parameters have descriptions and bounds has an enum plus default. The description adds the concrete 'set bounds="project"' example, which is helpful but not necessary. Baseline 3 is fair because the schema already does the heavy lifting.

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

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

Description names a specific verb+resource: 'Render (bounce) the project master to a 24-bit WAV file on disk.' It is immediately distinguishable from sibling tools like reaper_get_project_state or reaper_add_track, and the parenthetical 'bounce' reinforces the DAW-specific meaning.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

States the default behavior (renders time selection) and the exact way to switch to whole-project rendering ('set bounds='project''). It does not name alternative tools or exclusion criteria, but the tool's purpose is specific enough that little else is needed.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the core action (saving to disk) but does not mention important side effects like overwriting behavior, whether a project must be open, or if any dialog is shown. While minimal, it conveys the essential behavior; however, it lacks depth about potential failure modes or confirmation prompts.

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

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

The description is a single, clear sentence that front-loads the action and resource. It contains no filler or unnecessary detail, earning every word. Perfectly structured for rapid parsing by an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

Given the tool's simplicity (no parameters, no output schema, no annotations), the description is complete. It fully communicates what the tool does without needing additional context about return values or edge cases. An agent can confidently invoke this tool based on the description alone.

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

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

The tool has zero parameters, and the schema is an empty object with 100% coverage. As there are no parameters to describe, the baseline of 4 applies. The description adds the semantic that it operates on the 'current' project, which is a useful implicit constraint that isn't in the schema.

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

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

The description 'Save the current REAPER project to disk' states a specific verb (save), a clear resource (current REAPER project), and the target (disk). It is unambiguous and distinguishes itself from sibling tools, none of which perform a save operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No guidance is given on when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned. The usage is implied by the name and description, but there is no explicit context such as 'use this after making changes' or 'cannot be undone'. This is adequate for a trivial operation but leaves the agent to infer appropriateness.

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

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

No annotations are provided, so the description carries the full burden. 'Move' implies a non-destructive state change (edit cursor position), which is less risky than a destructive operation. Yet the description does not disclose side effects (e.g., does it affect playback? Does it require an open project? Does it change undo state?) which is important for an agent to anticipate.

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

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

The description is a single sentence with no filler words. It is front-loaded with the action and directly communicates the parameter meaning. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

The tool is simple: one parameter with a clear unit. Given no output schema, the description doesn't need to explain return values. However, it could briefly mention that the edit cursor position changes in the project timeline, which might affect subsequent operations like inserting items or recording. That gap is minor.

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

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

Schema coverage is 0%, so the description must fully explain the parameter. It states the unit is secondsable, which is exactly what the schema lacks. With one parameter and clear semantics, this is a strong contribution beyond the schema.

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

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

The description clearly states the verb ('move') and resource ('edit cursor') and specifies the action is to move it to a time position in seconds. It is distinct from siblings like reaper_set_tempo, which changes tempo, and reaper_transport, which controls playback, but 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.

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

The context implies usage: when an agent needs to set the edit cursor to a specific time in the project. However, it lacks explicit when-to-use vs alternatives (e.g., reaper_transport for playback control) and no mention of typical scenarios like scrubbing or editing. Compared to a tool with no usage guidance, this is adequate but not rich.

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

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 says 'Set' but does not mention persistence, side effects, undo behavior, error conditions, or that this modifies track/FX state. This is a meaningful gap for a mutating tool.

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

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

Two tight sentences, no filler, and the primary action is stated immediately. The reference to the discovery tool is placed directly after the action, keeping the description efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

The description is adequate for a simple setter but not fully complete: it names the discovery approach and the value constraint, yet omits how to obtain track/fx indices and does not describe return behavior or side effects. Given four required parameters and no output schema, this leaves some gaps for an agent to infer.

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

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

Schema description coverage is only 25%, so the description must compensate, but it only partially does. It explains that parameter indices and ranges come from reaper_get_fx_params, yet it leaves track_index and fx_index semantics undocumented and provides no concrete guidance about units or zero-based indexing.

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

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

The description states a specific verb and resource: 'Set one parameter of an FX by parameter index.' It also distinguishes the tool from the discovery sibling by pointing to reaper_get_fx_params, so an agent can tell this is the mutating counterpart.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The instruction 'Use reaper_get_fx_params to discover indices and ranges' provides clear context and a prerequisite for using this tool correctly. It does not explicitly enumerate when not to use it versus other sibling tools, but the discovery guidance covers the main ambiguity.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action (set) but does not mention potential side effects, whether the project must be open, or what the tool returns. For a simple mutation tool, the description is minimal but not misleading. It could add that it modifies the global project tempo or that it requires an active project, but the absence of these details is a moderate gap.

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

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

The description is a single, clear sentence with no filler. It front-loads the action and resource, and every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

For a tool with one parameter, full schema coverage, and no output schema, the description is adequate. It does not explain prerequisites (e.g., project must be open) or return behavior, but these are minor given the tool's simplicity. An agent can safely call it knowing it sets the tempo.

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

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

The schema already provides full coverage (100%) for the single parameter 'bpm', including its description ('Beats per minute') and constraints (exclusiveMinimum 0). The description adds no extra meaning beyond the schema, so the baseline score of 3 applies.

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

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

The description uses a specific verb ('set'), names the exact resource ('project master tempo'), and specifies the unit (BPM). It clearly distinguishes itself from the many sibling setter tools because tempo is a unique target not covered by any other sibling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description makes the tool's purpose obvious, so an agent can infer when to use it (whenever the project tempo needs to be changed). It does not explicitly name alternatives or exclusions, but given the tool's uniqueness among siblings (no other tempo-related tool exists), this is acceptable. A small mention of 'use this instead of other setter tools' would have made it a 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects, reversibility, effects on playback, or error behavior. It provides no information beyond what the name implies.

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

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

The description is a single, front-loaded sentence with no redundant content. It is appropriately short for a simple setter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

Given the lack of annotations, output schema, and parameter descriptions, the definition is incomplete. It does not explain return values, error handling, or any prerequisites. An agent has no information about the tool's behavior beyond the bare action.

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

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

Schema description coverage is 0%, so the description must add meaning. It implies 'index' refers to a track index and 'muted' is a boolean state, but it adds no syntax, default behavior, or constraints beyond the schema. The contribution is minimal.

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

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

The description 'Set the mute state of a track' clearly states a specific action on a specific resource. It is unambiguous and distinct from sibling tools like reaper_set_track_solo or reaper_set_track_volume, though it does not explicitly name alternatives. The title reinforces the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention contexts where muting is appropriate, nor does it exclude cases (e.g., when a track does not exist). No usage context is provided beyond the basic action.

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

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 indicates a mutation ('Set') but does not disclose side effects, reversibility, error handling for invalid indexes, or whether the operation requires any preconditions. For a write operation with zero annotation coverage, this is a significant gap.

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

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

The description is a single, front-loaded sentence with zero filler. It conveys the essential action immediately and avoids unnecessary detail. This is exemplary conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

The tool is simple with only two parameters and no output schema, but it lacks essential context: no explanation of expected behavior on out-of-bounds indexes, empty names, or whether the operation is undoable. Given no annotations and no schema descriptions, the description alone is insufficient for an agent to call this tool robustly without additional assumptions.

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

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

Schema description coverage is 0%, so the description must compensate by explaining the parameters. It only mentions 'track at the given index', implying an index parameter but never describing the 'name' parameter's format, constraints, or meaning. The schema provides only basic types with no descriptions, and the description adds no meaningful elaboration, leaving both parameters under-specified.

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

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

The description states a specific verb ('Set'), the resource ('the name of the track'), and the scope ('at the given index'). It clearly distinguishes itself from sibling tools like reaper_set_track_mute or reaper_set_track_volume, which target different properties. An agent can immediately understand what this tool does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies usage whenever a track's name needs to be changed, but it provides no explicit when-to-use guidance or alternatives. It doesn't mention that other track-setting tools exist or when one might prefer them. However, the purpose is self-evident enough that an agent can infer the context, so it's adequate but not explicit.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning side effects (e.g., whether soloing affects other tracks), return values, or error conditions. For a mutation tool, this is a significant gap.

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

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

The description is a single, efficient sentence with no wasted words. It is front-loaded with the core action, making it easy to scan. However, its brevity may contribute to the lack of behavioral and parameter details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

For a simple tool with two basic parameters and no output schema, the description covers the essential action. However, it lacks usage context, behavioral specifics, and parameter explanations. An agent would likely need to consult sibling tool patterns or infer from the schema, making it minimally complete for a trivial setter but not fully self-sufficient.

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

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

Schema description coverage is 0%, so the description must compensate. It does not explain what 'index' refers to or what 'soloed' boolean values mean. The parameter names are somewhat self-explanatory, but the description adds no additional meaning, leaving the agent to rely on the raw schema.

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

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

The description clearly states the action (set) and resource (solo state of a track). It differentiates from siblings like reaper_set_track_mute by focusing on solo, though it could be more specific about operating on a given track index. Overall, the purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of when soloing is appropriate, no exclusions, and no reference to other track-setting tools. The agent must infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It explains the meaning of the db parameter (0 dB = unity, negative = quieter), which is helpful. However, it does not disclose whether there are limits on the value (e.g., maximum positive dB), whether changes are immediate or require render, or what happens on invalid input. The description adds some value but lacks depth on side effects and constraints.

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

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

The description is a single, concise sentence that front-loads the action and then clarifies the unit semantics. There is no wasted wording, and the key information is presented efficiently. It is appropriately sized for a simple setter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

Given that there are no annotations, no output schema, and schema coverage is 0%, the description must be self-sufficient. It explains the db parameter but leaves the index parameter undefined, which is a critical piece of information for calling the tool correctly. Additionally, it does not mention any constraints or behavioral outcomes, making the description incomplete for an agent to use it reliably.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the 'db' parameter thoroughly with units and meaning, but the 'index' parameter is not mentioned at all. The description does not clarify whether the index is zero-based or one-based, or what it refers to (track number in the project). With one of two parameters undocumented, the description only partially fulfills the semantic burden.

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

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

The description clearly states the verb 'Set', the resource 'a track's volume', and the unit 'decibels' with an explicit definition of 0 dB as unity and negative as quieter. This distinguishes it from sibling tools like set_track_name, set_track_mute, or set_track_solo, which target different track properties. The purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or exclusions. Usage is implied from the action itself, but there is no statement like 'use this to adjust volume' or 'if you need to set pan, use another tool'. For a simple setter, this is acceptable but not thorough.

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

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

No annotations are provided, so the description must disclose behavioral traits. It does mention that the tool returns the resulting play state as bit flags, which is a concrete behavior. However, it does not clarify potential side effects, such as whether starting playback could interrupt recording or if there are any constraints (e.g., can't record without an armed track). There is no description of error behavior or prerequisites, leaving the agent in the dark beyond the immediate action.

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

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

The description is extremely concise: two sentences pack purpose, actions, and return semantics. It is front-loaded with the main purpose and includes the necessary detail about the return format. There is no wasted text, achieving high efficiency.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

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

Given the tool's simplicity (single parameter with enum) and lack of output schema, the description is mostly complete. It covers the actions and the return value, sufficient for basic invocation. However, it lacks behavioral context such as prerequisites (e.g., must have an open project) or potential side effects (e.g., changes to project state), which could be important for an agent. Thus, it is adequate but not thorough.

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

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

With 0% schema description coverage, the description must explain the parameter meanings. It does list the possible values (play, stop, pause, record) and explains the return state values, which adds context to the 'action' parameter. However, it does not elaborate on the exact effect of each action (e.g., does 'pause' toggle or set?), but since the enum is self-explanatory and the return state clarifies outcomes, a baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: controlling playback (play, stop, pause, record) and returning the resulting state. It is specific with the verb 'control' and the resource 'playback', and it distinguishes itself from sibling tools like reaper_set_tempo or reaper_transport, which have different functions. The actions are enumerated, making the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description implies when to use this tool: when the agent needs to control playback or recording. However, it does not explicitly state when not to use it or mention alternatives for similar functions. For instance, there is no direct sibling for transport control, so guidance is minimal but not misleading. A score of 3 reflects that usage is clear but not fully elaborated.

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