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

The description reveals that the function adds an effect and returns an object with fx_index, but it does not disclose side effects beyond that. It does not mention whether existing compressors are affected, whether duplicates are allowed, or whether the track must already exist. Annotations only cover non-destructiveness, leaving behavioral details largely undisclosed.

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 compact, with no wasted words. The purpose statement is front-loaded and the return-value note adds useful information without redundancy.

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 tool, the description is mostly adequate: it states the action, target, and return shape. However, it omits important contextual details such as the meaning of track_index, whether the index is zero-based, and what happens if the track does not exist or already has a compressor.

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 implies track_index refers to the target track, but it does not explain indexing conventions, required preconditions, or how the index maps to tracks. This is minimal compensation for an undocumented parameter.

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 specific action ('Add ReaComp') and the target resource ('a track'). It is immediately distinguishable from siblings like add_eq or add_limiter because it names the exact effect plugin.

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 such as track_fx_add_by_name, configure_reacomp_sidechain, or add_parallel_compression. There is no context about preferred use cases or exclusions.

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

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

The description mentions the return value (object with point index) and the value range, which adds some transparency. However, it does not disclose side effects such as whether existing points are replaced, if the envelope must be armed, or if track_index is required. Annotations only state destructiveHint=false, so the description carries most of the burden but provides limited behavioral detail.

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 concise and well-structured with a clear purpose line and a parameter list. It is front-loaded with the main action. However, it could be slightly improved by adding track_index and a note about envelope type.

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?

With five parameters and no output schema or parameter descriptions in the schema, the description needs to be thorough. It fails to describe track_index, does not clarify track vs. FX envelopes, and lacks any prerequisites or edge cases. This leaves the agent with incomplete information for a 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?

The description explains envelope_name, time, value, and shape, including units and shape mappings. It omits track_index, which is a required parameter and has no description in the schema (schema coverage is 0%). This is a significant gap, but the coverage of four parameters is still valuable.

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 a point to an envelope') and lists key parameters. However, it does not specify whether this applies to track envelopes or FX envelopes, which is needed to differentiate it from the sibling tool add_fx_envelope_point.

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 like add_fx_envelope_point or other envelope manipulation tools. The description only explains the action, leaving the agent to infer usage context from the name and sibling list.

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?

Annotations only declare destructiveHint=false; the description adds that this is a non-destructive insertion and that the return value is an object with fx_index. It does not discuss side effects, duplicate instances, or indexing conventions, but for a simple add operation the disclosure is adequate.

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

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

Two brief sentences front-load the action and the return value with no filler. Every element in the description 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 add-effect tool, the description covers the action and return shape clearly, and explicitly noting the returned fx_index is valuable since no output schema exists. Some conventions, such as zero-based indexing or track existence requirements, are left implicit, but complexity is low.

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 provides only 'track_index: integer' with 0% description coverage, and the description does not explain the parameter beyond the phrase 'to a track.' No indexing base, range, or special values are given, so the agent must rely on conventions across sibling tools.

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?

States a specific verb and resource ('Add ReaEQ') and a target ('to a track'), which distinguishes it from sibling effect-adders like add_compressor, add_limiter, and track_fx_add_by_name. It also names the return value, making the tool's core function 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?

No guidance is given about when to use this tool versus alternatives such as track_fx_add_by_name or add_limiter. The description only states the action itself and leaves selection context and prerequisites unstated.

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?

Annotations only provide destructiveHint=false, so the description carries most behavioral disclosure. It clearly indicates a mutating add operation and documents shape meaning and return shape, but it does not discuss edge cases, insertion behavior, or any prerequisites like envelope arming. This is adequate but not rich.

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

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

The description is compact and well-structured with Args and Returns sections. It front-loads the purpose and includes only relevant parameter and return details, with no filler.

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 covers the core semantics and return value, but gaps remain: three required index parameters are undefined, there is no mention of envelope arming or visibility requirements, and no output schema exists to fill in return details. It is functional but incomplete for an agent encountering the tool cold.

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 usefully explains time, value, and shape, including shape value meanings and value normalization. However, three required parameters (track_index, fx_index, param_index) are left undocumented, relying only on their self-explanatory names.

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 operation: 'Add an automation point to an FX parameter envelope.' This is a specific verb-resource pairing that distinguishes it from track-envelope operations like add_envelope_point and from deletion siblings like delete_fx_envelope_point.

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 such as add_envelope_point, get_fx_envelope_points, or delete_fx_envelope_point. It implies the FX envelope context through the name but provides no explicit selection criteria or exclusions.

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?

The annotations provide destructiveHint=false, and the description adds that the operation returns an object with fx_index, which implies a new FX insertion. It does not disclose further behavior such as whether it always appends a new instance or whether it interacts with existing limiting FX, but the mutation is clear.

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

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

The description is two short sentences with no filler. The core action is front-loaded, and the return information is separated cleanly.

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 one-parameter tool, the description is nearly complete: it states the action, the target is implied by 'to a track', and it documents the return value despite the lack of an output schema. It omits minor context such as track indexing details, but the complexity is low.

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%, but the single parameter track_index is partly clarified by the phrase 'to a track', indicating that this parameter identifies the target track. The description does not add details like zero-based indexing or the requirement that the track exists, so the compensation is only partial.

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 ('Add'), a specific resource ('ReaLimit'), and clarifies that it is a brickwall limiter applied to a track. This distinguishes it from sibling add_* tools like add_compressor and add_eq, and from generic track_fx_add_by_name.

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 intended use is implied: use when you want to add ReaLimit to a track. However, there is no explicit guidance about when not to use it, or when a generic tool like track_fx_add_by_name would be more appropriate.

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

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

Annotations provide only destructiveHint=false, so the description adds useful context such as position units ('seconds'), color default ('0 = default'), and the returned marker index. However, it does not disclose side effects of adding a marker beyond the creation itself, such as index assignment, ordering, or whether existing markers can be overwritten.

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 and well-structured with a one-line summary followed by clearly labeled Args and Returns sections. Every sentence earns its place, and there is no filler or redundant schema repetition.

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 three-parameter tool with no output schema, the description covers all parameters and the return value, which is essential. The main gap is the absence of any relationship or usage contrast with the many marker-related sibling tools, but the core operational details are present.

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%, and the description compensates by explaining position units ('Position in seconds'), name purpose, color meaning ('0 = default'), and the return value. This is meaningfully richer than the raw schema, though it does not clarify color value ranges or name constraints.

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 ('Add'), resource ('a marker'), and location ('at a position'). It is clearly distinguishable from sibling tools like delete_marker, go_to_marker, and add_region by specifying marker creation with position, name, and color.

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 explicit guidance is given about when to use this tool versus alternatives. An agent can infer it is for creating markers, but there are no exclusions, prerequisites, or comparisons to related tools such as add_region or get_markers.

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?

Annotations only declare destructiveHint=false, so the description carries the behavioral disclosure burden. It fully discloses the exact plugin list, their order, and the return value (list of added FX indices). This goes beyond the annotation and helps the agent understand the side effect and what to expect back.

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 concise and well-structured: a clear opening sentence, a numbered list for the plugin chain, and a brief note on the return value. Every sentence earns its place, and the most important information is front-loaded.

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

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

For a tool with zero parameters and no output schema, the description is nearly complete. It states the target track, exact actions taken, and the return type. A slight gap is that it does not mention whether the tool assumes the master track already exists or how it interacts with existing FX on that track, but these are minor given the tool's simplicity.

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)Skip the schema already covers everything. Baseline for a no-parameter tool is 4, and the description adds no unnecessary parameter information, which 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 uses a specific verb ('Add') and a precise resource ('standard mastering chain to the master track'), then enumerates the exact plugins in order. This clearly distinguishes it from related tools like add_parallel_compression or add_limiter, which target different signal chains.

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 it clear this is for establishing a standard mastering chain on the master track, which gives the agent strong contextual guidance. It does not explicitly state when to prefer alternative tools like add_eq or add_compressor, but the specificity of 'standard mastering chain' sufficiently implies the intended use case.

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

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

Annotations only declare destructiveHint=false, which the description does not contradict. However, the description does not disclose relevant behavior such as whether existing notes are preserved, whether a MIDI item must already exist, or whether this operation is non-destructive beyond the annotation's minimal hint. The example hints at repeated insertion but doesn't clarify underlying 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.

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

The description is compact and front-loaded with the core purpose. The Args list and example are relevant and helpful. However, the Args list is incomplete relative to the schema, which slightly undercuts the structure.

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 seven parameters, no output schema, and sparse annotations, the description is not complete enough for correct invocation. Missing definitions of track_index and item_index are critical, and the lack of usage guidance relative to add_midi_notes_batch leaves the agent to guess.

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 is responsible for explaining all parameters. It provides useful detail for pitch, velocity, start_beat, and length_beats, but completely omits the required track_index and item_index parameters, and also misses the channel parameter. The example implicitly suggests positional order but does not explain what 'item' and 'track' refer to.

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 first sentence states a specific action ('Add a MIDI note to an item') and a distinguishing characteristic ('using musical timing'). The singular 'a MIDI note' helps differentiate it from the batch sibling, though it doesn't name the sibling explicitly.

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 like add_midi_notes_batch. It implies a single-note workflow through the example, but never states exclusion criteria or conditions for choosing the batch version.

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?

The description adds the behavioral detail that timing is in beats (musical timing) and that the return is an object with a count of notes added. However, it does not disclose potential side effects such as whether existing notes are overwritten or if there are validation constraints. Since annotations only provide destructiveHint=false, the description adds some but not comprehensive behavioral context.

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

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

The description is concise, with a clear one-sentence summary followed by structured Args and Returns sections. It is front-loaded with the main purpose and includes only necessary details, making it easy to scan.

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 covers the essential information for calling the tool: the purpose, the structure of the notes list, and the return value. It does not explain error handling or edge cases, but these are not strictly required for a basic call. The description is sufficiently complete given the simplicity of the other parameters and the presence of only one complex parameter that is fully documented.

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 provides detailed semantics for the notes parameter, explaining it as a list of dicts with keys pitch, velocity, start_beat, length_beats, and optional channel. This is essential because the input schema has 0% description coverage and the notes array has no item schema. The other two parameters (track_index, item_index) are self-explanatory from their names, so the description adequately compensates for the schema gap.

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), the resource (multiple MIDI notes to an item), and the key differentiator (batch operation in one call, using beats). It is specific and distinct from the singular add_midi_note 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 implies usage for adding multiple notes at once, but it does not explicitly state when to use this tool versus alternatives like add_midi_note, nor does it mention any prerequisites or exclusions. The guidance is implied rather than explicit.

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

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

Annotations only include destructiveHint=false, so the description carries most of the behavioral disclosure burden. It transparently states that a new bus track is created, a send is added from the source track, and heavy compression is applied, which is meaningful beyond the annotation. It does not mention behavior on repeated calls, but the core side effects are clear.

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 and well-structured: a one-sentence purpose, a one-sentence mechanism, then clearly labeled Args and Returns. Every sentence earns its place and no redundant filler is present.

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 that creates multiple objects, the description covers the essential outcome and return values (bus_track_index, send_index, compressor_fx_index). It lacks details about repeated invocation behavior or edge cases like invalid track_index, but given the simple two-parameter surface and no output schema, it is reasonably complete.

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 explain the parameters, and it does. It defines track_index as 'Source track index (0-based)' and blend_db as 'Send level in dB for the compressed signal (default -6dB)', adding units, role, and default beyond 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 opens with a specific verb and resource: 'Set up New York style parallel compression for a track.' It then clearly explains the mechanism (new bus track, heavy compression, send from source), which distinguishes it from sibling tools like add_compressor, create_bus, create_send, and setup_sidechain_compression.

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 the tool: whenever the user wants New York/parallel compression on a track. However, it does not explicitly contrast with alternatives such as setup_sidechain_compression or add_compressor, nor does it state when not to use it.

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

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

With only destructiveHint:false in annotations, the description carries the burden for behavioral disclosure. It only states that a region is added and returns an object with a region index, without mentioning side effects, validation rules, or interaction with project state. This is minimal.

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

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

The description is a compact docstring with a one-line purpose, four parameter lines, and a one-line return. Every sentence earns its place and there is no fluff.

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 add operation the description covers the essentials, but it lacks context about project requirements, error behavior, and a clearer return structure than 'Object with region index.' With no output schema, a bit more detail would make it 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 coverage is 0%, so the description fully compensates by defining start and end in seconds, name as a region name, and color with its default. This adds meaning beyond the raw schema types, though it omits constraints like start < end or name uniqueness.

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 opens with 'Add a region,' a specific verb and resource. Among siblings like delete_region, get_regions, and add_marker, this clearly identifies the tool as the creating operation for regions.

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 such as add_marker, render_region, or go_to_region. There are no prerequisites, exclusions, or context hints beyond the obvious 'add a region'.

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?

The annotation destructiveHint=false already indicates the operation is not destructive. The description adds the core behavior (arming/disarming) but does not disclose side effects, such as whether the track's armed state is toggled or set, or any impact on recording. It provides minimal extra context beyond the annotation.

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

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

The description is extremely concise, with a clear title and an Args section that front-loads the essential parameter explanation. Every sentence serves a purpose and there is no fluff.

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 two parameters and no output schema, the description is incomplete because it fails to document the required track_index parameter. It also provides no information about return values, error conditions, or the effect of the operation on recording state, leaving an agent to guess at crucial details.

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 carry parameter explanations. It explains the 'arm' parameter ('True to arm, False to disarm'), but completely omits the required 'track_index' parameter, leaving its meaning and format undocumented. This is a significant gap for a required parameter.

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: 'Arm or disarm a track for recording.' It uses a specific verb and resource, and is distinct from sibling tools like arm_track_envelope. However, it does not explicitly differentiate itself from other track-related tools, though the name and action make it 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?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no context about typical workflows. It simply states the operation without suggesting when it is appropriate or what conditions must be met.

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?

The annotations only provide destructiveHint=false, so the description must carry the behavioral burden. It states the high-level arm/disarm effect but does not disclose what arming actually changes, whether an envelope must already exist, how track_index is used, or what errors or side effects may occur.

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 appropriately short and front-loaded, with the action stated first and only a minimal Args block. The omission of track_index is an accuracy problem, but not a conciseness or structure problem; the text is economical.

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 state-changing tool with no output schema and minimal annotations, the description should explain prerequisites and effects more fully. It fails to mention the required track_index, what a valid envelope name looks like, and what happens when the envelope or track 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?

Schema description coverage is 0%, so the description needed to document all parameters, but it omits the required track_index entirely. It adds minor value by explaining arm ('True to arm, False to disarm'), while 'Envelope name' just restates the parameter name.

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 first sentence names a concrete action ('arm or disarm') and a precise resource ('an envelope for recording'), so an agent can tell this is about envelope recording state. It does not explicitly contrast with the similarly named sibling arm_track or with envelope automation functions, but the 'for recording' qualifier provides enough differentiation for a 4.

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?

There is no guidance about when to use this tool versus alternatives such as arm_track, set_track_automation_mode, or get_track_envelope. The only contextual clue is 'for recording,' which is implied rather than stated as a selection rule, and no exclusions or prerequisites are given.

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

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

Annotations already declare idempotentHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral context beyond that by explaining that it 'Resets the held peak values that accumulate during playback,' which helps the agent understand the effect. This is valuable but not extensive; a brief mention of the lack of side effects or confirmation of no audio impact would be richer.

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 exceptionally concise—two short sentences. The main action is front-loaded, and the second sentence provides necessary context without redundancy. Every word earns its place, making it easy for an agent to parse quickly.

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 no-parameter, no-output-schema tool with annotations covering safety, the description fully covers what the tool does, why, and when to use it. There is no missing behavioral or usage information that an agent would need to correctly invoke it.

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?

Tool has zero parameters, so schema coverage is trivially 100%. Per the rubric, the baseline for 0 params is 4. The description doesn't need to explain any parameters, and it doesn't attempt to invent any. It correctly stays silent on inputs.

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 clear verb ('Clear'), specific resource ('peak hold indicators'), and scope ('all tracks including master'), making it unambiguous and distinct from any sibling. The second sentence clarifies the underlying purpose, reinforcing what exactly is being reset.

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 includes explicit guidance: 'Use before a fresh playback pass when you want clean readings for gain staging.' This tells the agent exactly when to invoke it. No alternatives or exclusions are needed because there are no competing tools for this action, but the context provided is clear and actionable.

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?

The destructiveHint annotation already signals destructive behavior. The description only restates that all points are deleted and adds no further behavioral context, such as irreversibility, effect on automation mode, or what envelope types are valid. It does not contradict the annotation, but it also adds no value beyond it.

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 text is short and front-loaded, but the Args section is incomplete and misleading because it lists only envelope_name while ignoring the required track_index. Brevity is not beneficial when it omits critical parameter 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?

With two required parameters, a destructive hint, and no output schema, the description should explain how track_index and envelope_name identify the target envelope. It does neither. It also fails to clarify whether this applies to track envelopes or FX envelopes, making correct invocation uncertain.

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 it only repeats envelope_name with the unhelpful phrase 'Envelope name.' It completely omits track_index, which is a required parameter. This provides no meaning beyond the raw schema and actively misleads by listing only one of the two required arguments.

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 clear action and resource: 'Delete all points from an envelope.' The verb 'Delete' and resource 'envelope' are specific, though it does not explicitly distinguish track envelopes from FX envelopes. The sibling tool clear_fx_envelope suggests clear_envelope refers to track envelopes, but the description itself relies on that inference.

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?

There is no guidance about when to use this tool versus alternatives like delete_envelope_point or clear_fx_envelope. The description does not mention exclusions, prerequisites, or a preferred context. An agent must infer usage from the tool name and sibling list.

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?

The description goes beyond the destructiveHint annotation by specifying exactly what gets destroyed ('all automation points') and disclosing the return value ('Object with deleted_count'). This adds useful behavioral context without contradicting the annotation.

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

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

The description is extremely concise and well-structured. The first sentence states the operation and scope, and the second documents the return value. There is no filler or unnecessary duplication.

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 three-parameter destructive operation, the description covers the core action and return shape. However, it omits parameter semantics and usage context, which are important given the lack of schema descriptions and the absence of an output schema. It is minimally viable but not fully complete.

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 needed to compensate, but it does not explain track_index, fx_index, or param_index. The parameter names are somewhat self-explanatory, but the description adds no detail about indexing conventions, which envelope is targeted, or how the parameters relate to the described operation.

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 ('Clear'), a specific resource ('all automation points from an FX parameter envelope'), and the scope of the operation. It is easily distinguished from the sibling tool 'clear_envelope' by explicitly targeting the FX parameter envelope rather than a generic envelope.

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 related alternatives like 'clear_envelope' or 'delete_fx_envelope_point'. There are no stated exclusions, prerequisites, or context for choosing this operation, so the agent is left to infer usage from the name and description alone.

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

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

The description adds the return value (count of deleted notes) and explicitly states the destructive action ('Delete all'), which aligns with the destructiveHint annotation. Beyond the existing annotation, it provides the return format and confirms the scope. It does not mention reversibility, selection behavior, or other side effects, but the annotation covers the core destructive nature.

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

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

Two short sentences with zero waste. The action is front-loaded, and the return information is briefly stated. No redundancy or filler.

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 MIDI operation with two undocumented parameters, the description is insufficient. It lacks parameter explanations and any guidance on when to use this tool over siblings like delete_midi_note. The return count is mentioned, but the overall context for correct invocation is incomplete.

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%, and the description provides no explanation for track_index or item_index. It merely references 'an item' without specifying how the parameters map to the item. The burden falls on the description to clarify parameters, and it completely fails to do so.

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 ('Delete') and resource ('all MIDI notes from an item') with clear scope. It distinguishes from single-note deletion (delete_midi_note) and note addition (add_midi_note) by targeting all notes in an item. The name and description align perfectly.

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 clearly implies when to use it: to remove all MIDI notes from an item. However, it does not explicitly compare with alternatives like delete_midi_note (single note) or note editing tools, nor does it state any conditions for use vs. not use. No exclusions or alternative routing are provided.

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?

Annotations already declare destructiveHint: false, indicating this is non-destructive. The description adds no further behavioral detail beyond the obvious action of clearing a UI selection, which is implied. Since the annotation covers safety, the description's minimal disclosure is acceptable but does not go beyond the annotation.

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

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

The description is a single, concise sentence that communicates exactly what is needed without excess. It is front-loaded with the verb and resource, making it immediately clear and efficient.

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 no parameters, no output schema, and a simple state-changing action, the description is complete. It fully specifies what the tool does, and the existence of sibling tools like set_time_selection provides necessary context. There is nothing an agent needs to call this correctly that 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?

With zero parameters, the baseline is 4 per the rubric. There are no parameters to explain, and the description correctly omits any parameter-related information, as none exist. The schema coverage is 100% (empty properties), so nothing is missing.

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 'Clear the time selection.' uses a specific verb ('clear') directly on a well-defined resource ('time selection'), making the tool's purpose unmistakable. It clearly distinguishes from siblings like 'set_time_selection' and 'get_time_selection' by indicating a removal action rather than a set or retrieval.

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?

While no explicit when-to-use or alternative routing is provided, the action itself is straightforward and self-explanatory within the context of REAPER's time selection operations. The sibling list includes set_time_selection, implying that clear is for removing an existing selection, which is contextually clear even though not explicitly 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?

Annotations only provide destructiveHint: falseched. The description adds useful behavioral context by specifying that use_sidechain maps to auxiliary input channels 3-4 and that a configuration status object is returned. However, it does not disclose side effects, prerequisites, or behavior when ReaComp is not present at the given indices.

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, front-loaded with the core purpose, and uses a clear Args/Returns structure. Every sentence contributes meaning without wasted words.

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 config tool with three parameters locked to a single effect type, the description is mostly adequate. However, there is no output schema, the return object is vague, and no usage context or prerequisites are provided, leaving some gaps for an agent deciding how to invoke it.

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 carries the full burden, and it succeeds: track_index and fx_index are defined as 0-based indices, and use_sidechain is explained with concrete channel meanings. This fully compensates for the bare 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 states a specific verb and resource: 'Configure ReaComp to use sidechain input for detection.' This is clear and the parameters reinforce intent, but it does not explicitly distinguish this tool from siblings like setup_sidechain_compression or setup_sidechain_send.

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 about when to use this tool versus the sibling setup_sidechain_* tools, nor are prerequisites mentioned. The description only explains the parameters, leaving the agent to infer context.

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 only destructiveHint=false, annotations give minimal safety information. The description doesn't disclose that the operation modifies the clipboard, potentially overwriting previous clipboard contents, or whether it affects the original items (it copies, so it shouldn't). No additional behavioral context is provided.

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

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

The description is a single, concise sentence with no fluff. It's appropriately short for a simple operation.

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, the description is minimal but lacks any note about the clipboard's effects or what 'selected items' means in this context. For a copy operation, it should clarify that it copies to clipboard (not duplicating in place) and that it requires existing selection.

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?

There are 0 parameters, so the schema is trivially complete. The description adds no parameter-specific information, but since none exist, a baseline of 4 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 'Copy selected items to clipboard' states the verb and resource but is vague about what 'items' refers to (MIDI items, audio items, tracks?). It doesn't distinguish from sibling tools like cut_selected_items or paste_items, which are similarly named.

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 provides no guidance on when to use this tool versus alternatives. There's no mention of prerequisites (e.g., what needs to be selected) or exclusions, leaving the agent to infer that it operates on currently selected items.

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?

Annotations only provide destructiveHint=false, so the description carries most of the behavioral burden. It states that the tool creates a bus and routes tracks, and mentions a return value, but does not disclose details like whether existing sends are preserved, how routing is represented, or what side effects occur on the source tracks. It does not contradict the annotations.

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 and well-structured, with a one-sentence summary followed by Args and Returns sections. Every sentence adds useful information, and there is no redundant content.

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 no output schema and minimal annotations, the description covers invocation well but leaves gaps: 'routing info' is vague, index semantics are not specified, and there is no mention of preconditions or behavioral edge cases. It is adequate but incomplete.

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%, and the description fully compensates: 'name' is explained as the bus track name, and 'source_track_indices' is explained as the list of track indices to route. Both required parameters receive meaningful semantics beyond their raw types.

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 names a specific verb and resource: 'Create a submix/stem bus and route specified tracks to it.' This clearly distinguishes it from routing-related siblings like create_send, because it describes the unique bus-creation behavior.

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 explains what the tool does but gives no guidance on when to choose it over alternatives such as create_send, insert_track, or add_mastering_chain. There are no explicit use conditions, exclusions, or prerequisites.

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?

Annotations only include destructiveHint=false, so the description carries some burden. It adds that the item is 'empty' and that the return value is an object with item info including the new item_index. However, it does not disclose behaviors such as whether the item is inserted at the edit cursor, whether it replaces existing items, or any selection or focus side effects. No contradiction with annotations exists.

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 and well-structured: a one-sentence purpose, an Args section, and a Returns section. Every line earns its place, with no redundant fluff or repetition of schema fields beyond useful unit clarification.

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 creation tool, the description covers the core action, two of three parameters, and the return shape. However, it omits track_index entirely, provides no usage context or alternatives, and does not clarify behavior like insertion position or interaction with existing MIDI items. It is minimally viable but not complete.

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 documents position and length with units ('seconds'), which adds meaning. However, track_index is a required parameter and is completely omitted from the description, leaving the agent to infer its purpose from the phrase 'on a track'. Missing one of three required parameters is a significant gap.

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 ('Create') and resource ('empty MIDI item on a track'), which clearly distinguishes it from siblings like add_midi_note or add_midi_notes_batch that add notes rather than creating an empty item container. The phrase 'empty MIDI item' is precise and unambiguous.

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

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

No guidance is given about when to use this tool versus alternatives such as add_midi_note, add_midi_notes_batch, or clear_midi_item. There are no exclusions, prerequisites, or context about typical workflows. The description only states what it does, not when it should be chosen.

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?

The description adds a useful behavioral note about the inability to name unsaved projects, which goes beyond the destructiveHint annotation. However, it does not explain the destructive nature of creating a new project (e.g., whether it replaces the current project), leaving important side effects undisclosed.

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 concise and front-loaded, stating the core action in the first sentence and providing a helpful clarifying note in the second. No unnecessary words.

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 marked destructive, the description does not explain the side effects of creating a new project (e.g., discarding the current one). The absence of an output schema also leaves return behavior unspecified. This is a significant gap for an agent to call it safely.

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 zero parameters, the schema is empty, and the description explains why there is no name parameter, adding meaningful context about the parameter's absence. This exceeds the baseline for zero-parameter tools.

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 'create' and resource 'new REAPER project', distinguishing it from sibling tools like create_bus or create_midi_item. The note about naming adds precision without ambiguity.

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. The only note about the removed name parameter is not usage guidance, and no exclusions or alternative tools are mentioned.

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

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

The description discloses that the tool returns an object with send_index, which is useful. Annotations only include destructiveHint: false, so the description carries some burden. It does not explain behavior on invalid track indices, whether existing sends are overwritten, or any other side effects. The return info adds some transparency, but it's not comprehensive.

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

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

The description is extremely concise: a single sentence stating the purpose, followed by a clean argument list and a return note. There is no fluff, and the core purpose is front-loaded. Every sentence earns its place.

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

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

For a simple two-parameter tool with no output schema, the description covers the essentials: purpose, parameter meaning, and return format. It does not mention prerequisites (e.g., track existence) or contrast with sidechain sends, but given the low complexity, it is reasonably complete. The missing usage guidance is the main gap.

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 each parameter's role ('src_track: Source track index', 'dest_track: Destination track index') and clarifies they are 0-based, adding meaning beyond the plain integer type in the schema. This is sufficient for the two parameters.

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: 'Create a send from one track to another.' It specifies the verb (create), the resource (send), and the relationship (from one track to another). This is distinct from sibling tools like delete_send, set_send_volume, and setup_sidechain_send, so an agent can readily identify 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 provides no guidance on when to use this tool versus alternatives. There are many send-related tools (e.g., setup_sidechain_send, delete_send), but no mention of when to prefer create_send over them. No exclusions or prerequisites are stated, leaving the agent to infer usage context.

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

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

The description explicitly discloses the destructive behavior: 'discarding all other takes.' This goes beyond the destructiveHint annotation by specifying exactly what gets destroyed (other takes) and what is preserved (the active take). It does not contradict the annotation.

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

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

A single sentence that is front-loaded with the action and resource, and includes the key behavioral consequence. No wasted words.

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 operation with no output schema, the description covers the core behavior. However, it lacks context about prerequisites (e.g., what happens if the item has only one take, or if no active take is set) and does not mention whether the operation is undoable. Given the destructiveHint annotation, a bit more cautionary context would be valuable.

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 carries the burden. However, the parameter names (track_index, item_index) are self-explanatory and the description clarifies the operation's target ('a media item'). The description does not add detail about indexing semantics (e.g., zero-based vs one-based), but the schema itself is minimal and the names are clear enough.

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 ('Crop'), a specific resource ('a media item'), and the exact scope ('to its active take, discarding all other takes'). This clearly distinguishes it from sibling tools like delete_take, explode_takes, and set_active_take, which operate on takes differently.

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 the use case: when you want to reduce a multi-take item to just the active take. However, it does not explicitly state when to use this tool versus alternatives like delete_take or explode_takes, nor does it mention prerequisites (e.g., the item must have multiple takes, an active take must exist).

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?

Annotations already declare destructiveHint=true, so the destructive nature is known. The description adds the clipboard behavior, which clarifies the tool is a move rather than a delete. However, it does not disclose that the original items are removed from their current location or that the clipboard contents are overwritten, though these are implied by 'cut'. The description adds minimal context beyond the annotation.

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

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

A single sentence with no filler. It states the action, target, and destination in under ten words. This is appropriately concise and 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 no-parameter, straightforward operation, the description is sufficient. It communicates the action and the clipboard destination. It does not explicitly state that a selection is required, but this is implied by the name and is a common prerequisite for such tools. No output schema is needed for a side-effect operation, and the destructive hint covers risk.

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 coverage is 100% (empty). There is nothing to explain about parameters. With no parameters, a baseline of 4 is appropriate; the description does not need to provide additional parameter context.

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 'cut' and the resource 'selected items', with the result 'to clipboard'. It distinguishes from delete (removes without clipboard) and copy (keeps original), though it doesn't explicitly name alternatives. The purpose is unambiguous for an agent.

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 explicit guidance on when to use this tool versus copy_selected_items or paste_items. The use case is implied by the name and description, but there is no mention of when not to use it or prerequisites like having a selection. It does not name sibling alternatives, so the agent must infer the correct context.

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?

Annotations already declare destructiveHint=true, and the description's 'Delete' matches that hint. However, no additional behavioral context is provided—such as irreversibility, effect on automation, or whether the envelope point is removed from the active take or item. The description adds no value beyond the annotations.

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 short, but under-specification is not conciseness. It fails to document two of three required parameters and provides no structural details. The single effective sentence does not earn its place because it omits critical 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?

With three required parameters, no output schema, and no parameter documentation in the schema, the description is critically incomplete. It leaves track_index and point_index unexplainedites, making it impossible for an agent to confidently construct a valid 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 0%, so the description must compensate by explaining the parameters. It only lists 'envelope_name: Envelope name' without describing track_index or point_index, which are both required. This is insufficient for an agent to correctly invoke the function.

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: 'Delete an envelope point.' The name and description are consistent)Skip, and the sibling delete_fx_envelope_point is distinguishable by the 'fx' qualifier. Still, it doesn't explicitly differentiate from clearing envelopes or deleting FX envelope points, so it's not a 5.

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

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

No guidance is provided about when to use this tool versus alternatives like delete_fx_envelope_point or clear_envelope. The description only states what it does, leaving the agent to infer selection criteria 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?

Annotations already declare destructiveHint=true, so the description must add context beyond that. It only repeats the destructive nature implicitly and provides no additional behavioral detail (e.g., irreversible, shifts subsequent points, affects automation playback). This contradicts the annotation? No, it aligns, but falls short of enhancing 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?

Very concise: two sentences, front-loading the core purpose and then explaining the one ambiguous parameter. No fluff. It focuses limited characters on the key detail (point_index base).

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 4 required parameters, all undocumented in schema, and a destructive operation, the description is too thin. It doesn't clarify how the envelope is identified (track/fx/param indices) or provide usage example or prerequisites. Output schema absent, but return value not critical for a deletion tool. Should include more context for an agent to call 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?

Schema description coverage is 0%, and parameters are bare integers with no descriptions. The description only explains point_index as '0-based', which is valuable, but track_index, fx_index, and param_index are unexplained. Since coverage is low, the description should compensate, but it only partially does. Baseline for low coverage is low, so 3 is fair.

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 clearly states the action: 'delete an automation point from an FX parameter envelope', specifying the resource (FX parameter envelope) and the operation (delete). This distinguishes from similar siblings like delete_envelope_point and clear_fx_envelope, though it doesn't explicitly name them.

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 explicit guidance on when to use this tool versus alternatives. It implies usage for deleting automation points but does not explain prerequisites (e.g., envelope must exist) or contrast with clear_fx_envelope, delete_envelope_point, or get_fx_envelope_points. Description lacks exclusions or alternative routing.

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?

The destructiveHint annotation already communicates that this is a destructive operation, and the description adds no further behavioral context. It does not mention whether the deletion is permanent, undoable, or what happens to contained MIDI notes, but there is no contradiction with the annotation.

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

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

The description is very short and front-loaded with the core action, containing no filler. However, it is slightly too terse to cover important context such as the indexing scheme, which could have been added in a few extra words without harming 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?

For a simple two-parameter destructive operation with a destructiveHint annotation, the description is minimally adequate. It lacks guidance on undo behavior, permanence, index base, and the relationship to selection-based deletion, which leaves some important gaps for an agent deciding how to invoke it.

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 carries the burden of explaining parameters. It does not clarify that track_index and item_index identify the target item, nor does it specify indexing conventions or how the two indices relate. The parameter names are somewhat self-explanatory, but the description adds no semantic value.

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 an explicit verb and object ('Delete a media item'), clearly identifying the operation and resource. It is distinguishable from sibling tools like delete_take or delete_midi_note, though it could more explicitly differentiate from delete_selected_items by mentioning that it targets an item by index rather than current selection.

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 such as delete_selected_items, clear_midi_item, or delete_take. The sibling list contains several deletion-related tools, and the description gives the agent no criteria for choosing among them.

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?

The annotation destructiveHint=true already indicates the destructive nature. The description simply restates 'delete' without adding extra context such as permanence, undoability, or side effects. It is consistent with the annotation but adds no additional transparency beyond it.

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 that directly states the action and target. There is no extraneous information, making it highly concise and well-structured.

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

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

For a simple one-parameter destructive tool, the description is minimal but adequate for a basic call. It does not explain how to obtain the index or any indexing conventions, which could be important for correct usage. Given the simplicity, a score of 3 reflects that it is functional but lacks deeper context.

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 provides no description for marker_index (0% coverage). The description clarifies that marker_index is the index of the marker to delete, which adds meaning beyond the raw schema. However, it does not specify whether the index is zero-based or how to retrieve it, so it is not fully comprehensive.

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 (delete), the resource (marker), and how to identify it (by index). This distinguishes it from siblings like delete_region and add_marker, 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention that the index should be obtained from get_markers, nor does it provide any prerequisites or exclusions. The description is purely declarative with no contextual instructions.

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?

The annotation destructiveHint=true already signals that this operation is destructive. The description adds minimal behavioral context beyond that—it specifies the target (a MIDI note within an item) but doesn't disclose whether the deletion is undoable, whether it affects only the selected note or all notes at that index, or what happens if indices are out of range. With the annotation covering the destructive nature, a 3 is appropriate: the description adds some context but not rich behavioral detail.

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 target. It earns its place with no wasted words. However, it could have used the brevity to add parameter context or usage guidance without becoming verbose.

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 mutation tool with no output schema and zero parameter documentation, the description is incomplete. It doesn't explain the indexing semantics, prerequisites, or effects beyond the basic action. The destructiveHint annotation covers the safety warning, but an agent still lacks enough information to call this tool correctly without guessing at index meanings.

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 for the three parameters (track_index, item_index, note_index). The description only mentions 'an item' and 'a MIDI note' but doesn't explain the indexing scheme (e.g., zero-based vs one-based, which item, which note). It doesn't clarify the relationship between track_index and item_index or how note_index maps to notes within the item. This is a significant gap for a tool with three required integer parameters.

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 'Delete a MIDI note from an item' clearly states the verb (delete), the resource (MIDI note), and the container (an item). It distinguishes itself from sibling tools like add_midi_note, set_midi_note, and clear_midi_item, though it doesn't explicitly name them. The purpose is clear and specific.

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 provides no guidance on when to use this tool versus alternatives like delete_selected_items, clear_midi_item, or remove_overlapping_midi_notes. It doesn't mention prerequisites (e.g., the item must contain MIDI notes, indices must be valid) or context for when deletion is appropriate. An agent must infer usage from the name and schema 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?

The annotation destructiveHint: true already covers the destructive nature, so the description adds almost nothing beyond that. It does not disclose whether the operation is permanent, whether it can be undone, or what happens to the region's content. The description merely restates the action without additional behavioral context.

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

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

The description is a single, efficient sentence that front-loads the action. There is no wasted text, and it is appropriately sized for a tool with one parameter. Perfectly concise.

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 minimal schema and lack of output schema, the description should explain how to use the index (e.g., referencing get_regions to retrieve the list) and specify indexing semantics. It provides none of this, leaving an agent without enough information to call the tool correctly, especially regarding the meaning of 'index'.

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 schema description coverage at 0%, the description must compensate for the missing parameter documentation. It only mentions 'by index', which largely repeats the parameter name 'region_index'. It does not clarify indexing convention (0-based vs 1-based), how to obtain a valid index, or what the index refers to in the list of regions. This is insufficient for a tool with an undocumented parameter.

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 clear verb ('Delete'), resource ('region'), and identifier ('by index'). It is unambiguous about what the tool does and is distinct from siblings like delete_marker or delete_track based on the noun. However, it does not explicitly differentiate itself from other deletion tools, so it falls short of a 5.

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?

There is no guidance on when to use this tool versus alternatives such as delete_marker or delete_item. No context about prerequisites (e.g., needing to list regions first) or conditions that select it is provided. The usage is only implied by the verb and resource, which is minimal.

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?

The destructiveHint annotation already signals mutating behavior, and the description adds the 'all selected' scope. However, it does not disclose whether the operation is undoable, whether it no-ops with no selection, or whether it affects only media items. The description is consistent with the annotation but adds limited behavioral detail.

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, direct sentence that front-loads the action and scope. Every word earns its place, and there is no redundant or filler content.

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 no-parameter, destructive tool, the description conveys the core behavior, but it leaves gaps around what 'items' means and what happens if nothing is selected. Given the destructive nature and no output schema, slightly more context would help an agent invoke it confidently.

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 input schema is complete by definition. The description does not need to explain parameter semantics, and there is no ambiguity introduced by missing parameter documentation.

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 identifies the action (delete), the resource (selected items), and the scope (all). It is distinguishable from singular tools like delete_item and from selection-oriented tools like cut_selected_items, though it does not explicitly state that 'items' refers to media items rather than tracks or other entities.

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?

There is no guidance on when to use this tool instead of alternatives such as delete_item, cut_selected_items, or clear_track. The intended context (delete all currently selected media items) is only implied by the name and description, with no explicit exclusions or prerequisites.

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?

The annotations include destructiveHint=true, which covers the primary behavioral trait (destructiveness). The description adds that the deletion is permanent, but it does not disclose other potential behaviors like whether it has side effects on other sends, whether it requires the track to be unmuted, or whether it returns anything. Given the annotation, the description's minimal addition is acceptable but not comprehensive.

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

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

The description is extremely concise—two lines covering the action and parameters. The information is front-loaded with the core action in the first sentence. It does not waste words, but it could be slightly more structured with a clearer separation between the description 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?

Given the tool's simplicity (2 integer parameters, no output schema), the description covers the essential calling contract. However, it lacks context on how to find the correct send_index, potential errors (e.g., out-of-range indices), and the broader use case. Since the description is the only source of behavioral guidance beyond annotations, a bit more contextual detail would make it more complete.

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 0% parameter description coverage, so the description must compensate. It does define both parameters ('track_index' and 'send_index') and clarifies they are 0-based, which is useful. However, it does not explain what a 'send' is or how to obtain the indices, leaving some ambiguity that could be filled by referencing sibling tools like 'get_track_num_sends'.

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 ('delete') and the resource ('a send from a track'), making the purpose unambiguous. It is distinct from sibling tools like 'create_send' or 'get_track_num_sends', which are easily differentiated by the verb and object, though it does not explicitly compare itself to them.

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 provides no guidance on when to use this tool versus alternatives. It does not mention that deletes are irreversible or suggest when deletion might be appropriate (e.g., when cleaning up routing). The only context is the destructive annotation, which is implicit rather than explicit in the description.

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?

The description discloses a non-obvious behavior beyond the destructiveHint annotation: 'The take is activated first, then removed.' This adds useful context about what happens during deletion, though it does not discuss side effects on the active take state or undo behavior.

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

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

The description is compact and front-loaded, with a clear one-sentence purpose followed by an Args section. Every sentence adds value, and there is no redundant filler or restatement of the tool name.

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 three-parameter tool with no output schema, the description leaves important context unexplained: what track_index and item_index refer to, how they relate to take_index, and what happens on invalid indices. The activation note is helpful, but it does not fully compensate for the missing parameter context.

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 needed to explain all three required parameters. It only documents take_index (including 0-based indexing), while track_index and item_index are left entirely unexplained beyond their schema names.

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 action ('Delete') and a specific resource ('a specific take from a media item'), which clearly distinguishes it from sibling tools like delete_item, delete_track, and delete_selected_items. The singular 'specific take' also signals that this targets one take by index rather than a bulk 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?

There is no guidance about when to choose this tool over alternatives such as delete_item, explode_takes, or crop_to_active_take. The description implies usage by its wording, but it does not state exclusions, prerequisites, or the relationship to other take/item deletion tools.

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?

The annotation destructiveHint=true already flags that this tool mutates state. The description adds useful behavioral detail beyond the annotation: track_index is 0-based and the master track (-1) cannot be deleted. It does not spell out side effects like removal of items or child tracks, but the destructive annotation lowers the burden and the critical prohibition is disclosed.

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

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

The description is minimal and front-loaded. The purpose is stated in the first three words, and the only supporting detail is the parameter explanation. Every sentence contributes information, and there is no fluff or repetition of the schema.

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 destructive tool with no output schema, this is complete. The agent knows what to delete, which index is valid (0-based), which index is prohibited, and that the operation is destructive via annotations. Nothing necessary to make the call 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?

With 0% schema description coverage, the description fully compensates. It explains that track_index is 0-based and explicitly calls out the forbidden value -1 (the master track). This gives an agent the semantic information absent from the raw integer 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 opens with a specific verb and resource: 'Delete a track.' This clearly distinguishes it from the many delete_* siblings (delete_midi_note, delete_take, delete_item) by naming the exact object being removed. No ambiguity remains about what resource this tool operates on.

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 intended use is implied by the name and opening sentence: call this when you want to remove a track by its index. However, the description does not explicitly discuss when to prefer this over alternatives or mention any prerequisite, such as obtaining a valid track index first. It also only partially guides usage by stating that the master track cannot be deleted.

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?

The description only mentions the return object, and the annotation already signals non-destructiveness. It does not disclose whether the duplicate is placed adjacent to the original, whether all properties are copied, or how selection state is affected—important behavioral context for an agent.

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

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

The description is very short, front-loaded with the action, and the return line is structured. It contains no filler, though it could be slightly more informative without losing 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?

For a mutation tool with no output schema, this description is too thin. An agent cannot determine what the duplicate will look like, where it will appear, or how the indices relate to the operation. The missing behavioral details make it inadequate for confident 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?

The input schema has zero description coverage, and the tool description does not explain the role of track_index and item_index or any indexing conventions. The parameter names are self-explanatory, but the description adds no deeper meaning beyond what the schema names already imply.

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 the action 'Duplicate' and the resource 'media item', clearly identifying what the tool does. It does not differentiate from siblings like copy_selected_items or paste_items, but the core 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?

There is no guidance on when to use this tool versus alternatives such as copy/paste or other item manipulation tools. No prerequisites, exclusions, or sibling comparisons are provided, leaving the agent to infer the appropriate context.

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?

The annotation destructiveHint=true already flags the destructive nature, so the description does not need to repeat that. It adds the 'in place' modifier and the outcome (each take becomes its own overlapping item), which clarifies that the original take structure is modified rather than creating new items. This goes beyond the annotation by describing the result.

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, focused sentence that front-loads the verb and resource and immediately states the effect. There is zero fluff; every word contributes meaning. It is concise without sacrificing clarity.

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 action with two parameters and no output schema, the description explains the core behavior but omits parameter semantics. The tool's simplicity reduces the need for extensive detail, but the lack of parameter explanation is a real gap. Given that annotations cover destructive behavior and the effect is described, it is minimally complete but not 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?

Schema description coverage is 0% and the description provides no explanation for track_index or item_index. While the parameter names are somewhat self-explanatory, the description does not compensate for the lack of schema details. An agent cannot know whether indices are zero-based, what ranges are valid, or how they relate to the media item. This is a significant gap.

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 'explode' and the resource 'all takes of a media item', with a precise outcome: each take becomes its own overlapping item. This distinguishes it from sibling tools like crop_to_active_take (which keeps only the active take) or delete_take (which removes takes). The purpose is unmistakable.

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

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

The description implies when to use it (when you want to separate takes into individual overlapping items) but does not explicitly mention alternatives or when not to use it. Sibling tools like crop_to_active_take or delete_take are not referenced, leaving the agent to infer the choice from context. No exclusions are provided.

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?

Beyond the destructiveHint annotation, the description discloses the conditional side effect: if instantiate is True and ReaEQ is absent, it will be added. It also specifies the return contract. It does not mention where the FX is inserted or error behavior, but the key behavior is transparent.

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

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

The description is compact and well-structured: a one-sentence purpose followed by Args and Returns. Every sentence contributes useful information with no filler.

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 return value and conditional side effect are clearly specified, which is good given there is no output schema. However, the required track_index parameter is not explained, and invalid-track or not-found edge cases are not addressed, leaving the tool slightly incomplete for autonomous use.

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 explains instantiate well ('If True and ReaEQ is not present, add it'), but it does not describe track_index at all. With 0% schema description coverage, the required track_index parameter is left undocumented beyond its integer type, which is a significant gap.

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: 'Find ReaEQ on a track', with an optional add behavior. This clearly distinguishes it from add-only tools like add_eq and other FX query tools.

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 use for locating ReaEQ or ensuring it exists, but it gives no explicit when-to-use guidance and does not mention alternatives such as add_eq for pure addition. An agent must infer the intended usage context.

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 readOnlyHint=true already declaring this as a safe read, the description goes further by defining the return shape and the sentinel value -1 for 'no active take', which is genuinely useful behavioral context an agent can act on. It stops short of describing what happens on an invalid track/item 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?

Two tight lines: the purpose sentence front-loads the verb and resource, and the Returns block cleanly scopes the output. No filler.

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?

There is no output schema, so the description rightly carries the return contract, and the -1 sentinel makes it callable without ambiguity. The remaining gap is that the two required indexing parameters are undescribed, leaving callers to guess how to address a valid item.

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% and the description adds nothing about track_index or item_index beyond implying they locate a media item. With two undocumented required integer parameters, the agent gets no help interpreting indexing base, valid ranges, or whether indices refer to the currently selected track.

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 precise verb (Get) and resource (the index of the active take of a media item), and its return specification (-1 when no active take exists) cleanly separates it from siblings like get_takes, which lists takes, and set_active_take, which mutates.

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?

Reading the description makes it obvious this is the read counterpart to set_active_take, but there is no explicit 'use this when... vs set_active_take/get_takes when...' guidance or mention of a prerequisite that an item must be selected or exist. Usage is implied rather than stated.

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

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

The readOnlyHint annotation already covers the read-only nature of the operation, and the description is consistent with it. The description adds the 'all tracks' scope but does not disclose whether the master track is included, how much data is returned, or any other behavioral details.

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

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

The description is one short, front-loaded sentence with no filler or repetition. It conveys the essential action and resource scope efficiently.

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 tool, the description is close to sufficient, but since there is no output schema it leaves the return format and content unspecified. An agent cannot tell whether the result includes track IDs, names, indices, or nested data.

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 schema coverage is 100%, so the description has no parameter semantics to add. This is the appropriate baseline for a no-parameter tool.

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 action ('Get information') and resource ('all tracks in the project'), which distinguishes it from siblings like get_track, get_selected_tracks, or get_track_count. However, 'information' is broad and does not specify what data is actually returned.

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 about when to use this tool versus alternatives such as get_track, get_selected_tracks, or get_track_count. The description does not mention scope exclusions, filtering behavior, or any condition that would make this tool the preferred choice.

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?

Annotations already declare readOnlyHint=true, so the safe read-only nature is known. The description adds useful behavioral context beyond that: the return value is an object containing the cursor position in seconds. It does not mention side effects, but none are expected given the read-only annotation.

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 short lines with no filler. It front-loads the verb and resource, then immediately states the return type and units. Every sentence 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 zero-parameter, read-only getter, the description is nearly complete: it names the resource, the return type, and the units. The only minor ambiguity is the exact key name inside the returned object, but this does not affect the agent's ability to invoke 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 input schema has zero parameters, so there is nothing to document. The baseline of 4 applies because no parameter guidance is needed; the description correctly focuses entirely on the return value.

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: 'Get the edit cursor position.' It clearly distinguishes this from the sibling get_play_position, which queries the playhead rather than the edit cursor. The addition of return units further clarifies intent.

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 context by naming the exact resource (edit cursor) and result format. It does not explicitly mention alternatives or when not to use it, but the resource name itself disambiguates from get_play_position and set_cursor_position. For a no-parameter getter, this is adequate.

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?

The annotation readOnlyHint=true already declares this a safe read operation, and the description's 'Get' wording is consistent with that. The description adds a small behavioral note that it returns 'an Object with point count,' but it doesn't disclose anything beyond what the annotation and tool name already imply. No contradiction, but no meaningful added transparency either.

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 and front-loaded with its one-line purpose. The Args/Returns docstring format is lightweight. However, the Args section is misleadingly incomplete (it lists one of two parameters), which slightly detracts from otherwise lean structure.

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 2-parameter tool with no output schema and 0% schema description coverage, the description should at minimum document both parameters. It documents only envelope_name and omits track_index entirely, leaving the agent unable to correctly construct a call. The simple read operation and existing annotation lower the bar, but the missing required parameter is a significant completeness failure.

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 carries the full burden of documenting parameters. It only documents envelope_name, which is near-tautological ('Envelope name'), and completely omits the required track_index parameter. An agent cannot know what track_index refers to or how to supply it, which is a critical gap for a 2-parameter tool.

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 clear verb and resource: 'Get the number of points in an envelope.' This distinguishes it from sibling get_envelope_points (which returns the points themselves) and the mutating add/delete/clear envelope tools. However, it does not name or reference any sibling for explicit differentiation, so it's clear but lacks the explicit contrast that would earn a 5.

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?

There is no guidance on when to use this tool versus alternatives such as get_envelope_points, get_fx_envelope_points, or get_track_envelope. The description provides no contextual triggers, exclusions, or conditions that would help an agent choose this tool over its many envelope-related 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?

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds that it returns an object containing a list of points with time, value, and shape, but does not disclose behavior for missing envelopes, ordering, or empty envelopes.

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 short, front-loaded, and free of filler. It follows a clear 'summary, args, returns' structure. The incomplete Args section is a content issue rather than a conciseness problem.

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 definition is not complete enough for correct invocation: track_index is required but undocumented, and there is no distinction from FX envelope tools. With no output schema and sparse annotations, an agent needs more context than this provides.

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%, and the description only mentions envelope_name, omitting the required track_index parameter entirely. The phrase 'Envelope name' adds little beyond the parameter name, and dropping a required parameter is misleading for an agent trying to invoke the tool.

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?

States a clear verb and resource: 'Get all points from an envelope.' It specifies the return format, so an agent understands the core action. However, it does not distinguish track envelopes from FX envelopes, even though get_fx_envelope_points exists as a 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?

No guidance is given about when to use this tool versus alternatives like get_fx_envelope_points or get_envelope_point_count. The intended usage must be inferred entirely from the tool name and sibling context.

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?

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful behavior beyond annotations: the exact return shape ('ret' boolean), 0-based indexing for FX and band index, and the bandtype numeric code mapping. No contradiction with annotations.

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

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

The description is compact and well-structured with a purpose line, Args section, and Returns section. It is front-loaded with the core behavior and avoids unnecessary prose, though the Args section is incomplete by omitting track_index.

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 provides the return contract and most parameter semantics, and the readOnly annotation covers side-effect concerns. However, it fails to explain the required track_index parameter or clarify that this is a track-FX operation versus a take-FX operation, leaving a meaningful gap for 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?

The description documents fx_index, bandtype, and bandidx with helpful semantics, including the bandtype enum mapping and 0-based indexing. However, it completely omits track_index from the Args block even though track_index is a required schema parameter and its meaning is not otherwise obvious.

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 action ('Check whether a ReaEQ band is enabled') with a clear resource target. It distinguishes itself from the sibling set_eq_band_enabled by framing itself as a read/query operation, and from get_eq_bands by targeting a single band's enabled state.

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 read/query intent is implied by 'Check whether,' and the sibling set_eq_band_enabled makes the contrast obvious, but there is no explicit guidance about when to use this tool instead of related ones, nor any mention of prerequisites like locating the ReaEQ FX first.

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?

The readOnlyHint annotation already establishes that this is a safe read operation. The description adds useful return-shape context, such as band metadata and computed gain_db values, but does not disclose behavior for invalid fx_index or non-ReaEQ FX. No contradiction with the annotations exists.

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 concise and front-loaded, with a clear one-sentence purpose followed by Args and Returns sections. Every sentence adds information and there is no filler.

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 return value is documented in detail even without an output schema, and fx_index is explained. However, track_index is missing from the description, and there is no guidance about when to prefer this over get_eq_band_enabled or set_eq_band, leaving the description only minimally complete.

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 documents fx_index clearly as a 0-based FX index, but track_index is required by the schema and is completely unexplained, leaving an essential parameter underspecified.

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: 'Get all ReaEQ band settings in one structured call.' The word 'all' and the structured-return framing distinguish it from siblings like get_eq_band_enabled and set_eq_band.

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 that this tool is for retrieving the complete set of ReaEQ band settings at once, but it never explicitly says when to choose it over alternatives or when not to use it. No sibling tools are named as alternatives.

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?

Goes beyond the minimal destructiveHint=false annotation by explicitly disclosing the side effect that the envelope is created when missing and by naming the return fields. No hidden mutation is implied beyond creation.

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?

Compact, front-loaded purpose with a clear Args/Returns structure. The example and side-effect statement each earn their place; no filler.

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?

No output schema and only destructiveHint=false, so the description carries the burden. It covers side effects and return shape, but leaves two of three required parameters undocumented and does not clarify 0-based indexing for track_index and fx_index.

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?

Only param_index is documented (with 0-based indexing and how to discover valid values via track_fx_get_num_params). track_index and fx_index remain undocumented at 0% schema coverage; their meanings are inferable from names but the description does not state that they are also indices or what indexing convention they follow.

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?

States a specific action (get or create) on a specific resource (automation envelope for an FX parameter), with an illustrative example. This clearly differentiates it from track-envelope utilities like get_track_envelope and point-level tools like get_fx_envelope_points.

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?

Explains the intended use: automating any FX parameter, and clarifies side-effect behavior (created if absent). It does not explicitly name alternatives or exclusionary conditions, but the FX-scoped context is sufficient to guide selection among envelope-related 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?

The readOnlyHint annotation already covers the safe-read behavior, and the description adds the return shape (time, value, shape, tension, selected). However, it does not disclose behavior around empty envelopes, index conventions, or whether the envelope must exist. No contradiction with annotations.

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

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

The description is two short sentences with the core action front-loaded and a concise return summary. Every sentence earns its place, and there is no filler or repetition of schema 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 read-only getter, the description plus readOnlyHint covers the basic call and lists the return fields. However, with no output schema and no parameter explanations, an agent lacks details on index conventions and point field semantics, so the description is only minimally complete.

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%, and the description does not explain track_index, fx_index, or param_index, their units, or zero-based indexing. It only names the resource, so it fails to compensate for the complete lack of parameter documentation 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 states a specific verb ('Get') and resource ('all automation points from an FX parameter envelope'), which clearly distinguishes it from siblings like get_envelope_points that target track envelopes. The phrase 'FX parameter envelope' makes the tool's scope 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 given about when to use this tool versus alternatives such as get_envelope_points, get_fx_envelope, or add_fx_envelope_point. The description only states what the tool does, leaving the agent to infer selection from the name and sibling context.

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?

The readOnlyHint annotation already signals a safe read operation. The description adds that the return value is an object containing the current preset name, which is useful. However, it does not disclose behavior for invalid indices or whether the preset name can be null.

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 short and front-loaded with the core purpose. The return line is slightly redundant but adds a small amount of structural information without waste.

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?