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

With no annotations provided, the description carries the full behavioral burden. It implies a mutation (adding an effect) but says nothing about permissions, whether the effect is inserted at a particular position in the chain, or whether an existing ReaComp is replaced. Only the return shape is mentioned.

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 two short, front-loaded statements that say what the tool does and what it returns. No filler or redundancy 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?

The description mentions the return object but says nothing about essential behavioral details such as chain position, replacement behavior, or prerequisites. Without annotations, an output schema, or parameter documentation, the definition leaves large gaps for a mutation tool.

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 is one parameter, track_index, and schema description coverage is 0%, so the schema gives no semantic detail. The description also omits any explanation of track_index (e.g., index scope, whether it is absolute), providing essentially no added meaning.

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 (add ReaComp) and a specific target (a track), so the verb+resource is clear. However, it doesn't distinguish itself from close siblings such as track_fx_add_by_name or configure_reacomp_sidechain, which an agent would need to disambiguate.

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 indication of when to use this tool rather than track_fx_add_by_name or the related compressor setup tools. The description gives no conditions, prerequisites, or alternatives, leaving the agent to infer from the name alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It omits side effects of insertion (whether points must be added in time order, what happens on duplicate times, whether this modifies automation data destructively), and gives only the return shape ('point 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?

Front-loaded imperative sentence followed by a tight Args list and a one-line Returns. Every line carries information; 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?

For a 5-parameter mutation tool with no annotations and no output schema, the description covers most surface area and even states the return value. However the undocumented required track_index and the absence of any side-effect or ordering information leave a meaningful 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 documents envelope_name, time (seconds), value (0.0-1.0), and the full shape enum meaning — genuinely valuable detail the schema lacks — but it entirely omits track_index, which is 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?

States a specific verb+resource ('Add a point to an envelope'), which is unambiguous on its own. It does not distinguish itself from the closely-named sibling add_fx_envelope_point, so an agent must infer the track-vs-FX distinction from the parameter list alone.

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 on when to use this tool versus add_fx_envelope_point, add_midi_note, or the batch/clear alternatives. It gives no preconditions (e.g., envelope must be armed or exist via get_track_envelope).

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

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

With no annotations, the description carries the full burden of behavioral disclosure for a mutation tool. It does add one useful fact not otherwise available: the call returns an object containing fx_index. But it says nothing about permissions, failure modes, whether an existing ReaEQ is replaced, or where in the chain the FX is inserted.

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, front-loaded statements with no wasted words. The explicit 'Returns' line is valuable given there is no output schema, though the phrasing is terse and could be slightly more informative.

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 annotations, no output schema, and an undocumented parameter, the definition is too thin. Disclosing the return object is a partial offset, but the agent still lacks the information needed to know when the call will succeed or what side effects to expect.

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 single parameter track_index is undocumented. The phrase 'to a track' only vaguely implies that track_index identifies the target track, adding essentially no meaning beyond 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?

States a concrete verb and resource ('Add ReaEQ to a track'), naming the specific plugin, which distinguishes it from generic siblings like add_compressor or add_limiter. However, it does not differentiate itself from track_fx_add_by_name or find_eq, which an agent might reasonably consider equivalent options.

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 the generic track_fx_add_by_name, nor any precondition stated (e.g., whether the track must already have an FX chain). Usage is only implied by the name and 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?

With no annotations, the description must carry full behavioral burden. It mentions that the tool returns an object with point_index and confirmation, which is useful, but it omits critical mutation details: whether it adds or replaces existing points, required permissions, undo behavior, or error conditions (e.g., if the FX envelope doesn't exist). These gaps are significant for a mutation tool.

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

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

The description is well-structured with a clear top-line purpose, followed by labeled Args and Returns sections. It is appropriately sized and front-loaded, with no wasted text, though the Args/Returns formatting is slightly formal.

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 a 6-parameter mutation tool with no annotations and no output schema, the description leaves important context unstated. It mentions a return shape but does not cover the three index parameters, permission requirements, side effects, or failure modes, making it incomplete for reliable 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. It explains time (seconds), value (normalized 0.0–1.0), and shape (enum mapping) for three of six parameters. The remaining three required identifiers (track_index, fx_index, param_index) are left undocumented in both schema and description, so it only partially fills the 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 clear verb and resource: 'Add an automation point to an FX parameter envelope.' This distinguishes it from the generic track-envelope sibling 'add_envelope_point' by specifying 'FX parameter envelope.' However, it does not explicitly name the alternative or further differentiate from other FX envelope 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?

The description offers no when-to-use guidance, no prerequisites, and no comparison to alternatives (e.g., 'add_envelope_point' for track envelopes). It only states what the tool does, leaving the agent to infer its 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?

No annotations are provided, so the description carries the full behavioral burden, yet it only discloses the return shape (fx_index). It does not state what happens on failure, whether an existing limiter is replaced, whether the FX is appended at the end of the chain, or any permission/installation requirement for a mutation operation.

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, action stated first, return value second; nothing is wasted. The 'Returns:' block is slightly awkwardly formatted for a description but is still clear 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?

Because no output schema exists, the description usefully supplies the return object (fx_index). However, for a mutation tool with zero annotations and an undocumented required parameter, it omits the operational details an agent needs to invoke it reliably.

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

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

Schema coverage is 0% for the single required parameter track_index, and the description never mentions it, so no meaning is added (e.g., whether indices are 0-based or how to obtain a valid index). The schema itself documents only the type, leaving the parameter effectively unexplained.

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 ReaLimit (brickwall limiter) to a track') and names the concrete plugin being inserted, so the agent knows exactly what effect is created. It does not explicitly differentiate itself from siblings like track_fx_add_by_name or add_compressor, but the named plugin makes intent 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 on when to choose this over the generic track_fx_add_by_name, add_compressor, or add_mastering_chain. There is no mention of prerequisites, ordering relative to other FX, or whether the plugin must be installed. The agent must infer usage entirely.

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

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

No annotations provided, so the description carries full burden. It states a return object with marker index, which is helpful, but doesn't mention any behavioral traits like project state requirements, undo behavior, or side effects. For a mutation tool with no annotation coverage, this is a significant gap.

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

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

Efficient and front-loaded: the purpose is stated first, followed by parameter details and return value. No wasted words, though the formatting mimics docstring style with 'Args:' and 'Returns:' rather than natural prose.

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 no annotations, no output schema, and 0% schema description coverage, the description provides basic parameter semantics and return value. However, it lacks behavioral context (e.g., does it require an open project? What happens on failure?) and usage guidance, making it minimally adequate.

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 provides meaning for 'position' (seconds), 'name' (marker name), and 'color' (0 = default), which is essential since the schema lacks descriptions. However, it doesn't specify units or constraints for color beyond default.

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+resource ('Add a marker') clearly. Distinguished from siblings like delete_marker, get_markers, go_to_marker by the 'add' verb. Missing differentiation from add_region, but that's a minor concern.

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 on when to use this vs. alternatives like add_region or go_to_marker. Implies usage from the verb but provides no context 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?

No annotations, so the description carries full behavioral burden. It correctly discloses the side effect (mutating the master track FX chain) and the exact insertion order, which is genuinely useful context. But it doesn't disclose whether the chain is idempotent, whether it appends or replaces, or whether an existing chain is preserved.

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?

Front-loaded first sentence stating purpose, followed by a compact numbered list of the exact chain. No filler, no 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?

No annotations and no output schema, but the description compensates well by listing the four plugins and the return type (list of added FX indices). The remaining gap is that it doesn't state whether the operation is idempotent or how it interacts with existing master FX.

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?

Zero parameters, so the baseline is 4. The description correctly notes there is nothing to configure and specifies the fixed plugin sequence, which is the only semantic content available for this no-arg 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 specific verb ('Add') and resource ('standard mastering chain to the master track'), and enumerates exactly which plugins get added and in what order. This is immediately distinguishable from generic siblings like add_compressor or add_limiter.

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?

Implicitly suggests use when you want a complete mastering chain in one call rather than adding plugins individually. However, it never explicitly says when to prefer this over add_compressor/add_limiter/add_eq, nor does it mention exclusions (e.g., will it stack on an existing chain?).

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

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

With no annotations, the description carries the full burden and falls short: it does not say whether the item/track must pre-exist, what happens on invalid indices or pitch out of range, whether the change is undoable, or what the call returns. It only conveys timing units and value ranges, which is parameter information rather than behavioral disclosure.

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

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

Front-loaded purpose sentence, then a compact Args block, then a concrete example. Slightly redundant in restating start/length values inside the example, but every element is useful and the layout is 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?

For a 7-parameter mutation tool with no annotations and no output schema, the description covers the timing model well but omits the role of track_index/item_index/channel and says nothing about failure modes or return behavior. Adequate to make a first correct call, 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 coverage is 0%, so the description must compensate, and it does for the four musically non-obvious parameters: pitch (0-127, 60 = middle C), velocity (1-127), start_beat (0 = first beat), and length_beats (0.25 = sixteenth, etc.). It leaves channel, item_index, and track_index undocumented, but those are relatively self-describing index/default fields.

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 a MIDI note to an item' with the key qualifier 'using musical timing (beats)'. That distinguishes it reasonably from related siblings like add_midi_notes_batch or set_midi_note, though the description never names those alternatives 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 worked 'four-on-the-floor kick' example implicitly shows usage context and expected input shape, which is helpful. But there is no explicit guidance on when to use this single-note tool versus add_midi_notes_batch, nor any stated prerequisites (e.g., a MIDI item must already exist at item_index).

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

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

With no annotations provided, the description carries the full behavioral burden. It does disclose the return value ('Object with count of notes added') and the note dict shape, which is genuinely useful, but it never states whether notes are appended versus replacing existing content, what happens on invalid pitch/channel values, or whether item/track must already exist.

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 definition is compact and front-loaded: the first sentence states the action and timing model, followed by clearly separated Args and Returns blocks. Nothing is padded, though the docstring-style formatting is slightly verbose relative to the amount of information conveyed.

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 no output schema, the explicit Returns note is valuable, and the notes payload is well described. However, for a 3-required-parameter mutation tool with zero annotation coverage, the description leaves the indexing parameters and append-vs-replace semantics unexplained, so an agent could still call it incorrectly.

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

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

Schema description coverage is 0%, so the description must compensate. It does well for the notes array, enumerating keys (pitch, velocity, start_beat, length_beats, channel) and marking channel optional, but track_index and item_index receive no explanation at all despite being required, leaving half the parameter surface undocumented.

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 ('Add multiple MIDI notes to an item') and the 'in one call' phrasing signals the batch nature, which meaningfully separates it from the singular sibling add_midi_note. It does not explicitly name that sibling, so differentiation is inferable rather than stated.

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?

Beyond the implied 'multiple' vs single-note distinction, there is no explicit when-to-use guidance or routing to alternatives like add_midi_note or add_midi_notes_batch's relationship to create_midi_item. The agent must infer that this is the bulk-insert path when many notes are needed.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the side effects: a new bus track is created, a send is added from the source, and compression is applied — the agent knows three new entities result. Doesn't mention undo behavior or whether existing sends are affected, but the mutation profile 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?

Front-loaded with the purpose, then tightly documents behavior, args, and returns in a standard structured format. The Returns section is slightly redundant with the Args-level description but adds the concrete output field names, so it 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 2-parameter tool with no annotations, no output schema, and 0% schema coverage, the description supplies the missing pieces: parameter meaning, mutation side effects, and return shape. The remaining gap is the absence of guidance against sibling low-level alternatives.

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% and parameters have no inline descriptions, so the description must compensate. It does: track_index is defined as a 0-based source index, blend_db is clarified as the send level in dB with a -6 default. Units and indexing convention are added beyond the bare schema 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?

States a specific verb (Set up) and a named mixing technique (New York style parallel compression) for a specific resource (track). Distinguishes itself from sibling primitives like create_send, create_bus, or add_compressor by bundling them into one high-level 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?

Implies 'use this when you want parallel compression,' but gives no explicit when/when-not guidance versus the low-level siblings it composes (create_send, create_bus, add_compressor). An agent can't tell whether to call this or build the chain manually.

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

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

No annotations provided, so the description carries full burden. It does not mention mutation, permissions, whether the operation is reversible, or side effects. It only states the return object with region index, which is minimal. For a mutation tool with no annotations, this is a significant gap.

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

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

The description is brief and front-loaded with the purpose. The Args and Returns sections are structured and easy to parse. It could be slightly more concise by integrating parameters into a sentence, but overall it's 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 4-parameter mutation tool with no annotations and no output schema, the description is adequate but incomplete. It does not cover behavioral aspects like side effects, error conditions, or return structure beyond 'region index'. The parameter semantics are documented, which helps, but broader context 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 must compensate. It does document all four parameters: start and end in seconds, name, and color with default explanation. This adds necessary semantic meaning beyond the schema's bare types. However, it lacks constraints (e.g., valid ranges for start/end, color encoding).

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 'Add a region', a specific verb+resource. Siblings like add_marker, get_regions, delete_region exist, but the description doesn't explicitly differentiate or reference them. A 4 is appropriate: clear but no sibling differentiation.

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 when-to-use or when-not-to-use guidance. It does not mention alternatives like add_marker or conditions under which this tool should be used. The description provides only the basic purpose, leaving usage context implicit.

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

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

No annotations are provided, so the description carries the full burden. It conveys the toggle semantics but says nothing about whether arming is required before record, whether it persists, whether it affects existing input monitoring, or whether disarming mid-record fails — meaningful gaps for a state-changing DAW operation.

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, front-loaded with the tool's action. The Args block is somewhat redundant-formatted but adds the only real semantic value present, so it 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 two-parameter toggle with no annotations and no output schema, the definition is minimally adequate. It omits track_index meaning and any return/state information, so an agent knows the gist but not the full call contract.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify the boolean 'arm' (True = arm, False = disarm), which is genuinely useful, but leaves the required 'track_index' completely unexplained — the more important parameter for correct invocation.

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+resource pair ('Arm or disarm a track') and scopes it to recording, which distinguishes it from the mute/solo siblings. It does not explicitly contrast with arm_track_envelope, but the object 'track' (not envelope) is a reasonable implicit differentiator.

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 on when to arm vs. disarm beyond the parameter flag, no prerequisites (e.g. recording enabled, record-arm mode), and no mention of related siblings like record or set_track_input. The agent must infer the workflow context entirely.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the state change but not whether the track must be armed first, whether arming affects existing automation data, whether the change is reversible, or what confirmation is returned.

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 output is short and front-loaded with the action, and the Args block is compact. The redundant restatement of envelope_name is the only 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?

For a 3-parameter mutation with no annotations and no output schema, the definition covers the core action and the arm flag's polarity but leaves the required track_index undocumented and omits any prerequisites or side effects.

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 is the only documentation. It usefully clarifies that arm=True arms and arm=False disarms (valuable given the default of true), but 'envelope_name: Envelope name' is a pure tautology and track_index is never mentioned despite being required.

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 pair ('Arm or disarm') and resource ('envelope for recording'), so the operation is unambiguous. It does not explicitly distinguish itself from the sibling arm_track, though the 'envelope' qualifier implicitly separates 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?

There is no guidance on when to arm versus disarm, what state the track or envelope must be in, or how this relates to the sibling arm_track tool. The agent must infer usage entirely from the verb.

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 indicate readOnlyHint=false and idempotentHint=true, which are consistent with the description. The description adds behavioral context by explaining what gets reset ('held peak values that accumulate during playback') and confirms idempotence implicitly by describing a reset operation.

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

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

The description is two sentences, front-loaded with the action, followed by usage context. Every sentence earns its place with no 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 simple, parameterless mutation with clear annotations and no output schema, the description covers purpose, scope, and usage. Nothing critical is missing for an agent to call it 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 tool has zero parameters, so parameter semantics are not applicable. Per the rubric, 0 params yields a baseline score of 4; the description does not need to compensate for any schema details.

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: 'Clear the peak hold indicators on all tracks (including master).' It clearly distinguishes from sibling tools like get_track_peak_hold (which reads) by specifying the clearing action and scope covering all tracks.

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 explicit when-to-use guidance: 'Use before a fresh playback pass when you want clean readings for gain staging.' It does not mention when-not-to-use or alternatives, but no direct alternative exists among 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?

No annotations are provided, so the description carries full behavioral burden. It does convey that the operation is destructive ('delete all points'), but says nothing about irreversibility, whether the envelope itself is removed or just emptied, or permission/state requirements. For a mutation tool with zero annotation coverage, this is a significant gap.

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

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

Very short and front-loaded. The purpose sentence is efficient. The args list restates only one of two params, which is minimally useful structure rather than 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?

A destructive mutation tool with no annotations, no output schema, and 0% schema description coverage requires the description to explain scope, alternatives, and parameters. It omits the required track_index and gives no safety or reversibility context, leaving the agent under-informed.

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 documents only envelope_name, completely omitting the required track_index parameter. With two required parameters and zero schema descriptions, the description fails to compensate for the 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?

States a specific verb+resource: 'Delete all points from an envelope.' Clear and unambiguous. Does not explicitly differentiate from siblings like delete_envelope_point or clear_fx_envelope, but the 'all points' vs single-point distinction is reasonably implied.

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 when-to-use guidance and no mention of alternatives such as delete_envelope_point (for individual points) or clear_fx_envelope (for FX envelopes). The agent gets no routing help despite several closely 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?

With no annotations, the description carries the full behavioral burden. It clearly indicates a destructive bulk-clearing operation and documents the return field deleted_count, but it does not explain reversibility, undo behavior, permissions, or any constraints such as whether playback must be stopped.

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

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

The description is two sentences, front-loaded with the action and resource, and closes with the return value. Every sentence adds useful 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?

For a simple, low-complexity operation with no annotations and no output schema, the description covers the action and return value. However, it leaves parameter semantics and behavioral safety details undocumented, so it is only minimally complete for reliable 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 explain the three integer parameters. It implies that track_index, fx_index, and param_index identify an FX parameter envelope, but it does not define any parameter individually, their indexing scheme, or their valid ranges.

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: clearing all automation points from an FX parameter envelope. It is clearly an FX-envelope operation, which separates it from generic envelope tools, but it does not explicitly name the sibling alternative such as clear_envelope or 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 provides no when-to-use guidance, prerequisites, or alternatives. An agent can infer that this is used to wipe an FX parameter envelope, but nothing tells it when to choose this over delete_fx_envelope_point or clear_envelope.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return value (count of notes deleted), which is useful, but for a destructive mutation it says nothing about irreversibility, undo availability, or whether non-note item data is preserved.

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, front-loaded with the action and followed by the return detail. No wasted words, though the return-value clause could be folded in more tightly.

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 no output schema, no annotations, and 0% parameter documentation, the description is too thin. It covers the action and return count but leaves the destructive semantics and parameter identification entirely to inference.

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 both parameters are required integers. The description mentions only 'an item' and does not explain that track_index plus item_index identify the target, nor indexing conventions or ranges.

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 with scope: 'Delete all MIDI notes from an item.' The word 'all' implicitly distinguishes it from the sibling delete_midi_note (single note), but no sibling is named explicitly, so this sits just below the top 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?

No when-to-use guidance, no prerequisites, and no alternatives referenced. The agent must infer from the name alone that this bulk-clears notes versus delete_midi_note's single-note removal.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it discloses nothing beyond the action itself. It does not say whether the clear is undoable, whether it affects any pending edit or rendering state, or what happens if no selection 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?

A single short sentence with no filler, and the action is front-loaded. It is efficient, though its brevity borders on under-specification rather than tight 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?

As a zero-parameter, no-output, low-complexity tool, the description is minimally sufficient to invoke it. It nonetheless leaves gaps about side effects and its relationship to the other time-selection tools, which would be cheap to add.

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 takes zero parameters, so the baseline of 4 applies. There is no parameter information the description could add or omit.

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') and resource ('the time selection'), so an agent knows the basic action. However, it is essentially a restatement of the tool name in sentence form and offers no differentiation from siblings like set_time_selection or get_time_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?

There is no guidance on when to clear the selection versus calling set_time_selection to change it or get_time_selection to inspect it. No preconditions, no context for when clearing is useful (e.g., before an edit operation) 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?

No annotations are provided, so the description carries the full behavioral burden, yet it only states the mechanical effect and a return type. It omits whether a sidechain send must exist first, whether the change is reversible, and any state the toggle affects.

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?

Front-loaded with the core action and organized into Args/Returns sections; every line earns its place. The docstring framing is slightly heavier than necessary but not wasteful.

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 no output schema, the description appropriately states the return value, and it covers all parameters. But for a state-mutating tool with zero annotation coverage, it lacks prerequisite and usage context needed to call 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?

Schema description coverage is 0%, so the description has to compensate, and it does: it documents all three parameters, noting 0-based indexing for track_index/fx_index and that use_sidechain=True maps to auxiliary input channels 3-4 while False uses the main input. This adds real meaning beyond 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?

States a specific verb (configure) and resource (ReaComp sidechain input for detection), so the action is unambiguous. However, it does not distinguish this tool from closely related siblings such as setup_sidechain_compression or setup_sidechain_send, leaving the agent to infer the boundary.

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 when-to-use guidance and no exclusions or alternatives offered. The description never explains how this differs from setup_sidechain_compression or setup_sidechain_send, so an agent cannot tell which sidechain tool to pick.

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

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

With no annotations, the description carries the full burden. It says items go to the clipboard but not whether the source selection is preserved, whether the operation is undoable, whether it works across item types (MIDI/audio), or what happens when nothing is selected — all relevant for a clipboard mutation.

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 four-word sentence with zero padding, and the verb is front-loaded. It is appropriately sized, though it is terse enough that it sacrifices useful detail.

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 tool with no annotations and no output schema, the description is minimally viable: it conveys the basic action but omits behavioral context (undo behavior, selection state, item-type scope) that would help an agent use it correctly alongside cut_selected_items and paste_items.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description adds no parameter-level content because none is needed.

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 ('Copy') and resource ('selected items') plus the destination ('clipboard'), which clearly differentiates it from get_selected_items and select_all_items. It does not explicitly contrast with cut_selected_items, which performs a similar copy but also removes the source, leaving sibling differentiation implicit.

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 versus cut_selected_items, paste_items, or duplicate_item, nor any prerequisite (e.g., a prior selection). The agent must infer usage entirely from the verb.

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

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

No annotations are provided, so the description carries the full burden. It discloses that a bus is created, source tracks are routed, and returns bus_track_index plus routing info, but omits side effects like permissions, error behavior, or whether existing routing is altered.

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

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

Two sentences plus brief Args and Returns sections, front-loaded with the core purpose. 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?

With no annotations and no output schema, the description covers purpose, both parameters, and return shape. It lacks usage context and behavioral details such as prerequisites or failure modes, but is largely sufficient for a basic creation tool.

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 describes both parameters: name as the bus track name and source_track_indices as tracks to route to this bus, adding meaning beyond bare schema types though it does not specify index origin or format.

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 'submix/stem bus', plus the routing action of specified tracks. It does not explicitly differentiate from siblings like insert_track or create_send, but the action is clear.

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 on when to use this tool versus alternatives such as insert_track or create_send. It only describes the action, 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the item is empty and that a return object includes item_index, but it omits side effects, track-existence requirements, selection behavior, and error conditions for a mutation tool.

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

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

The description is front-loaded with the core action, then lists arguments and return value efficiently. Every sentence is relevant and there is no wasted text.

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 creation tool with three required parameters, no annotations, no output schema, and 0% schema descriptions, the description is too thin. It covers the return value broadly but omits track_index semantics, side effects, and prerequisite conditions.

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 adds useful units for two parameters (position and length in seconds), but it does not describe track_index at all, leaving one of three required parameters semantically undocumented.

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: 'Create an empty MIDI item on a track.' This clearly distinguishes the tool from siblings like get_midi_item, clear_midi_item, and add_midi_note. It does not explicitly name a sibling alternative, so it falls short of the highest clarity tier.

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 about when to use it versus alternatives such as add_midi_note or insert_audio_file. There are no prerequisites, exclusions, or context cues to help an agent choose this operation.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that the project cannot be named and that the removed `name` parameter never took effect, but it omits whether creating a project discards unsaved changes, what happens to the current project, and what the tool returns.

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

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

Two sentences: the first states the action, the second gives a relevant caveat. It is front-loaded, efficient, and has no wasted text.

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 project-creation mutation with no annotations and no output schema, the description covers the naming limitation but leaves out key side-effect context, such as impact on the currently open project and whether unsaved changes are affected.

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 parameters, so the baseline is 4. The description additionally explains why there is no `name` parameter, which prevents an agent from expecting one.

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: 'Create a new REAPER project.' This clearly distinguishes it from open_project, save_project, and other project-management siblings in the tool list.

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?

Usage is implied by the name and the word 'new,' but there is no explicit guidance on when to use this versus open_project or save_project. No exclusions or prerequisites are 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?

With no annotations, the description carries the full burden but only discloses the return shape. It does not say whether the call fails when a send already exists, whether indices must be valid track positions, or what side effects occur on the routing matrix.

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?

Short and front-loaded: the action is stated first, then parameters and return value in labeled sections. The Args/Returns framing is slightly boilerplate but wastes nothing.

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

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

For a two-parameter state-mutating tool with no annotations and no output schema, the description covers the action, parameters, and return value, but omits error conditions and interaction with the existing routing/send list. Adequate but with clear gaps.

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

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

Schema coverage is 0%, so the description must supply meaning, and it does: it clarifies that src_track is the source and dest_track the destination and that both are 0-based indices. That is meaningful beyond the bare integer properties, though it omits bounds/validity behavior.

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 ('Create a send from one track to another'), which is clear and separable from most siblings like delete_send and set_send_volume. It does not, however, contrast itself with related tools such as setup_sidechain_send, which also creates sends implicitly.

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 on when to use this tool versus alternatives, no prerequisites, and no mention of how it relates to setup_sidechain_send or get_track_num_sends. The agent must infer that this is the primitive send-creation call.

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 readOnlyHint=false, but the description earns extra credit by specifying exactly what is destroyed ('discarding all other takes'). It still omits prerequisites such as which take must be active and whether the action is reversible.

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

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

A single front-loaded sentence with no filler; the destructive scope is stated immediately after the action.

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 two-parameter tool with no output schema, the description communicates the effect but leaves both parameter meanings and any preconditions undocumented. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description carries the burden, yet it only refers vaguely to 'a media item' and never explains track_index vs item_index. An agent cannot infer from the description what these two required integers mean.

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 (Crop) and resource (a media item to its active take), which is meaningfully distinct from siblings like explode_takes, delete_take, and set_active_take. It does not name an alternative to route against, but the operation itself 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 explicit when-to-use guidance and no comparison to related tools such as delete_take or explode_takes, which manipulate takes differently. The intended use is only weakly implied by the description's outcome.

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

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

No annotations are provided, so the description carries the full burden. It does not state that the source items are removed from the timeline, whether the operation is undoable, whether it depends on a time selection, or whether the clipboard survives project changes. 'Cut' implies removal but this is convention, not disclosure.

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 front-loaded sentence with zero filler; the verb and the affected resource come first. Nothing in it is redundant or restating the tool name mechanically.

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 clipboard verb with no output schema and no annotations, a short description is largely sufficient. Still missing are the implicit-selection dependency and the removal side effect, which are the details an agent needs to chain this correctly with paste_items.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. It correctly signals that the target set is implicit (whatever is currently selected) rather than passed in.

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 (cut) and resource (selected items) with the destination (clipboard), so the action is unambiguous. It does not explicitly distinguish itself from near-neighbours like copy_selected_items or delete_selected_items, though 'cut' conventionally implies both copy and removal.

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 when-to-use guidance, no stated alternative to copy_selected_items or delete_selected_items, and no prerequisite such as requiring a prior selection or routing to paste_items as the follow-up. The agent must infer all routing from the name.

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

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

No annotations are provided, so the description carries the full burden. It says 'delete' but does not disclose reversibility, undo availability, what happens to point indices after deletion, or required track state (armed/shown envelope). For a destructive mutation this is a significant gap.

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

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

Very short and front-loaded with the action, which is good, but the 'Args:' block restates only one parameter and the whole body is under-specified rather than efficient. Brevity here reflects a missing spec, not tight prose.

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?

Destructive tool with no annotations, no output schema, no undo information, and 0% parameter coverage. An agent cannot safely determine preconditions, index validity, or side effects from this definition.

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 documents one of three parameters (envelope_name), leaving track_index and point_index entirely unexplained. It must compensate for the coverage gap and does not.

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+resource ('Delete an envelope point') but is nearly a tautology and offers no differentiation from sibling delete_fx_envelope_point, delete_midi_note, or delete_marker. An agent must already know envelope-specific semantics to use it.

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 when-to-use context, no mention of alternatives like clear_envelope or delete_fx_envelope_point, and no prerequisites. The agent gets only the obvious fact that it deletes a point.

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

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

No annotations, so the description carries the full burden. It says 'Delete' (implying mutation) but doesn't state reversibility (undo?), error behavior on invalid index, or effect on envelope point count. Minimal behavioral context.

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

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

Two sentences, front-loaded with purpose, followed by a concise param note. No waste, though the Args block format is minimal.

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 4-parameter mutation tool with no annotations and no output schema, the description is insufficient. It should clarify index semantics for all params, behavior on invalid input, and relationship to sibling tools.

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% and 4 required parameters exist. The description only documents 'point_index' with a brief note (0-based). The other three (track_index, fx_index, param_index) are undocumented in both schema and description.

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

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

States a specific verb ("Delete") and resource ("automation point from an FX parameter envelope"). Distinguishable from sibling 'delete_envelope_point' (track envelope) and 'clear_fx_envelope' (bulk removal), though it doesn't explicitly name these.

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 on when to use this vs alternatives like 'clear_fx_envelope' or 'delete_envelope_point'. No prerequisites stated (e.g., envelope must exist, indices must be valid).

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

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

With no annotations, the description carries the full behavioral burden. 'Delete' implies a mutation, but nothing is said about irreversibility, undo availability, error behavior when indices are out of range, or whether the item is removed from disk or just the project. For a destructive operation with zero annotation coverage this is a real gap.

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

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

A single short sentence is front-loaded and wastes no words, but it is under-specified rather than genuinely concise. There is no structure beyond the bare statement of action.

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?

A destructive, two-parameter tool with no annotations, no output schema, and no parameter documentation leaves the agent without enough to call it safely. At minimum, index semantics and undo/reversibility should be stated.

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% for both required parameters. The description's phrase 'media item' faintly hints that item_index addresses an item, but it never explains track_index vs item_index, indexing base, or whether item_index is scoped to the track. It does not compensate for the coverage 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 ('Delete a media item'), so the agent knows it removes an item. However, it gives no differentiation from close siblings like delete_selected_items, delete_take, or delete_midi_note, which also remove content. Clear but undifferentiated, matching the 4 criteria.

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 on when to use this versus delete_selected_items or delete_take, and no prerequisites such as selection state or whether the item must be unselected first. The agent must infer usage entirely.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates deletion but does not mention irreversibility, required permissions, side effects on other markers or the timeline, or behavior on invalid index. This is a significant gap for a mutation tool.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently states the action, resource, and identifier. It could be slightly more complete without becoming verbose, but its concision is appropriate for the core 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?

With no annotations, no output schema, and 0% parameter description coverage, the description is too sparse. It omits return behavior, error conditions, index semantics, and confirmation of destructive action. An agent lacks enough context to invoke it safely and correctly in all cases.

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 says 'by index' but does not clarify whether the index is zero-based, one-based, or an identifier, nor what range is valid. It adds only minimal meaning beyond the parameter name marker_index.

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 (marker) and adds the identifying mechanism (by index). It clearly distinguishes from sibling operations like add_marker and get_markers, but it does not explicitly contrast with delete_region or other delete_* tools. A 4 is appropriate for a clear, actionable purpose without sibling routing.

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 offers no when-to-use guidance, prerequisites, or alternatives. It does not say whether to use this versus delete_region, or what happens if the marker is referenced elsewhere. Usage is only implied by the tool name and description, which is insufficient for a 3.

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

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

No annotations are provided, so the description carries the full burden. It says 'delete' but discloses nothing about whether the deletion is undoable, whether the indices are 0- or 1-based, or whether remaining note indices shift after removal — critical for a destructive mutation whose parameters are index-based.

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 short sentence with no waste, but it is under-specified rather than genuinely concise — the brevity comes at the cost of missing guidance and parameter context.

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?

A destructive mutation tool with no annotations, no output schema, and three completely undocumented parameters needs substantially more description than one sentence. An agent cannot confirm whether it needs to call get_midi_notes first or what the index base is.

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% across three required parameters. The description adds no meaning: it never explains what track_index/item_index/note_index refer to, whether they are zero-based, or whether note_index must reference an already fetched note. With a low-coverage schema, the description has to compensate and does not.

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?

Clear specific verb+resource: deleting a MIDI note from an item. It is distinguishable from sibling delete tools (delete_take, delete_item, delete_envelope_point) by naming the MIDI-note resource, though it does not differentiate itself from set_midi_note or remove_overlapping_midi_notes beyond the verb.

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 offers no when-to-use context, no prerequisites (e.g., that the note must exist), and no comparison to alternatives such as clear_midi_item or remove_overlapping_midi_notes. It is purely a statement of effect.

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

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

With no annotations, the description carries the full behavioral burden. It states the destructive action 'Delete,' but does not disclose irreversibility, undo behavior, permission requirements, side effects on markers or project state, or error behavior. It provides only minimal transparency for a mutation tool.

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

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

The description is a single front-loaded sentence with no wasted words. It is concise and readable, though its brevity contributes to the gaps in usage and behavior 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 destructive one-parameter tool with no annotations, no output schema, and 0% schema description coverage, the description is too thin. It does not explain the return value, error cases, or how to obtain a valid region index, leaving important context to inference.

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 single parameter is only documented by the phrase 'by index.' This adds that region_index is an ordinal identifier, but it does not explain where the index comes from (e.g., get_regions), whether it is zero-based, or what happens if it is invalid.

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 gives a specific verb and resource: deleting a region by index. This clearly separates it from sibling deletion tools such as delete_marker, delete_take, and delete_track. It does not explicitly name an alternative or clarify its role relative to get_regions/add_region, so it stops 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 like delete_marker or delete_take. The agent must infer that it is for removing a region from the project, with no when-to-use or when-not-to-use 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?

No annotations are provided, so the description carries the full behavioral burden. It doesn't disclose whether deletion removes items from disk, whether it is undoable, what happens to an empty selection, or the scope of affected entities. It adds the key fact that the operation targets selected items (not a parameter).

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?

One short sentence, front-loaded with the verb and resource, 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 no-param mutation with no annotations and no output schema, the description is minimally adequate but leaves the agent without key context: prerequisite selection, reversibility, and differentiation from delete_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?

Zero parameters, so baseline 4 applies. The description correctly notes the input comes from the current selection rather than a 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?

Clear verb+resource: deletes items that are currently selected. The dependence on prior selection distinguishes it from delete_item (which presumably targets a specified item), though it doesn't explicitly name that alternative.

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

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

No guidance on when to use this versus delete_item, clear_midi_item, or other deletion siblings. The only implied context is that a selection must exist, which is not 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?

With no annotations, the description carries the full behavioral burden, but it only implies a destructive mutation via the verb 'Delete'. It does not disclose whether the deletion is irreversible, what happens to remaining sends, or whether permissions or valid indices are required.

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 front-loaded with the purpose in a single clear sentence, followed by a compact Args block for the two parameters. Every element earns its place with no redundancy.

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

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

For a simple two-parameter mutation with no annotations or output schema, the description covers the purpose and both parameters adequately. However, it omits behavioral context such as irreversibility and index validity, which would be important for an agent invoking a deletion operation, so it is minimally sufficient rather than 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 must compensate, and it does: track_index is explained as 'Source track index (0-based)' and send_index as 'Send index (0-based) to delete.' This adds meaning beyond the bare integer types in the schema, though it doesn't state valid ranges or how to obtain a valid send index.

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 (send from a track), clearly distinguishing it from the sibling create_send and other send-management tools. An agent can tell exactly what this tool does without opening the schema.

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

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

No guidance is given on when to use this tool versus alternatives, nor are any prerequisites or exclusions stated. The description only restates the operation, leaving context about valid track/send state to inference.

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, but the description adds a genuinely non-obvious side effect: the take is activated before being removed, so deleting has a state-changing consequence beyond removal. It still omits error behaviour for an out-of-range index and whether remaining takes are renumbered.

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?

Front-loaded purpose sentence followed by a short Args block; nothing is padded. The Args block covering only one of three parameters is a structural weakness, but the text itself is tight.

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 or return-value detail is needed for a delete, and destructiveness is covered by annotations. However, for a three-index operation with 0% schema coverage, the definition is still missing the meaning of track_index/item_index and any post-delete state or failure behaviour.

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% across three required parameters, so the description carries the full burden. It documents only take_index (0-based) and leaves track_index and item_index completely unexplained, compensating for roughly one third of the 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?

States a specific verb and resource ("Delete a specific take from a media item"), which an agent can distinguish from delete_track, delete_item and take_fx_delete. It does not name any sibling explicitly, so it stops 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?

No when-to-use guidance, no prerequisites, and no pointer to how to obtain a valid take_index (get_takes / get_active_take are the obvious siblings). The agent must infer everything about context from the purpose line alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It never states that this is destructive/irreversible, whether the action is undoable, what happens to the track's items, FX, and sends, or whether subsequent track indices shift. For a destructive mutation tool with zero annotation coverage, this is a substantial gap.

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

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

Only two short lines, with the core action front-loaded before the argument note. There is no filler, though the 'Args:' block style is terse rather than maximally informative.

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 single-parameter destructive tool with no annotations and no output schema, the description covers the parameter and one important restriction (master track). It omits return/confirmation behavior and side effects on routed sends, items, or FX, leaving an agent without enough to predict consequences.

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% (the schema only says 'integer'), so the description must compensate, and it does: it specifies the index is 0-based and that the master track (-1) is an invalid target. That adds real meaning beyond the bare schema, though it doesn't note whether indices shift after deletion.

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 a track'), which is unambiguous against siblings like delete_take, delete_send, or delete_item. It does not explicitly contrast itself with those siblings, but the resource name is distinct enough that an agent can select it correctly.

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 explicit when-to-use guidance or named alternative, but the description does impose a meaningful scoping constraint: the target cannot be the master track (-1). That is a partial 'when-not' rule, though it stops short of saying when this tool should be preferred over other track-management operations.

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

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

No annotations are provided, so the description carries the full burden. It discloses only the return shape ('Object with new item info') and says nothing about where the duplicate lands, whether the original is preserved, or any permissions/limits.

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, front-loaded lines with no filler. The description is appropriately brief, though the 'Returns:' block is a slightly awkward way to convey that detail.

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 annotations and two undocumented parameters, the definition is too thin. The only return info is a vague 'Object with new item info,' and there is no output schema to fill the 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% and the description gives no explanation of track_index or item_index. The parameter names are somewhat self-evident, but the description adds no meaning beyond them, failing to compensate for the documentation 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?

States a specific verb ('duplicate') and resource ('a media item'), so the core action is unambiguous. However, it does not distinguish this from siblings like copy_selected_items or split_item, so the agent gets no help telling them apart.

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 on when to use this versus alternatives such as copy_selected_items/paste_items, nor any stated prerequisites. The agent must infer all usage context 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 readOnlyHint=false and destructiveHint=true, so the agent knows this is a mutating, destructive operation. The description adds that takes become overlapping items, which is useful context beyond annotations, but it doesn't explain what 'in place' means precisely, whether existing items are replaced, or what happens to the original media item. The added value is moderate given annotation coverage.

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

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

Single sentence, front-loaded with the action and resource, no wasted words. It efficiently conveys the core 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?

With no annotations covering parameter semantics, no output schema, and 0% schema description coverage, the description should do more. It fails to explain parameters, side effects, or return values, making it incomplete for a destructive mutation tool with two required integer parameters.

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 both parameters (item_index, track_index). Instead, it provides no information about parameter meaning, required values, indexing base, or how to locate the target item and track. 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?

States a specific verb (explode) and resource (all takes of a media item) with the resulting behavior (each take becomes its own overlapping item). This distinguishes it from siblings like get_takes, set_active_take, and crop_to_active_take, which operate on takes but don't explode them. It is clearer than a vague purpose statement but not as precise as naming the exact Reaper action or differentiating further.

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 on when to use this tool versus alternatives such as duplicate_item, split_item, or crop_to_active_take. The description implies a transformation but does not state prerequisites, context, or exclusions. This leaves usage ambiguous for an agent.

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

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

No annotations, so the description must carry the burden. It discloses the return value (-1 if not found) and that instantiate adds the effect, which are useful behavioral details. But it doesn't cover auth or side effects beyond that.

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

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

Front-loaded with the main purpose, then a concise Args/Returns section. No wasted words, though the Args/Returns format could be more integrated.

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-param tool with no annotations and no output schema, the description covers the return value and instantiate behavior, but leaves track_index semantics and any error conditions unexplained. It's minimally adequate but incomplete for robust 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?

Schema description coverage is 0%, so the description must compensate. It explains instantiate (add if absent) but doesn't explain track_index at all beyond the name. Baseline would be 4 if no params, but with 2 params and 0% coverage, this is a 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?

States a clear verb (find) and resource (ReaEQ on a track), plus the optional instantiation behavior. It doesn't explicitly name the sibling it differs from, but the specific mention of ReaEQ distinguishes it from generic FX tools like 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 instantiate arg implies when to use it (if you want ReaEQ added when absent), but there's no explicit when-to-use vs alternatives, and no prerequisites like requiring a valid track_index.

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?

No annotations are provided, so the description carries the full burden. It implies a read but never states whether the master track is included, what fields each track carries, ordering, or volume of results for large projects — meaningful gaps for a tool whose entire value is its returned list.

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

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

A single efficient sentence with no waste. It is a touch thin given no supporting schema or annotations, but nothing is padded or buried.

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 no output schema and no annotations, the description is the only source of information about what comes back, and it says nothing about the shape or contents of the track data. An agent cannot predict the response from this definition.

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?

Zero parameters, so there is nothing to document and the baseline is 4. The description correctly implies no filtering or pagination options are needed.

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 ('Get information about') and resource ('all tracks in the project'). The word 'all' distinguishes it from the singular get_track and from get_track_count, though it never names those siblings 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?

No when-to-use guidance and no alternatives named. The agent must infer that this is for bulk listing versus get_track for a single track or get_track_count for a count.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the return shape and that the value is in seconds, and 'Get' implies a read-only operation, but it does not explicitly state side-effect safety or error behavior if no cursor 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?

Two short, front-loaded sentences with no wasted words. The purpose comes first, followed immediately by the return value.

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 zero-parameter getter with no output schema, the description is nearly complete: it covers what the tool does and what it returns, including units. Minor edge cases, such as behavior when no cursor is available, are omitted but not essential.

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 takes zero parameters, so there are no parameter semantics to explain. Per the baseline for parameterless tools, this is adequately handled by the empty 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 ('Get the edit cursor position'), and the 'edit' qualifier subtly separates it from playback cursor tools like get_play_position. However, it does not explicitly distinguish itself from siblings such as set_cursor_position or get_play_position.

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 purpose implies the tool is called when you need the current edit cursor location, but there is no explicit when-to-use guidance. No alternatives (e.g., set_cursor_position to change cursor, get_play_position for playback cursor) 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?

No annotations are provided, so the description carries the full burden. It discloses only that a point count is returned; it says nothing about error behavior for a missing envelope, required permissions, or whether it works on track vs FX envelopes. The 'Returns' line is the sole behavioral disclosure.

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

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

Short, front-loaded, and the docstring-style Args/Returns layout is easy to scan. Nothing is wasted, though the terseness contributes to the gaps in the other dimensions.

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 no output schema, the description does cover the return value (an object with a point count), which is genuinely useful. However, the undocumented track_index parameter and absent usage/precondition guidance leave it only minimally complete for a two-parameter tool.

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 documents only one of the two parameters (envelope_name). track_index is completely undescribed in both schema and description, leaving half the input surface undocumented.

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: 'Get the number of points in an envelope.' An agent can distinguish it from sibling get_envelope_points (which returns the points themselves) by the count semantics, though the description never explicitly names that alternative.

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 when-to-use guidance, no mention of prerequisites (e.g. whether the envelope must exist or be armed), and no routing to alternatives such as get_envelope_points or get_track_envelope. The reader must infer usage entirely from the name.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the return payload structure (time, value, shape), which is genuinely useful since there is no output schema, and 'Get' signals a read-only operation. It says nothing about ordering, empty-envelope behavior, permissions, or errors, which is a meaningful gap for a tool with zero annotation coverage.

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

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

Front-loaded with the purpose and short overall, but the 'Args: envelope_name: Envelope name' block is pure boilerplate that restates the schema with zero added information and could be dropped without loss.

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 read tool with no annotations and no output schema, the description does cover the return shape, which is the most important omission to fill. The unaddressed track_index parameter and lack of any sibling differentiation leave it only adequate.

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 there are two required parameters. The description only restates envelope_name ('Envelope name') without adding any format or semantics, and track_index — the parameter that actually identifies which track's envelope to read — is documented nowhere at all.

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?

Specific verb+resource: 'Get all points from an envelope', which tells the agent this returns the full point set rather than a count or a single point. However, it never distinguishes itself from the near-identical sibling get_fx_envelope_points (FX envelope) or get_envelope_point_count, so the agent must infer the track-vs-FX distinction from the schema.

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

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

There is no statement of when to use this tool versus get_envelope_point_count, get_track_envelope, or get_fx_envelope_points. Usage is only implied by the verb 'Get'. No prerequisites (e.g., that the envelope must exist) 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?

No annotations are provided, so the description carries the burden. It does disclose the return shape ('Object with ret boolean, true=enabled') and implicitly indicates a non-mutating read via 'Check', but says nothing about permissions, error behavior when the FX index is invalid, or whether the track must be selected.

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?

Purpose is front-loaded in one sentence, followed by a clean Args/Returns structure with no redundant prose. Slightly verbose in header labels but every line carries 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?

There is no output schema, so documenting the return object is the right call, and the bandtype enum is a valuable addition. The one gap is the undocumented track_index parameter, which an agent must infer.

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

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

Schema coverage is 0%, so the description must compensate, and it does well for three of four params: it explains fx_index (0-based), bandidx (0=first), and critically supplies the full bandtype enum mapping (0=hipass ... 5=lopass) which the schema lacks entirely. It omits any description of track_index, keeping it short of a 5.

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+resource: checking the enabled state of a ReaEQ band. This is clearly distinguishable from siblings like get_eq_bands (all bands) and set_eq_band_enabled (mutation), so an agent can select it without opening either schema.

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

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

The description explains the arguments but gives no guidance on when to prefer this over get_eq_bands or how it relates to set_eq_band_enabled. Usage context is left entirely to inference from the tool name.

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

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

With no annotations, the description carries the full burden. It discloses the return structure in detail (bands list with fields and gain_db), which is valuable, and the verb 'get' implies a read-only operation. It does not state permissions or error behavior, but for a getter that is acceptable.

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 front-loaded with purpose, then uses clear Args and Returns sections. The return field list is lengthy but justified because there is no output 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?

The tool has no annotations, no output schema, and 0% schema description coverage, so the description must be self-sufficient. It partially compensates by describing return values, but it fails to document the required track_index parameter, leaving a critical gap for an agent trying to call 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 coverage is 0%, so the description must compensate. It explains fx_index (0-based) but completely omits track_index, which is a required parameter, leaving half the parameters undocumented.

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: 'Get all ReaEQ band settings.' It scopes the result ('all') and the format ('structured call'), making it distinct from set_eq_band and get_eq_band_enabled, though it does not name those siblings 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?

There is no explicit guidance on when to use this tool versus alternatives like get_eq_band_enabled or set_eq_band. Usage is only implied by the 'get all band settings' purpose.

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

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

With no annotations, the description must carry the behavioral burden, and it does disclose a key trait: this is a get-or-create operation with a side effect (the envelope is created if it doesn't exist), plus the return shape. It omits error/permission behavior when indices are invalid, so the disclosure is helpful but incomplete.

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?

Purpose is front-loaded, and the Args/Returns structure is easy to scan. Minor redundancy: 'The envelope is created if it doesn't exist' restates the 'or create' in the opening line, but overall the text is tight.

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 annotations, no output schema, and 0% schema coverage, the description does compensate by spelling out the return object fields (envelope_name, param_name, point_count, indices). It still leaves the other two parameters and failure modes unexplained, so it is adequate 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 coverage is 0%, so the description must compensate, but it only explains param_index (0-based, with a helper tool for valid values). track_index and fx_index receive no explanation at all, leaving two of three required parameters entirely undocumented.

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+resource: 'Get or create an automation envelope for an FX parameter', with a concrete example (a flanger knob in Guitar Rig) that grounds the concept. It's clear the tool returns/creates the envelope object itself. It doesn't explicitly distinguish itself from the related envelope siblings (get_fx_envelope_points, add_fx_envelope_point, clear_fx_envelope), so it falls just 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?

Provides useful operational guidance: use track_fx_get_num_params() to find valid parameter indices, and notes the envelope is auto-created if absent. However, it never explains when to reach for this tool versus get_fx_envelope_points, add_fx_envelope_point, or clear_fx_envelope, leaving the workflow position implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return structure (list of points with time, value, shape, tension, selected), which is helpful since no output schema exists. However, it does not explicitly state that this is a read-only operation, nor does it describe any side effects, permissions, or error conditions. Behavioral transparency is partial.

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

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

Two sentences, front-loaded with purpose and then return details. No wasted words. The structure is 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?

Given three required parameters with no schema descriptions and no annotations, the description is insufficient to correctly invoke the tool. While it covers the output shape, it omits any explanation of the input indices, leaving an agent unable to determine what track_index, fx_index, and param_index should be.

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?

Three required integer parameters (track_index, fx_index, param_index) with 0% schema description coverage. The description does not explain what these indices represent, their valid ranges, or indexing base. It adds no meaning beyond the parameter names themselves.

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 'Get' and resource 'automation points from an FX parameter envelope'. Differentiates from siblings like get_fx_envelope (returns the envelope object) and add/delete/clear point tools. However, it does not explicitly distinguish itself from similar point-listing tools such as get_envelope_points or get_envelope_point_count.

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 on when to use this tool versus alternatives like get_fx_envelope, get_envelope_points, or get_envelope_point_count. No prerequisites, conditions, or exclusions 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?

No annotations are provided, so the description carries the full disclosure burden. The verb 'Get' plus the stated return shape establishes this as a safe read that returns an object with the preset name, which is useful, but nothing is said about error behavior when the track/fx index is invalid or out of range.

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

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

Two short sentences, front-loaded with the action. The 'Returns:' line is slightly redundant with the first sentence but still compact and earns most of its space by disclosing the return shape.

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 no output schema the Returns line usefully names the return value, but the definition leaves the FX scope (track vs take vs master) and index semantics unstated, and offers no annotations to cover safety or mutation behavior.

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 neither parameter is mentioned in the description. track_index and fx_index are bare integers with no stated base, range, or relationship, so the description does nothing to compensate for the undocumented 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?

States a specific verb and resource ('Get the current preset name of an FX') and is clearly distinguishable from set_fx_preset, save_fx_preset and get_fx_presets by the read-only singular-target framing. It does not say which FX scope (track vs take) the indices refer to, which matters given sibling families take_fx_* and track_fx_*.

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

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

No when-to-use guidance and no alternative named. The agent must infer on its own that get_fx_presets (plural) is the list variant and that set_fx_preset is the mutation counterpart.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it partially meets it by disclosing the return shape ('Object with list of preset names'), which compensates for the absent output schema. However, it never states this is a read-only, non-mutating call, nor how it behaves if track_index/fx_index are invalid.

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?

Extremely short and front-loaded, with the purpose in the first sentence and the return note in the second. Each line earns its place, though the 'Returns:' block formatting is slightly heavy for a single-field result.

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 read tool the description is minimally viable: it explains the output (covering the missing output schema) but leaves parameter semantics and read-only/error behavior entirely to inference, with no annotations to fill the 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 both required integer parameters are undocumented. The phrase 'presets available for an FX' only loosely implies fx_index identifies the FX; track_index is never explained and neither parameter's indexing/zero- vs one-based convention or valid range is given.

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: list presets available for a given FX. It is naturally distinguished from get_fx_preset/set_fx_preset/save_fx_preset by the plural 'list' framing, but the description never names or contrasts those siblings 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?

No indication of when to use this versus get_fx_preset, set_fx_preset, or save_fx_preset, nor any prerequisites (e.g. the FX must already exist on the track). Usage must be inferred entirely from the name.

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