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

With no annotations, the description carries the full burden, and it does disclose the key behavioral fact — the return value is the new FX index, or -1 if not found. However, it says nothing about mutation side effects (undo/reversibility), whether the track must already exist, or what happens when the same FX is added twice.

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

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

Three front-loaded sentences; the purpose leads, then matching semantics, then the return value. The examples earn their place by clarifying a non-obvious matching rule. Slightly under-specified rather than bloated.

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

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

For a low-complexity, two-parameter tool with no output schema, the description covers the essentials: what it does, how the FX name is matched, and what it returns. Gaps are the undocumented track_index convention and the mutation/undo behavior, which keep it short of complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does add real value for fx_name by explaining the REAPER FX-browser matching convention with concrete examples, but track_index is entirely unexplained (0-based? selectable via list_tracks?), 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?

States a clear verb+resource ('Add an FX plugin to a track') that an agent can easily distinguish from the sibling tools remove_fx and list_fx. The fx_name examples ('ReaEQ', 'VST:Pro-Q 3') further pin down what kind of resource is being added. It never names a 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?

Usage is only implied: the tool obviously requires an existing track, but the description never says so, nor does it point to list_fx as the way to discover valid FX names before calling. No when-to-use vs. alternatives guidance is given beyond the name-matching semantics.

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 it does disclose two useful behavioral facts: `name` is optional and the default `position` of -1 appends at the end. It says nothing about out-of-range position handling, error behavior, or whether the track is selected after creation.

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

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

Three terse sentences with zero filler, front-loading the action, then the two parameter semantics, then the return value. Every sentence earns its place.

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

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

For a two-parameter creation tool with no output schema, the description covers both parameters and even documents the return shape {index, name}, which is otherwise unavailable. Only edge-case behavior on an invalid position 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 coverage is 0%, so the description must compensate, and it largely does: it marks `name` as optional and fully explains `position` semantics (0-based insert index, -1 default appends). It omits only the empty-string default for `name` that the schema declares.

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 new track'), which is instantly distinguishable from sibling mutations like delete_track or rename_track. It does not explicitly name an alternative, but the action is unambiguous on its own.

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 add a track versus using apply_template, insert_midi_item, or new_project, nor any stated prerequisites. Usage is only implied by 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?

With no annotations, the description carries the full burden and discloses key behavior: templates are processed in order, tracks are appended without clearing existing tracks, and the return value includes new track indices and names. It does not cover failure modes, permissions, or atomicity, but the core mutation and return behavior is well described.

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 purpose is front-loaded, followed by the necessary nested-parameter details and mutation/return behavior. Every sentence earns its place, and the dense field list is justified by the schema gap.

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

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

Given the complex nested input, no output schema, and no annotations, the description is largely complete: it explains purpose, parameter structure, append behavior, and return values. It could be slightly stronger with explicit alternative-tool guidance or failure behavior, but it is sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate. It does so extensively by describing the nested track object fields, optionality, value formats (color as [r,g,b]), and folder_end semantics. This adds substantial meaning beyond the bare array parameter in the schema.

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

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

The description states a specific verb and resource: 'Build a track layout from a template.' It clearly distinguishes bulk layout creation from sibling operations like add_track by describing the template-based, ordered list input.

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?

It gives important context that the operation 'Appends to the current project; does not clear existing tracks,' which helps an agent choose it over a destructive project reset. However, it does not explicitly say when to use this instead of add_track or new_project, leaving alternatives implied.

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

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

With no annotations, the description carries the full burden. It usefully discloses that the tool reuses the project's configured format and only swaps bounds, output directory, and pattern, which is genuine behavioral context. It says nothing about overwrite behavior, whether files are created vs replaced, permissions, or what the call 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?

Three tightly packed sentences with the core action front-loaded and no filler. The format/wildcard details follow naturally. Slightly dense parenthetical in sentence two, but nothing is wasted.

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 write-side tool with no annotations, no output schema, and zero schema description coverage, the description should cover more ground. It handles the format-routing question well but leaves 'only_matching', overwrite semantics, and failure modes unexplained.

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 so only partially. It explains file_name_pattern well (REAPER wildcards, default '$region' meaning filename equals region name) and implies output_dir, but 'only_matching' is never mentioned anywhere in the schema or 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 and resource with explicit scope: 'Render every region in the project to its own file.' The 'every region' framing implicitly separates it from the single-item render siblings, but no sibling is named, so the differentiation is left to inference 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?

Provides one real prerequisite: the render FORMAT must be configured once in REAPER's Render dialog beforehand. However, it never says when to pick this over render, render_with_current_settings, or batch_rename_regions, so the agent must guess the boundary between batch region export and a normal render.

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 load, and it does disclose the ordering semantics (track-then-position), the -1 cross-track behavior, and the return value ("the list of renames applied"). It omits any warning about overwriting existing names or collision behavior, but for a local DAW rename operation the disclosure is solid.

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?

Four short sentences, all front-loaded with the core action first and token reference second. No filler; a slight tightening of the token list is possible but nothing is 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?

No output schema and no annotations, but the description covers action, ordering, scope switch, token grammar, and return value. An agent has enough to invoke it correctly; only edge-case error behavior is absent.

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%, yet the description documents the pattern token vocabulary ($num, $idx, $name, $track), explains pad_width via the $num padding rule, and defines the sentinel value for track_index. Only start_num is left implicit (its off-by-N interaction with the 1-based $num is never stated).

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+scope: "Rename items on a track in order." An agent can distinguish it from batch_rename_regions by the item/region noun, though the description never names that sibling, so differentiation relies on inference.

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

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

It gives one concrete usage rule (track_index = -1 applies across ALL tracks in track-then-position order), which tells the agent when the broad mode applies. It offers no guidance on when to prefer this tool over batch_rename_regions or what happens on invalid 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 no annotations, the description carries the full burden and does disclose meaningful behavior: it renames everything (no filtering), processes in time order, and defines the naming token grammar. However, it says nothing about the destructive/irreversible nature of overwriting names, permissions, or failure behavior, which matters for a batch 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?

Two sentences, action front-loaded, followed by token documentation. No filler; each sentence 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?

For a mutation tool with no annotations, no output schema, and 0% parameter coverage, the description covers the core transformation and pattern grammar but leaves start_num undocumented and gives no sense of the return value or error 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 coverage is 0%, so the description must compensate. It usefully defines the pattern tokens and ties $num padding to pad_width, but start_num is never mentioned and pad_width's own semantics are only implied. Partial compensation for a three-parameter tool.

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

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

States a specific verb and resource ('Rename ALL regions in the project') plus the ordering behavior ('in time order'), which distinguishes it from the region-listing sibling. It does not explicitly name batch_rename_items, but 'regions in the project' naturally separates it from item-level tools.

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

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

The scope statement 'ALL regions' implies that no filtering is possible, which is an implicit usage constraint, but the description never states when to prefer this over batch_rename_items or what prerequisites (e.g. an open project) apply. Usage is inferred rather than guided.

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

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

No annotations are provided, so the description carries the burden. It discloses that this is a read-only diagnostic that surfaces one value (the directory) and explains why it matters. It stops short of stating the return format or whether it errors when the bridge is uninitialized.

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, zero waste. The action is front-loaded and the diagnostic context immediately follows, with no restating of the name.

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

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

For a zero-param diagnostic with no output schema, the description supplies enough to invoke correctly: what it does, when to reach for it, and the key invariant (Python/Lua directory match). More detail on return shape would be nice but is not required.

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. There is nothing to misdescribe, and the description correctly implies it takes no arguments by framing it as a passive status print.

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

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

States a specific action (print the bridge directory) and the resource (the directory the Python side uses). It's a diagnostic read tool that is clearly distinguished from siblings like reaper_eval or ping by naming what it returns. Minor gap: 'bridge' is project-specific jargon that isn't independently defined.

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

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

Explicitly scopes usage to 'diagnosing setup issues' and even provides the criterion that matters (it must match the Lua side). No explicit when-not or named alternatives, which keeps it short of a 5, but the triggering context is clear.

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 does not disclose whether this mutates project state irreversibly, whether it is undoable, whether it also deselects items inside the range, or what happens when there is no active selection.

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?

It is a single front-loaded sentence with no waste, which is appropriate in shape. However, brevity here borders on under-specification rather than genuine conciseness, since the sentence conveys almost nothing the name did not.

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, low-complexity tool with no output schema, the description is minimally viable. It omits the one useful piece of context an agent would want: how this relates to set_time_selection and what state it leaves the project in.

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. The description correctly implies a no-argument action, and there is nothing parameter-related left to document.

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 verb ("clear") and a resource ("time selection"), but it is essentially a restatement of the tool name and adds no scope detail. An agent can infer the effect, yet nothing distinguishes it from the neighboring set_time_selection beyond the antonym in the 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?

There is no when-to-use guidance, no mention of set_time_selection as the complementary operation, and no note about state preconditions (e.g., what happens if no time selection exists). The agent must infer the usage context purely 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?

With no annotations, the description carries the full burden, and it does disclose real behavior: a MIDI item is created and notes are laid back-to-back starting at start_sec. It does not say whether an existing item is replaced, whether the track must already exist, what happens on an out-of-range root or invalid type, or what 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?

Purpose is front-loaded in the first sentence, followed by the chord-format payload spec and a closing note about note placement. Dense but every clause 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 3-param mutation tool with no annotations and no output schema, the description covers the tricky chords structure well but omits track_index meaning, replacement/overwrite behavior, and success feedback. 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 compensate, and it largely does for the complex parameter: it documents the chord object shape, root range with the C=0 convention, the full type enum, duration_qn units, and the octave default of 4. Only track_index semantics (position in list_tracks ordering) are left unstated.

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: builds a chord progression on a track, creating a MIDI item with one chord per entry. The phrase 'Convenience' implies it is a higher-level wrapper over the raw MIDI tools, but it never names insert_midi_item or insert_midi_notes, so sibling differentiation is only inferable.

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 word 'Convenience' and 'from scratch' imply this is the shortcut path when you want a whole progression rather than placing notes individually, but no explicit when-to-use, when-not-to-use, or named alternative (insert_midi_item / insert_midi_notes) is 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?

With no annotations provided, the description carries the full behavioral burden, and it discloses almost nothing: it does not say the deletion is irreversible, what happens to the track's items/regions, whether it can be undone, or whether subsequent track indices shift. 'Delete' at least signals a destructive write, so it is not misleading, but the safety profile is undocumented.

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 tight sentence with the key qualification (0-based index) front-loaded alongside the action. Nothing is redundant, though it is arguably under-specified rather than concise.

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

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

For a destructive, unannotated, no-output-schema tool in a DAW project, the definition omits irreversibility, side effects on contained items, and index-shift behavior after deletion. The minimum viable information for safely invoking a delete is not present.

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

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

Schema coverage is 0% and the schema title 'Index' adds no meaning, so the description does real work by specifying the index is '0-based'. However, it does not clarify which collection the index refers to (all project tracks, the ordering returned by list_tracks, selected tracks) or what happens with an out-of-range 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?

States a specific verb ('Delete') and resource ('track'), which cleanly separates it from add_track, rename_track, and the set_track_* mutators. It stops short of any explicit sibling differentiation beyond the name itself, but an agent can identify the operation 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 when-to-use guidance, no prerequisites, and no mention of alternatives (e.g., whether removal differs from other track mutators). The phrase 'by 0-based index' hints at input form but says nothing about when this tool is the right choice or what state it requires.

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 and no output schema, so the description carries the full disclosure burden — and it discharges most of it by enumerating exactly what is returned (path, sample rate, length, play state, counts, time selection). It doesn't mention error behavior (e.g. no project open), which is the only 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?

Two sentences: the first front-loads the returned data, the second gives the sequencing cue. No filler, nothing restating the name or title.

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 field enumeration is what makes this tool callable without guesswork. Only missing piece is failure-mode behavior when no project is loaded, a minor gap for a zero-arg read.

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. The description correctly implies no arguments are needed to orient on the current project.

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 an overview') plus the exact resource (current REAPER project) and enumerates the fields returned. An agent can distinguish it from list_tracks, list_regions, and list_markers, which each cover only a subset of this data.

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?

'Call this first to orient yourself' gives a clear, explicit usage cue about sequencing. It doesn't name an alternative or state when not to use it, but for an orientation tool the guidance is unambiguous.

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, but 'Get' already signals a safe read with no side effects. The enumeration of returned fields adds genuinely useful behavioral context since there is no output schema, though nothing is said about permissions or state.

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 that lists the returned settings with zero filler. Every clause earns its place.

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

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

For a zero-param read tool with no output schema, the description usefully enumerates the returned settings, covering the return-value gap the missing output schema leaves. It is nearly complete; only side-effect/permission confirmation is absent, which 'Get' largely implies.

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 is 4. The schema is empty and there is nothing for the description to compensate for on the parameter side.

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

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

The description states a specific verb ('Get') and resource ('render settings') and enumerates what is returned (bounds flag, output file/dir, pattern, sample rate, channels), making the purpose unambiguous. It doesn't explicitly differentiate itself from the sibling 'render_with_current_settings', but the read-only framing is clear enough to separate 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?

There is no explicit when-to-use or when-not-to-use guidance, and no sibling (e.g. render_with_current_settings) is named. Usage is only implied — inspecting settings before invoking a render — so it meets the minimum-viable bar without routing the 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?

With no annotations, the description must carry the full behavioral burden. It discloses the core effect (contiguous items are merged per track), but it does not state that this is a destructive project mutation, whether it is undoable, or what happens if no items are 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?

The description is three short sentences and front-loads the action and effect. Every sentence earns its place by naming the operation, explaining the result, and giving a usage 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?

For a zero-parameter, no-output tool with no annotations, the description is largely sufficient: it names the operation, describes the resulting item grouping, and notes when it is useful. It could still mention selection prerequisites or undo behavior, but the missing pieces are minor for this simple action.

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

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

The tool takes zero parameters, so there are no parameter semantics to describe. The baseline for zero-parameter tools is 4, and the description does not need to add parameter-level detail.

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: 'Glue (consolidate) currently selected items.' It also explains the resulting transformation, 'Each contiguous group on a track becomes one item,' which clearly distinguishes this tool from siblings like split_items_at_time or move_selected_items.

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 one contextual usage note, 'Useful after a lot of editing,' but does not specify when not to use the tool, prerequisites such as needing a selection, or any alternative tools. Usage is implied rather than fully guided.

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 usefully discloses that the created item is empty and that an item index is returned, but it omits side effects (does it select the item?), failure conditions for an invalid track_index, and any permission/precondition requirements.

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 span, followed by the return value. No filler, no restatement of the tool name.

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

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

For a simple three-parameter mutation with no output schema, the description covers purpose, span, and return type, but leaves the meaning of track_index, selection side effects, and error behavior undefined — gaps that matter given 0% schema coverage and no annotations.

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 clarifies that start_sec/end_sec define a span (a range, not two independent points), which adds meaning, but track_index is never explained — is it an index into list_tracks output? — leaving one of three parameters semantically undefined.

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 ('Insert an empty MIDI item on a track') plus the time span, so an agent can distinguish it from siblings like insert_midi_notes or create_chord_progression. It stops short of naming an alternative explicitly, but the 'empty' qualifier makes the distinction 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 when-to-use guidance, no prerequisites, and no alternatives named. An agent cannot tell from the description whether this should precede insert_midi_notes, whether the track must already exist, or what to do if the item already exists.

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 coordinate system (quarter-notes relative to item start) and per-note defaults, which is genuinely useful. However, for a mutation tool it omits whether notes are appended or replace existing content, whether the item must be selected, and any error behavior.

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

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

Two sentences, front-loaded with the action, followed by the precise note payload spec. No filler; every clause 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?

With no annotations and no output schema, the description is responsible for the full behavioral picture. It covers the hardest ambiguity (note coordinates and payload) but leaves gaps: index semantics for track/item, append-vs-replace behavior, and what the call returns. Adequate but not complete for a write 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 and it largely does: it fully documents the notes array element shape (pitch range, start_qn, length_qn, velocity and channel defaults) that the schema leaves as an unspecified additionalProperties object. track_index and item_index are only implied by name and remain unexplained, which keeps this from 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?

Specific verb+resource: 'Insert MIDI notes into an existing MIDI item.' It is clearly distinguished from the sibling insert_midi_item (which creates the item itself) by the word 'notes' and the constraint 'existing MIDI item'. An agent can select this over its siblings 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?

'Into an existing MIDI item' implies a prerequisite (the item must already exist), which is useful guidance. But there is no explicit when/when-not statement or direction to alternatives such as insert_midi_item or create_chord_progression. Usage is only implied.

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

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

With no annotations, the description carries the behavioral burden. It usefully discloses the include_params=false performance tradeoff ('faster'), which is genuine behavioral context, but spends most of its text restating the return shape that the output schema already provides and says nothing about permissions or edge cases.

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-loads the action in the first clause, then details the return structure and the optimization flag. Two tight sentences with no filler, though the nested shape breakdown is somewhat verbose given an output schema exists.

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 read-only two-parameter list tool with an output schema and no annotations, the description covers purpose, return shape, and the include_params tradeoff. Gaps (track_index meaning, routing against siblings) are minor for this complexity level.

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 fully explains include_params ('skip parameter details, faster') and its effect, and track_index is inferable from 'on a track'. The non-obvious parameter is well covered; the obvious one is left implicit.

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 ('List FX on a track with their parameters'), which is clearly distinct from sibling mutations like add_fx, remove_fx, and set_fx_param. It does not explicitly name those siblings to route the agent, but the purpose is unambiguous.

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

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

Usage is implied (read FX state, presumably before adding/removing/editing FX) but there is no explicit when-to-use or when-not-to-use guidance, and no reference to sibling tools. It does provide one practical routing hint via the include_params flag.

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; 'List' implies a safe read but nothing states permissions, side effects, or ordering. The enumerated return fields are useful context, but they largely duplicate the output schema rather than disclosing new behavioral traits.

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 that leads with the verb and the disambiguating constraint. The trailing field enumeration is compact but partly redundant with the output schema, so it does not quite earn a 5.

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

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

For a zero-parameter, read-only list tool with an output schema covering return values, the description supplies everything an agent needs: what is listed, what is excluded, and the shape of each entry. Only the safety/permission profile is left unstated.

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 no parameter semantics to document and the baseline is 4. The description correctly omits parameter discussion rather than inventing filter options.

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 ('List all markers') and immediately scopes it against the nearest sibling with '(not regions)', so an agent can separate this from list_regions without opening either schema. The returned field list further pins down what a 'marker' means here.

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 parenthetical '(not regions)' gives a clear exclusion that steers the agent toward list_regions for the other case, which is strong implied routing. It stops short of naming list_regions explicitly or stating when listing markers is the right choice, so it is clear context rather than full when/when-not guidance.

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 says nothing about read-only safety, scope, ordering, or pagination. The field list it does give is redundant with the output schema, so it adds no behavioral context beyond structured data.

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 padding; the resource is named first and the payload follows. Every token 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 trivial no-argument read tool with an output schema already documenting the return shape, the description is nearly sufficient. It lacks only usage context and a read-only reassurance, which for a simple list operation is a minor 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?

The tool takes zero parameters, so per the baseline rule a 4 applies. There is nothing parameter-related for the description to clarify 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?

States a specific verb and resource ('List all regions in the project') and enumerates the returned fields, so an agent immediately knows what it gets. It does not, however, distinguish itself from neighboring region tools like batch_rename_regions or batch_export_regions.

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

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

No guidance on when to use this versus alternatives such as list_markers or the batch_*_regions tools, and no prerequisites or context. The agent must infer the use case 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 behavioral burden. 'List all tracks' implies a non-destructive read and the field enumeration sketches the returned data, but it never explicitly confirms read-only/no-side-effects and says nothing about ordering, empty-project behavior, or performance on large sessions.

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 and the verb up front. The long comma-separated field enumeration is dense and slightly listy, overlapping with the output schema rather than adding selection value, but nothing is wasted.

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 an output schema present, the description need not document return values, and for a zero-parameter read tool it covers the essentials. The only gap is behavioral framing (read-only confirmation, ordering) that annotations would normally supply.

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 and the schema is an empty object with 100% coverage, so there is no parameter meaning to add. The 0-param baseline of 4 applies.

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

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

Opens with a specific verb+resource ('List all tracks') and immediately scopes it with the exact fields returned. The sibling list contains only differently-scoped readers (list_fx, list_regions, list_markers), so an agent can distinguish this tool without opening any 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?

Usage is only implied: the tool takes no arguments and has no overlapping sibling, so the when-to-use is obvious from the name. However, the description never states conditions, prerequisites, or an alternative (e.g. whether to prefer this over inspecting tracks via other calls).

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 discloses the core effect (all selected items are shifted by delta_sec seconds), but omits whether negative deltas are allowed, what happens with no selection, permission/undo implications, or collision/overlap behavior. For a mutation tool with zero annotation coverage, this is thin.

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 the verb and effect stated first and zero wasted words. Well sized for the tool's simplicity.

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

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

For a one-parameter mutation tool with no output schema, the description covers the essential effect but leaves selection-state requirements, delta sign semantics, and undo/error behavior unstated. Adequate but with clear gaps given the absence of annotations.

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 the single parameter has no description, so the description must compensate. It does add the unit and meaning ('by delta_sec seconds'), but does not explain sign conventions (does a negative value move items earlier?) or constraints, leaving partial ambiguity.

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 ('shift the position of') and resource ('all currently selected items') plus the operative parameter, which distinguishes it from siblings like glue_selected_items or split_items_at_time. It is clear, though it does not explicitly contrast itself with those other selected-item operations.

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 alternatives, nor any prerequisite such as needing items selected first (relevant given siblings select_items_on_track and select_tracks). Usage is only inferable from the phrase 'currently selected items'.

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

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

With no annotations, the description carries the full burden and does meaningful work: it states the project is empty, opens in a new tab, focus switches to it, and crucially that the previous project is not saved. That unsaved-work warning is exactly the kind of behavioral disclosure an agent needs for a destructive-in-effect operation. It does not cover error or permission behavior, so not a 5.

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, zero waste, with the core action front-loaded and the important caveat immediately after. Nothing redundant.

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-param tool with no output schema, the description covers creation, tab behavior, and the unsaved-work caveat. Minor gaps remain (e.g., what happens to the previous project/tab, whether it is closed or left open), but nothing critical to a correct invocation 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?

There are zero parameters and 100% schema coverage, so the baseline is 4. There is nothing parameter-wise the description could add.

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+resource (create a brand-new empty project) plus meaningful scope detail (in a new tab, switches to it). An agent can easily distinguish this from save_project_as or apply_template. It stops short of explicitly naming a sibling for routing, so it lands at 4 rather than 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?

Usage is implied by the nature of the operation, and the 'Does NOT save the previous project' note usefully flags when an agent should save first. However, there is no explicit when-to-use guidance or named alternative (e.g., save_project_as vs this).

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

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

With no annotations, the description carries the burden and does add key traits: it is non-destructive ('Doesn't modify audio data'), it operates on items via volume rather than audio, and it discloses a version requirement. It omits error behavior and whether the change is undoable, leaving a moderate 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?

Front-loads the core action and non-destructive note, then groups parameter guidance compactly. No filler sentences; every clause adds information.

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

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

No output schema exists and none is needed, but the description omits what the call returns and how failures are reported. For a project-mutating command with no annotations, that is a small residual gap given how thoroughly parameters and mechanism are covered.

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 does: it enumerates all `kind` values with the default, gives representative `target_db` values, and spells out the `selected_only` boolean semantics. Every one of the three parameters gains meaning absent from the schema.

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

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

States a specific verb and resource ('Normalize the perceived loudness of items') plus the mechanism (adjusting each item's D_VOL volume). This clearly separates it from siblings like set_track_volume_db, which set a raw level rather than a loudness target.

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 concrete scenarios for choosing values ('-14 for streaming, -23 for broadcast EBU R128') and a prerequisite ('Requires REAPER 6.40+'). It does not name an explicit alternative tool or a when-not condition, so it stops short of full routing guidance.

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 does reasonably well: it signals a non-mutating connectivity probe and discloses the exact success payload ({pong: true, time}). It stops short of stating failure behavior or whether it has any side effects, but for a zero-parameter ping the disclosure is solid.

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 compact sentence with the purpose front-loaded, followed immediately by the return contract. No filler, no repetition of the tool name.

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

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

There is no output schema, so the description compensates by specifying the return value, and a parameterless health check needs nothing more. An agent has everything required to call it and interpret the result.

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 no parameters, so there is nothing to disambiguate; the baseline for zero-parameter tools applies. The schema adds no fields the description needs to explain.

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: a health check confirming the REAPER bridge is running. That is clear, but it does not differentiate itself from the sibling 'bridge_status', which an agent could reasonably assume covers the same ground.

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 phrase 'Health check' implies the context (connectivity/availability verification), but there is no explicit when-to-use guidance and no comparison to the similarly named 'bridge_status' sibling, leaving the agent to infer which one to 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that playback begins at the edit cursor (not the selection or project start), but says nothing about whether the call blocks, whether it interrupts an in-progress record, or what happens if playback is already running.

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 eight-word sentence with the action and the positional qualifier front-loaded and zero filler. Nothing could be removed without losing information.

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

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

For a no-argument transport toggle, stating the action and its start position covers the essentials. The remaining gap is interaction behavior (concurrency with record, blocking semantics), which a slightly richer description could have supplied.

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 per the rubric the baseline is 4. There is nothing for the description to disambiguate beyond the fixed cursor-start behavior it already mentions.

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 ('Start playback') and the exact starting position ('from the edit cursor'), which is more than a restatement of the name. It is separable from 'stop' and 'record' by inference, but the description never explicitly contrasts itself with those siblings.

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

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

There is no statement of when to use this tool versus 'stop', 'record', or other transport actions, and no prerequisites or preconditions are given. The only usage-relevant information is the implied start position, which is inferred rather than stated as guidance.

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 operation is a mutation of note positions in the active MIDI take and scopes it to a specific item, which is useful. It omits reversibility/undo behavior, how notes not on the grid are handled, and error cases for non-MIDI items.

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

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

Two tight sentences, front-loaded with the action and target, with the example grid values serving as immediately usable guidance. No filler or 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 mutation tool with no annotations, no output schema, and 0% schema coverage, the description covers purpose and the key grid parameter but leaves behavioral gaps (reversibility, non-MIDI/error behavior, index ordering). Adequate but not fully complete for the complexity.

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 gives concrete semantics for grid_qn (quarter-note value with example mappings), which substantially exceeds the bare schema, and ties track_index/item_index to the target item. The index semantics (e.g., ordering vs list_tracks/select_items_on_track) remain unclarified, keeping it out of the top band.

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 (Quantize) and resource (note positions in the active MIDI take of the item), and precisely identifies the target via (track_index, item_index). No sibling tool performs quantization, so it is unambiguous against the 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?

The description explains how to choose a grid value (0.25/0.5/1.0 maps to musical note divisions), which is practical guidance. However, it gives no when-to-use versus when-not context, no prerequisite that the item must contain a MIDI take, and no exclusions. Usage is only implied.

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

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

With no annotations the description carries the full burden, and it does disclose real behavior: the `reaper` global is in scope, returned values are serialized to JSON, and `args` is injected as a variable. It omits the behavioral meaning of the `undo` parameter (default true implies mutations are wrapped in an undo block by default) and the `label` parameter, and says nothing about error/failure semantics for arbitrary code.

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?

Four short sentences, front-loaded with the core capability, each carrying distinct payload (scope, return contract, routing rule, a concrete example). Nothing is redundant and the example earns its place by showing the exact call 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?

For an arbitrary-code-execution escape hatch with no annotations and no output schema, the description covers the call contract but leaves gaps an agent needs: the default undo wrapping, what `label` affects, and whether eval'd mutations are as safe/reversible as the typed tools. Adequate but not complete for this risk profile.

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 4 parameters, so the description must compensate. It explains `code` implicitly (the Lua chunk) and `args` explicitly, but never mentions `undo` (default true) or `label` (default 'eval') — two of four parameters 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 precise verb and resource ('Execute arbitrary Lua inside REAPER') and immediately frames itself as the escape hatch that the sibling list of typed tools cannot cover. An agent can distinguish it from list_tracks/add_fx/etc. 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?

'Use this for anything not covered by a typed tool' gives a clear selection condition and implicitly names the alternative category (the typed siblings). It does not give explicit when-not guidance (e.g. prefer a typed tool for safety/discoverability even when eval would work), so it falls just short of the top mark.

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 discloses only the target scope ('all armed tracks'); it says nothing about whether recording begins immediately, whether it blocks, what happens when no track is armed, or how the operation is terminated. That is a substantial gap for a state-changing transport action.

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

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

A single short sentence with the scope constraint front-loaded and zero filler. Nothing redundant and nothing that could be cut.

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 transport action with no output schema, the description covers the essentials but omits failure conditions and post-invocation state (e.g. that stop ends it). Minimum viable, with clear gaps an agent would have to discover empirically.

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 per the rubric the baseline is 4. There is no parameter surface for the description to clarify.

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 ('Start recording') and scope ('all armed tracks'), which clearly separates it from transport siblings like play and stop. It does not name or differentiate against those siblings explicitly, 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 phrase 'all armed tracks' implies a precondition (tracks must be armed, presumably via set_track_record_arm), but there is no explicit when-to-use guidance, no statement of what happens if no tracks are armed, and no pointer to the stop sibling for ending the operation.

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

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

With no annotations provided, the description must carry the full behavioral burden. It states the destructive action ('Remove') but omits consequences like whether remaining FX indices shift, whether the operation is undoable, or what errors occur for invalid indices.

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

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

The description is a single front-loaded sentence with no filler or repetition. Every word contributes to stating the action, target, and required identifier.

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 0% schema description coverage, the description is too thin. It doesn't cover how to obtain valid indices or what state changes after removal, leaving meaningful gaps for correct invocation.

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

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

Schema description coverage is 0%, so the description must explain both parameters. It only clarifies that fx_index is an index used to identify the FX and implies an associated track, but does not explain track_index or whether indices are zero-based.

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 ('Remove'), resource ('an FX'), and scope ('from a track by FX index'). This cleanly separates it from siblings like add_fx, list_fx, set_fx_param, and set_fx_enabled without needing to name them.

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

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

There is no statement of when to use this tool versus alternatives, no prerequisites (such as needing an FX index from list_fx), and no exclusions. Usage is only implied by the operation itself.

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 and fails it. It does not state whether renaming overwrites an existing name (destructive), whether the track must already exist, what happens on an out-of-range index, or what the call returns. Only the bare mutation intent is conveyed.

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?

Four words, front-loaded, zero waste — but the brevity is under-specification rather than effective conciseness. It is appropriately short for a trivial operation but leaves critical detail unstated.

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 0% parameter documentation, the definition is not complete enough for reliable invocation. The agent cannot determine indexing convention, error behavior, or the result of the operation.

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 opaque: "index" never specifies 0-based vs 1-based track addressing, and "name" is only weakly implied to be the new track name. With two required params and no schema documentation, the description should have compensated but adds nothing.

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 clear verb and resource ("Rename a track"), so an agent knows the general operation. However, it is essentially a restatement of the tool name and adds no distinguishing detail versus siblings like batch_rename_items or batch_rename_regions (which target different resources) or versus the set_track_* family. Minimum viable, no 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as batch_rename_items for renaming multiple items. The agent 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses the dependency on REAPER's current render format and how to configure it, plus the meaning of the bounds options. However, it says nothing about whether existing files are overwritten, whether the operation blocks, or what success/failure looks like for a write-to-disk 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?

Three tight sentences, front-loaded with the action and then the parameter specifics. Dense with useful detail and no filler; the parenthetical about format configuration 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 disk-writing render operation with no annotations and no output schema, the description covers bounds and naming well but omits overwrite behavior, `sample_rate` semantics, and any return/result signal. Adequate but with clear gaps given the tool's weight.

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 largely does: it enumerates the valid `bounds` values (the schema provides no enum, only a default) and documents the wildcard syntax for `file_name_pattern` with concrete examples. It leaves `sample_rate` (and the semantics of `output_dir` creation) unexplained, so it's not exhaustive.

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: renders a project to a directory with given bounds and file pattern. The description names the render domain precisely and even distinguishes itself somewhat from `render_with_current_settings` by explaining where the extension/format comes from. It does not explicitly position itself against siblings like `batch_export_regions`, so it's clear but not fully sibling-differentiated.

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?

It hints at the format-config workflow ('configure via REAPER once, or call `render_with_current_settings`'), which is useful routing context. But it never states when to choose `render` over `batch_export_regions` or `render_with_current_settings` directly, nor when each `bounds` value is appropriate. Usage is implied rather than directed.

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 full behavioral burden. It usefully discloses that the operation is non-interactive with no UI popup, but says nothing about blocking behavior, error/failure semantics, what scope is rendered (project, time selection, regions), or whether existing output files are overwritten.

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

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

Two front-loaded sentences with no filler; the trigger and the settings source come first. The parenthetical 'non-interactive — no UI popup' slightly restates itself but is defensible as emphasis.

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-param action with no output schema, the description gives enough to invoke it correctly and explains the settings source. It stops short of covering outcome verification or failure handling, which an agent would have to discover elsewhere.

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 per the rubric this is a baseline 4. The description correctly adds no parameter detail because there is none to describe.

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 (Trigger) and resource (a render), plus the distinguishing detail that it consumes REAPER's current render-dialog settings. It differentiates informally from the sibling 'render' tool via 'current settings', but never names the alternative 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?

Provides a usage condition ('Useful if the user has already configured the render dialog'), which implies when to reach for this tool. However, it never states when to prefer the sibling 'render' tool instead, nor any prerequisites such as an existing render configuration, leaving the choice between the two render tools 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?

With no annotations, the description carries the full disclosure burden. It usefully reveals the side effect that parent directories are created and the .rpp format, but says nothing about overwrite behavior for an existing file, permission requirements, or what a success response looks like.

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 zero filler. The core action leads and the side effect follows immediately.

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

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

For a simple one-parameter tool with no output schema, the description covers the essential action, format, and one notable side effect. Only ambiguous edge cases like overwriting an existing project file are left unaddressed.

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 the single 'path' parameter has no schema description, so the description must compensate. It adds the file format (.rpp) and the directory-creation behavior, but does not clarify whether the path should be absolute, include the extension, or point to a new vs existing file.

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 ('Save') and resource ('the current project') plus the 'as' semantics of saving to a caller-supplied path, with the file format (.rpp) named. An agent can distinguish it from new_project or render, though it doesn't explicitly contrast with a plain save operation.

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

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

No when-to-use guidance, no prerequisites, and no named alternatives among the many siblings. The usage is implied only by the tool name; the description never tells the agent when this is the right choice versus new_project or render.

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 it does disclose two meaningful behaviors: the -1 sentinel meaning 'all items' and that `replace` clears prior selections. It omits error behavior for invalid track indices, whether the selection persists across other calls, and the indexing base.

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

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

Three short sentences with zero filler, front-loading the core action before the sentinel and replace details. Every sentence earns its place.

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

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

For a 4-param, no-annotation, no-output-schema mutation-of-selection tool, the description covers the headline action but leaves indexing conventions and failure behavior unaddressed. 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 must compensate, and it explains start_item/end_item sentinels and the replace flag. However, it never clarifies whether track_index/start_item/end_item are zero-based, which is critical for a selection tool, leaving the required parameter partly ambiguous.

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

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

The description states a specific verb and resource (select items on a track) and scopes it to an index range, which distinguishes it from the track-level select_tracks sibling. It does not explicitly name a sibling or alternative, so it falls short of the top 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?

It explains the -1/-1 shortcut for selecting everything and what `replace` does, which implies usage, but gives no when-to-use vs alternatives, no prerequisites, and no indication of what happens after selection. Usage context must be inferred.

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 usefully discloses that the call replaces any previous selection (effectively destructive to prior state) and that an empty array clears it, but omits index-base convention, behavior on out-of-range indices, and whether the selection persists across project changes.

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 core action and the replacement constraint; no filler content.

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

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

For a one-parameter mutation of selection state with no annotations, no output schema, and no schema descriptions, the description covers the essentials (what gets replaced, how to clear) but leaves the indexing convention and invalid-index handling undefined.

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 that indices is a list of track indices and that [] clears the selection, but never states whether indices are 0-based or 1-based, which is the single most important detail for calling this correctly.

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 (select tracks) plus the scoping detail that selection is by index list. It is clearly distinguishable from the similarly named select_items_on_track, though it does not explicitly name that sibling.

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

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

Usage is only implied: an agent infers this is a prerequisite step before track operations, and the description's note about replacing selection and clearing with [] hints at state semantics. There is no explicit when-to-use vs alternatives guidance or listed prerequisites.

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

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

With no annotations, the description carries the full behavioral burden and does not meet it. It does not say whether the move is undoable, whether it interrupts playback or recording, whether it scrolls the view, or what happens if time_sec exceeds the project length.

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, front-loaded sentence with zero padding, appropriate for a single-parameter tool. It is arguably too terse rather than too verbose, but it 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 trivial one-parameter state setter with no output schema, the description is minimally viable, but it omits units confirmation, boundary behavior, and any interaction with playback or selection that an agent would want before invoking it.

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

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

Schema description coverage is 0%, so the description must compensate, and it only repeats the parameter name in backticks. It adds no range, no reference origin (project start vs. timeline), and no precision guidance beyond what the identifier 'time_sec' already implies.

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 ('Move') and a specific resource ('the edit cursor'), so the agent knows exactly what state changes. It does not, however, distinguish itself from adjacent timeline tools such as set_time_selection or move_selected_items, which a sibling-aware description should do.

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. a loaded project), and no routing to alternatives like set_time_selection. The agent must infer the use case entirely 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?

No annotations are supplied, so the description carries the full behavioral burden, and it discloses almost nothing: it does not say whether the change is reversible, whether it affects audio immediately during playback, what happens with an out-of-range index, or how 'bypass' relates to the 'enabled' boolean. For a state-mutating 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?

It is a single short sentence with no padding and the resource is front-loaded, which is good. But the length here reflects under-specification rather than disciplined conciseness, and the 'Bypass / enable' slash wording adds ambiguity rather than clarity.

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

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

For a three-parameter mutation tool with no annotations, no output schema, and no parameter descriptions, the description is far too thin. An agent cannot determine index conventions, indexing source, or the effect of the boolean from anything provided.

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

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

Schema description coverage is 0% and the description does not compensate: it never explains track_index, fx_index, or whether indices are zero-based and how to obtain them. The only hint is that the FX lives on a track, which is already implicit in the required parameters. Two of three parameters remain completely 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?

The description names a verb (set/bypass/enable) and a resource (an FX on a track), which is enough to place it among the FX siblings add_fx, remove_fx, list_fx, and set_fx_param. However, the slash construction 'Bypass / enable' is ambiguous: it is unclear whether the tool toggles the current state or writes an absolute state, even though the schema exposes a boolean 'enabled'. Sibling differentiation is weak but inferable.

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 alternatives (add_fx, remove_fx, set_fx_param, list_fx), no prerequisites stated, and no note that indices must first be obtained from list_fx or list_tracks. The agent is left to infer the entire usage context.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the normalized default and the 0..1 range, but is silent on permissions, whether the change is reversible/undoable, behavior when an index is invalid, and whether the plugin must be loaded first.

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

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

Two tight sentences, front-loaded with the core action and the key semantic caveat. No filler, though the backtick-quoted code style is slightly informal.

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, no output schema, and 0% schema coverage, the description is thin. An agent still cannot determine valid index ranges, error behavior, or what a successful call returns, which is a meaningful gap for a state-changing operation.

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% across 5 parameters, so the description must compensate. It does explain the value/normalized relationship (which is the most consequential semantic), but leaves track_index, fx_index, and param_index entirely undefined, including whether they are 0- or 1-based.

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 ('Set an FX parameter'), and the normalized/value clarification pins down what 'set' means. It does not, however, explicitly distinguish itself from siblings like add_fx/remove_fx/set_fx_enabled, so the agent must 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?

No when-to-use or when-not-to-use guidance is given, and no prerequisites (e.g. the FX must already exist on the track) are stated. The only guidance is the normalized flag semantic, which is parameter-level rather than usage-level.

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 unit (dB) and the unity-gain reference point, but says nothing about the acceptable range, clamping behavior, whether the change is immediate/reversible, or what the response contains for a mutating call.

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 terse sentences that are fully front-loaded: the action and resource come first, the unit convention second. 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 single-parameter setter with no output schema and no annotations, the description covers the essentials (unit, unity reference). The missing piece is the permissible value range/limits, which matters for choosing a valid argument.

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

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

With 0% schema description coverage, the schema only says 'number'. The description compensates by stating the unit is dB and that 0 equals unity gain, which is the key semantic an agent needs to pick a value. It still omits any valid range or clipping limits.

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+resource ('Set master track volume'), which cleanly separates it from the sibling set_track_volume_db via the word 'master'. It does not explicitly call out that sibling, so the differentiation is implied by the resource name 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?

There is no guidance on when to use this tool, when not to, or which alternative to pick for per-track volume (set_track_volume_db). The only contextual information is the unit convention, not usage conditions.

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 does explain the domain meaning of the input index, which is genuinely useful, but it says nothing about side effects, whether the change is reversible, permission/track-existence requirements, or error behavior for invalid indices.

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

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

Two sentences, front-loaded with the purpose followed by the parameter encoding. Every clause earns its place with no filler.

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

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

For a 2-required-param mutation tool with no output schema and no annotations, the description covers the tricky input encoding well but omits any behavioral or prerequisite context and leaves track_index 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 must compensate. It does so thoroughly for `input` (0..N-1 mono, 1024+ch stereo pair, -1 for MIDI all-channels), adding real meaning beyond the bare integer schema. However, `track_index` is left completely undescribed, so compensation is only partial.

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

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

The description states a specific verb+resource: 'Set the record input for a track.' This is unambiguous relative to the obvious sibling set_track_record_arm, which arms recording rather than choosing the source. It stops short of explicitly naming that sibling, so it is clear but not maximally differentiated.

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, no mention of prerequisites (e.g. track must exist, whether it should be record-armed), and no routing to alternatives. Usage is only implied by the description of the input value encoding.

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 discloses batch scope and the -1 sentinel, but says nothing about what happens with no selection, whether fade values are clamped to item length, whether the operation is undoable, or how errors surface.

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

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

Two short sentences with zero filler; the operation is front-loaded and the sentinel rule follows as essential clarification. Every sentence earns its place.

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

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

For a simple two-parameter setter with no output schema and no annotations, the description covers scope, units, and the sentinel default. It omits edge-case behavior (empty selection, value clamping), which is a minor gap given the tool's low complexity.

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 largely does: it gives units (seconds) for both parameters and, critically, explains the -1 sentinel that the schema only shows as a bare default. This is close to full parameter meaning, though it does not state 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?

States a specific verb (Set), specific resource (fade-in and fade-out seconds), and precise scope (every selected media item). No sibling tool performs fade operations, so no differentiation is needed, and an agent can immediately tell what this does.

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 phrase 'on every selected media item' implies the prerequisite that items must be selected first, but there is no explicit when-to-use, when-not-to-use, or alternative guidance. Usage is inferable 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?

With no annotations, the description carries the full burden. It notes the unit is seconds, but says nothing about whether this overwrites an existing selection, valid range constraints (e.g. end > start), or whether the loop is activated. 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?

One tight sentence with no waste and the key qualifier (loop range, seconds) front-loaded. Nothing extraneous, though there is also very little content.

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

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

For a simple two-parameter setter this is minimally adequate, but with no annotations and no output schema the description should do more: state the relation to clear_time_selection and whether the loop is engaged. Currently an agent can guess its behavior but not confirm it.

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

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

Schema description coverage is 0%, so the schema only provides titles 'Start Sec'/'End Sec'. The description's 'in seconds' adds the unit meaning that the schema titles imply but don't fully specify. However, no ordering, range, or validation semantics for start_sec/end_sec are 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 specific verb (set) and resource (time selection), and the parenthetical '(loop range)' clarifies that this controls the loop region rather than a cursor. It is distinguishable from the sibling clear_time_selection conceptually, though the distinction is not made explicit.

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 clear_time_selection, nor prerequisites such as needing a project loaded or a valid range. Usage is only implied by the parenthetical '(loop range)'.

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 supplied, so the description carries the full behavioral burden. It usefully discloses the sentinel behavior (r=g=b=0 clears/reverts to default), which the schema does not, but says nothing about error handling, whether the change is immediate/persistent, or whether 'index' is zero-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?

Three short sentences, front-loaded with the action, then the value domain, then the special-case escape. No filler and no repetition of the schema.

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

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

For a small four-parameter mutation with no annotations and no output schema, the description covers the essential non-obvious behavior (clearing via zeros) and byte ranges. It is nearly sufficient, with the only real omission being the meaning and indexing convention of 'index'.

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

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

Schema description coverage is 0%, so all four parameters rely on the description, which does add real value for r/g/b (0..255 range, sentinel clear value). The 'index' parameter, the most important for selecting the target, receives no explanation at all, leaving a clear compensation 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 ('Set track color'), and the r/g/b semantics make the target unambiguous. It does not distinguish itself from the many other set_track_* siblings, but the operation itself 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?

Provides one genuine usage rule – 'Use r=g=b=0 to clear (revert to default)' – which tells the agent how to undo a color. There is no guidance on when to prefer this over other track-setting siblings, and no mention of prerequisites such as the track needing to exist.

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

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

With no annotations, the description carries the full burden. It explains the depth encoding thoroughly, but for a state-mutating tool it says nothing about undo behavior, error handling on bad index/depth, or what happens to the project hierarchy/rendering when nesting is applied.

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

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

Two tight sentences; the opaque value encoding is front-loaded before the illustrative example, and nothing is wasted.

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?

Covers the hard part (opaque depth encoding) well and needs no return-value explanation since there is no output schema. The unexplained 'index' parameter and absent mutation side-effect notes leave a small 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 does an excellent job on 'depth' (1, 0, -1, -2 semantics spelled out), but 'index' is never explained — an agent must guess it is a track 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?

States a specific verb and resource: 'Set folder structure depth for a track.' No sibling tool touches folder/nesting structure, so it is effectively distinguishable, though it does not name any alternative 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?

Gives clear guidance on when to reach for it ('Use this to group tracks') plus a concrete worked example pairing depth=1 on a parent with depth=-1 on the last child. No exclusions are needed since no sibling performs folder nesting.

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 state change but omits permissions, error conditions, whether the change is immediate or undoable, and how existing mute state is handled, leaving significant gaps.

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

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

The description is a single, front-loaded sentence with no wasted words. It is appropriately concise for a simple tool, though its brevity comes at the cost of 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 simple mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is too sparse. It leaves the agent without parameter semantics or behavioral context needed to invoke the tool 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% and the description does not explain either parameter. It does not clarify that 'index' is a track index or that 'muted' true means mute, so it fails to compensate for the schema's lack of parameter documentation.

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

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

The description gives a specific verb pair ('Mute or unmute') and resource ('a track'), so the agent can tell what the tool does. However, it does not explicitly differentiate itself from close siblings like set_track_solo or set_track_record_arm, so it falls short of a 5.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. The operation is implied by the name, but the description provides no contextual routing for the 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 are provided, so the description carries the full behavioral burden. It discloses nothing beyond the value mapping: not whether an out-of-range or invalid index errors, whether the change is persisted to the project, whether it applies to selected tracks, or whether it is undoable.

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 front-loaded, with the numerical legend immediately after the verb. Nothing is redundant, though the brevity reflects under-specification rather than disciplined editing.

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 single-target setter with no output schema and no annotations, the core action and value domain are conveyed. However, the identity of the 'index' argument and the error behavior on invalid input are missing, which an agent needs to call this correctly against a project with many tracks.

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 only one of the two required parameters is explained — the description fully documents the 'pan' range, but 'index' is given no meaning at all (track index in which listing? zero- or one-based? must the track exist?). Half the parameters remain opaque 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?

The description states a specific verb and resource ('Set track pan'), and the value legend (-1.0 left, 0 center, 1.0 right) makes the intent unambiguous. It does not distinguish itself explicitly from sibling setters like set_track_volume_db, but the resource noun is distinct enough for 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 use this tool, no prerequisites (e.g. the track must already exist), and no reference to alternatives such as set_track_volume_db, set_track_mute, or set_track_solo. The agent must infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full disclosure burden. It states the mutation (arm/disarm) but says nothing about whether arming is exclusive and disarms other tracks, what permissions or preconditions apply, or what happens on an invalid index.

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

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

A single terse sentence with no waste and the action front-loaded. It is efficiently structured, though the terseness borders on under-specification rather than deliberate concision.

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-required-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description is far too thin. It omits index semantics, arm-exclusivity behavior, and any confirmation of success, all of which an agent needs to invoke 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?

Schema description coverage is 0% and the description adds no parameter meaning. 'Arm or disarm' loosely implies the 'armed' boolean, but 'index' is completely unexplained — the agent cannot tell whether it is zero-based, one-based, or a track ID.

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 pair and resource: arm/disarm a track for recording. It is clear what the tool does, but it offers no differentiation from adjacent siblings such as set_record_input or record, which an agent could plausibly confuse it with.

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 prerequisites (e.g. that the track must already exist, or that this is a precondition for the record tool), and no mention of alternatives. The agent must infer the workflow 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 behavioral burden, and it says nothing about whether soloing is exclusive, whether it affects the audition mix, or whether the change is persisted. For a project-state mutation 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?

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

With no annotations, no output schema, and 0% schema coverage on two required parameters, the description does not supply enough to call the tool confidently. It omits track-index semantics and solo exclusivity behavior that an agent would need.

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 is the only source of parameter meaning and it supplies none. 'index' is almost certainly a track index but that is never stated, and the boolean 'soloed' semantics (true=solo, false=unsolo) must be guessed.

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 (solo/unsolo) and resource (track), and the boolean parameter makes the dual direction explicit. It does not, however, differentiate itself from the sibling set_track_mute or clarify that soloing is the track-level counterpart of play/mute.

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 instead of the mute or selection siblings, no prerequisites, and no mention of how solo interacts with already-soloed tracks. The agent is left to 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. It does disclose important value semantics (-150 means -inf/silent, 0 is unity), which prevents misuse, but says nothing about permission requirements, reversibility, or persistence of the change.

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

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

Three terse sentences, front-loaded with the core verb+resource, and every sentence adds non-redundant value (unit, sentinel, range). No 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 mutation tool with no annotations and no output schema, the value semantics are well covered, but the unexplained 'index' parameter is a real gap an agent needs to call the tool correctly. 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 description coverage is 0%, so the description must compensate. It thoroughly explains the 'db' parameter (unit, -inf sentinel, unity point, practical range) but leaves the required 'index' parameter entirely unexplained — an agent cannot tell it must be a track index. This partial compensation warrants the baseline 3.

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 ('Set track volume') with the unit (dB), which cleanly separates it from set_master_volume_db and set_track_pan in the sibling list. It stops short of naming those alternatives explicitly, so it is clear but not fully differentiated by text.

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

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

The description gives value guidance ('0 = unity', 'typical mix range') but never says when to use this tool versus siblings like set_master_volume_db, nor any prerequisites or exclusions. It reads as reference data rather than usage guidance.

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 does disclose key behavior: which items are affected, the selection filter, and the return value (count of items created). However it omits mutability/undo context, whether new items are destructive to existing ones, and any permission or selection prerequisites.

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

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

Three tight sentences, front-loaded with the core operation and ending with the return value. No filler or 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 2-parameter mutation tool with no output schema or annotations, the description covers the operation, both parameters, and the return count adequately. Minor gaps remain around units and whether the split is reversible, but nothing essential 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 and it does: time_sec is clarified as the split boundary ('crosses time_sec at that time') and selected_only as scoping to current selection. Both of the two parameters gain meaning beyond their bare schema titles.

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 (split) and resource (items) scoped to a time position, which an agent can distinguish from sibling item operations like glue_selected_items. It stops short of naming an alternative sibling, so it's clear but not fully differentiated.

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 or when-not-to-use guidance relative to siblings such as glue_selected_items or move_selected_items. The selected_only clause is parameter behavior, not usage routing, so the agent must infer the context itself.

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 both playback and recording are affected, but says nothing about idempotency, behavior when nothing is active, or any side effects (e.g. cursor position). Significant behavioral gap for an action 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?

A single, front-loaded sentence with zero waste. Appropriately sized for a trivial zero-argument command.

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 parameterless transport stop with no output schema the description is adequate, but it omits what happens after stopping and any return/error behavior, leaving the agent to infer the post-condition.

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 no parameters, so there is no parameter semantics to document. Baseline 4 applies for a parameterless 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 (stop) and both resources it acts on (playback or recording), which an agent can distinguish from play and record. It is clear but does not explicitly differentiate itself from other transport siblings.

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

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

Usage is implied by the transport-control nature of the tool, but there is no explicit when-to-use, when-not-to-use, or named alternative. For a zero-argument stop command the implication is fairly strong, so a middling score fits.

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