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

No annotations exist, so the description carries the full burden, and it does not disclose key mutation traits: where in the FX chain the plugin is inserted, what happens if the plugin name does not match, whether the track must already exist, or whether the operation is idempotent. Only the plugin-name format and a list of built-ins are provided.

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

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

Front-loaded with the action, then the naming constraint, then the built-in list. Every sentence is relevant, though the enumerated built-in plugin names take a fair amount of space for a hint that arguably could be shorter.

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

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

The tool is simple (2 required params, no nested objects, no output schema), and the description covers what fx_name should look like. However, with zero annotation coverage it leaves the mutation behavior and track_index semantics unaddressed, which is a meaningful gap for a state-changing tool.

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

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

Schema description coverage is 0%, so the description must compensate. It adds real meaning for fx_name (exact FX-browser name, plus a concrete list of built-in Cockos names), but gives no clarification for track_index — its indexing base, validity, or whether it must reference an existing track.

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

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

Specific verb+resource ("Add an FX plugin to a track") with the scope explicitly narrowed to a track, which cleanly separates it from sibling add_master_fx, list_track_fx, and remove_fx. The second sentence clarifies the plugin domain (VSTi vs VST/AU), so an agent knows it is the generic FX-insertion tool.

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

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

Usage is implied by the verb — call it when a track needs a new plugin — but there is no explicit when/when-not guidance and no routing to alternatives such as load_fx_preset, insert_track_template, or add_master_fx. The naming convention note ("exact plugin name as shown in REAPER's FX browser") is helpful context but is parameter guidance rather than use-case 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 full burden for behavioral disclosure. It only states the basic action, omitting details like whether it inserts at end, replaces, or any 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?

The description is very concise at one sentence, but this brevity sacrifices essential detail. It is front-loaded but under-informative.

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

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

Given the tool's simplicity (1 required param), the description is incomplete. It does not explain the parameter or provide minimal context for use.

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

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

Schema coverage is 0% and parameter 'fx_name' lacks description. The tool description provides no additional meaning, format, or examples for the parameter.

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

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

The description clearly states the verb 'Add' and the resource 'FX plugin to the master track', which distinguishes it from sibling tool 'add_fx' that likely adds to regular tracks.

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

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

No guidance on when to use this tool vs alternatives like 'add_fx' or conditions for use. The description does not provide any 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 supplied, so the description carries the full burden. It conveys that this is an additive mutation on an existing item, but says nothing about failure behavior for invalid indices, whether notes are appended or can collide, or what is returned. That is thin for a write 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?

The core action is stated first, followed by compact per-parameter notes with no filler. Every line carries information and the format is easy to scan.

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

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

With no output schema, no annotations, and 7 parameters, the description covers the musically tricky fields but omits velocity range/default semantics and, critically, the index basis for track_index and item_index. An agent can call it, but may guess wrong on indexing and velocity.

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 does so well for pitch (0–127, 60=middle C), start/length (seconds, relative to item start) and channel (0–15, 9=drums). However velocity, track_index and item_index are completely undocumented, leaving 3 of 7 parameters with no semantics anywhere.

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

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

States a specific verb and resource ("Add a MIDI note to an existing MIDI item"), which is clearly distinct from siblings like create_midi_item or create_drum_pattern. It doesn't explicitly name those alternatives, so differentiation is implied 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?

The phrase "to an existing MIDI item" implies the prerequisite that an item must already exist (presumably via create_midi_item), but there is no explicit when-to-use/when-not guidance and no mention of alternatives for bulk note creation. Usage is inferable but not spelled out.

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 one side effect (the pan envelope becomes visible), but says nothing about whether existing automation points at the same position are overwritten, what a failed call returns, or what 'if needed' actually means. For an unannotated mutation tool this leaves the behavior largely opaque.

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, with the parameter range immediately following. No filler; the only weakness is the telegraphic 'showing its pan envelope if needed' clause, which reads as an afterthought.

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

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

A 3-required-parameter mutation tool with no annotations, no output schema, and 0% schema coverage needs far more: units for position, indexing convention for track_index, and overwrite semantics. The description covers the pan domain only, leaving the agent to guess on two of three inputs.

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 partially does: the pan range (-1.0 full left to 1.0 full right) is genuinely useful. Position (beats? seconds? ticks?) and track_index (0- vs 1-based) remain undocumented in both schema and description.

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

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

States a specific verb and resource: 'Add a pan automation point on a track.' This is distinguishable from set_track_pan (static pan) and from add_volume_automation by the resource qualifier, though the description never names either sibling explicitly.

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

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

The only usage-adjacent phrase is 'showing its pan envelope if needed,' which hints at a side effect rather than telling the agent when to prefer this over set_track_pan or add_volume_automation. No preconditions, no exclusions, no alternative routing.

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

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

No annotations exist, so the description carries the full behavioral burden. It mentions the envelope is shown 'if needed,' but never states that this is a mutation, whether an existing point at the same position is overwritten, or whether it requires an automation mode to be enabled.

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 the action front-loaded and no filler. The parenthetical envelope behavior is genuinely informative rather than padding.

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 should do more: index base for track_index, overwrite semantics, and what is returned after the point is added are all unaddressed. It is adequate for a simple three-parameter writer but leaves real gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully documents units for position (seconds) and value_db (dB), but says nothing about track_index, leaving one of three required parameters semantically bare.

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: adding a volume automation point on a track, and the 'volume' qualifier implicitly separates it from add_pan_automation. It never names a sibling or states an explicit boundary, so it stops short of a 5.

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

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

There is no explicit when-to-use guidance, no prerequisites (e.g. the track must exist, track_index convention), and no stated alternative such as set_track_volume for a static level. The purpose implies the use case, which is the definition of an implied-usage 3.

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

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

With no annotations, the description carries full burden but provides no behavioral details beyond the action. It does not state whether the modification is destructive, permanent, or requires 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?

Single sentence is highly concise and front-loaded with the main purpose.

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

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

Given the simple tool, the description is too brief. It lacks information about return values, side effects, and requirements (e.g., track/item must exist). No output schema to compensate.

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 description must compensate. It adds context for 'semitones' (can be fractional) but provides no meaning for 'track_index' or 'item_index'. Partial compensation.

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

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

The description clearly states the action (adjust), the resource (pitch of an audio item), and the parameter (semitones, can be fractional). It distinguishes from sibling tools like adjust_playback_rate which adjusts pitch via speed.

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

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

No guidance on when to use this tool vs alternatives like adjust_playback_rate or add_fx. No prerequisites or exclusions mentioned.

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

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

No annotations are provided, and the description gives minimal behavioral disclosure. It explains rate unit but doesn't mention range limits, whether pitch is preserved, or any side effects. The agent is left to infer behavior from the input schema.

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

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

The description is short and front-loaded with the action. Every sentence is relevant, though more details could be added without becoming verbose. It is efficiently stated.

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

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

Given the tool has 3 required parameters and no output schema, the description is too minimal. It lacks instructions on how to select the correct track and item, and what the effect entails (e.g., real-time, destructive). The agent may struggle to invoke it correctly without external knowledge.

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

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

Schema coverage is 0% with no descriptions on parameters. The description adds meaning only for the 'rate' parameter by giving examples. The 'track_index' and 'item_index' are left unexplained, forcing the agent to rely on naming conventions alone.

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

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

The description clearly states the tool adjusts playback rate of an audio item and provides common values (1.0 normal, 0.5 half). However, 'audio item' is somewhat vague and could be more specific, but the purpose is well understood.

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

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

No guidance on when to use this tool versus alternatives like adjust_pitch or other manipulation tools. There is no when-not-to-use or context for choosing this over siblings.

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

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

With no annotations, the description carries the full burden, and it does disclose two important things: the tool renders the project (an expensive, potentially side-effecting operation) and the exact DR algorithm used ('average peak-to-RMS over 3-second blocks'). It omits whether the render is written to disk or discarded, whether it requires stopped transport, and roughly what cost/runtime to expect.

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 the metric list following immediately. Every clause is informative – even the parenthetical definition of the DR score earns its place by pinning down a metric that varies between implementations.

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 analysis tool with no output schema, the description usefully implies what comes back by naming RMS, peak, crest factor, and DR. It still leaves the rendering side effect unexplained and gives no basis for choosing this over analyze_loudness, which is the main ambiguity an agent faces here.

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

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

The schema has zero parameters, so there is nothing for the description to compensate for. The enumerated metrics describe measurements rather than inputs, meaning no parameter meaning is left 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?

States a specific verb and resource ('Render the project and measure dynamic range') and enumerates the exact metrics produced, which is far more informative than a generic 'analyze' label. It does not, however, distinguish itself from the closely related analyze_loudness or detect_clipping siblings, which an agent will have to disambiguate 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?

No guidance on when this tool should be chosen over analyze_loudness, analyze_frequency_spectrum, analyze_transients, or detect_clipping, all of which live in the same sibling set. Usage must be inferred from the metric list alone, and there are no stated preconditions (project loaded, transport stopped) despite the tool rendering.

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 exist, so the description carries the full burden. It does disclose a meaningful side effect — the project is rendered — and specifies the return payload (RMS dB per band), but it never says whether the render is persisted to disk, how long it takes, or whether it disturbs project state. That leaves the expensive/possibly-side-effecting part under-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?

Two sentences, front-loaded with the action, followed by a compact band table that is information-dense with no filler. Every clause contributes either the operation or the return semantics.

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

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

For a zero-parameter tool with no output schema, the description fully covers what comes back (seven named bands with frequency ranges and dB units). The remaining gap is the un-annotated nature of the render step — whether it writes files or blocks — which a no-annotation tool should ideally address.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The band definitions describe output semantics rather than inputs, which is a bonus rather than a parameter explanation.

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

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

States a specific verb+resource ('Render the project and analyze frequency band levels') and enumerates the seven bands with their Hz ranges, which intrinsically separates it from siblings like analyze_loudness, analyze_dynamics, and analyze_stereo_field. An agent can tell exactly what this produces 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 by the phrase 'Render the project' — the agent can infer this is a post-render/mix-inspection tool, but there is no explicit when-to-use, no guidance on choosing it over analyze_loudness or detect_clipping, and no statement of prerequisites (e.g. transport stopped, project loaded).

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 usefully discloses that the tool renders the project to a temp file before measuring, which is a significant hidden side effect. However, it does not state whether the project is modified, how the temp file is cleaned up, permissions, performance, 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?

The description is a single front-loaded sentence that wastes no words. It delivers the key operation, units, and standard 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 no-parameter analysis tool, the description covers the essential operation, measurement basis, and temp-render behavior. It would be stronger if it explicitly described the return values or temp-file lifecycle, especially since there is no output schema.

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

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

The tool takes zero parameters, so there are no parameter semantics to explain. Per the baseline rule for zero-parameter tools, a score of 4 is appropriate.

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

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

The description states a specific verb and resource: render the project and measure integrated loudness and true peak. It names exact units (LUFS, dBTP) and the ITU-R BS.1770 standard, making the tool's purpose unambiguous and distinguishable from generic render or analysis 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 measurement purpose, but the description does not explicitly say when to use this tool versus siblings like analyze_dynamics, detect_clipping, normalize_project, or render_project. There are no exclusions or alternative-selection 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 it does disclose the important side effect that it renders the project first (a non-trivial, potentially slow operation). However it omits whether rendering is offline vs realtime, whether output files are created, and whether it disturbs playback state — material for an unannotated mutating/render 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?

Three short sentences: action first, then return values, then interpretation guidance. Every sentence 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?

With no output schema, the description usefully enumerates the returned metrics and explains how to read the correlation value, which is the key interpretive detail. It falls short only on operational context, such as render duration or side effects, for an annotation-free 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to clarify, and it correctly implies the whole project is the implicit input.

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

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

States a specific verb+resource pair ('analyze stereo width and mono compatibility') and immediately names the exact measurements returned. It is unambiguously separable from sibling analysis tools like analyze_loudness, analyze_dynamics, and analyze_frequency_spectrum.

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 concept of mono compatibility checking, but there is no explicit when-to-use or when-not guidance. It never tells the agent to prefer this over render_stems or render_project, nor when a stereo-field check is warranted versus other analyses.

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 exist, so the description carries the full burden; it does disclose two non-obvious traits — that the tool performs a render (a side effect beyond a pure read) and that results are capped at 100 onsets. It omits whether the render writes files, whether it covers the whole project or a time selection, and what units the timing uses.

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

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

Two short sentences, front-loaded with the action and followed by the return shape. Every clause carries information; no filler or restatement of the tool name.

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

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

With no output schema, the description correctly supplies the return shape (count plus onset timings, capped at 100). It stops short of specifying timing units, ordering, or whether the render operates on the full project, which matters for a tool whose behavior depends on a render step.

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; there is nothing for the description to disambiguate. The mention of 'up to 100 transient onset events' usefully frames the result size but is not a parameter concern.

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-plus-resource: renders the project and detects transient events, calling out note attacks and drum hits as examples. This is clearly distinct from sibling analyses (analyze_loudness, analyze_dynamics, detect_clipping), so an agent can route correctly without reading further.

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

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

The description never says when to choose this over the other analyze_* siblings, nor any precondition such as requiring audio/MIDI content or a completed render. Usage is only inferrable from the stated return value (count and timing of onsets).

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 exist, so the description carries the full behavioral burden, and it leaves key questions open: whether an existing limiter is replaced or a second instance added, whether prior settings are lost, and whether the operation is reversible. It does disclose the parameter defaults and the direction of the release control, which is genuinely useful context.

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

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

Front-loaded with the action, then two tight parameter sentences; no filler. Formatting as a single paragraph makes the per-parameter guidance slightly harder to scan than a list would be, 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 2-parameter mutation tool with no annotations and no output schema, parameter documentation is solid but the effect on project state is under-specified – an agent does not learn whether this stacks FX or replaces them, or what it gets back. Adequate, but with a clear behavioral 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 and largely does: threshold_db gets an explicit -60 to +12 dB range, and release_db_per_sec is explained as dB-per-second recovery with a typical floor of ~6, direction (higher = faster) and default 15. Only the threshold default (-0.5) is left to 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 – adds the ReaLimit plugin to the master track and configures two of its parameters. An agent can tell it is a convenience wrapper around master-bus limiting. It does not explicitly contrast with siblings like add_master_fx or apply_mastering_chain, which could also place a limiter.

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

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

Usage is only implied: the tool is for putting a limiter on the master bus, which fits mastering/loudness workflows. There is no explicit when-to-use versus add_master_fx, apply_mastering_chain, or normalize_project, and no stated 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 burden. It discloses the chain components for each preset and implies a mutation of the master track, but it does not clarify whether existing master FX are preserved or replaced, nor does it mention reversibility or 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?

The purpose is front-loaded, the preset list is compact, and the follow-up instructions are directly useful. Every sentence contributes without unnecessary repetition.

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

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

For a mutation tool with no annotations and no output schema, the definition covers presets and next steps but omits important side-effect details such as whether applying a chain overwrites existing master FX. It is adequate but has clear behavioral 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 by listing the preset values and explaining the FX chain for default, loud, and gentle, which adds substantial meaning beyond the bare string parameter.

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

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

States a specific verb and resource: adding a standard mastering FX chain to the master track, with preset variants. It is clear what the tool does, but it does not explicitly differentiate itself from sibling tools such as add_master_fx or apply_limiter.

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

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

Gives useful follow-up guidance: use set_master_fx_parameter after applying, and use list_master_fx/get_fx_parameters to discover indices. However, it does not state when to choose this tool over alternatives like add_master_fx or apply_limiter, nor does it provide exclusions.

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

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

The description indicates a direct set action, but does not clarify if it toggles or sets to the given state, nor does it mention side effects or permissions. With no annotations, more detail would be beneficial.

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

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

The description is a single, concise sentence with no wasteful words.

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

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

The description lacks context on indexing (0-based?), success/failure behavior, and required prior steps (e.g., track must have FX). With no output schema and limited annotations, it is insufficient.

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?

Parameters have clear names (track_index, fx_index, bypassed), but the description adds no additional meaning. With zero schema description coverage, more elaboration is needed to clarify indexing and boolean meaning.

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

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

The description clearly states the tool enables or bypasses an FX plugin on a track, specifying the verb and resource. It distinguishes from siblings like remove_fx (removes) and add_fx (adds).

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

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

No guidance on when to use this tool versus alternatives (e.g., get_fx_parameters to check current state). No prerequisites or exclusions mentioned.

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

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

With no annotations, the description carries the full burden. It does disclose the important non-obvious side effect that this both creates a bus track and reroutes the listed tracks into it via sends. It omits send level defaults, irreversibility, and what happens if indices are invalid or already routed.

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 immediately followed by the key parameter note. No filler, though the second sentence is slightly redundant with the first's 'route the given tracks.'

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 unannotated mutation with a compound side effect and no output schema, the core behavior is explained but key operational details are missing: default send level, return value (e.g., new bus index/name), and error behavior for out-of-range indices.

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 track_indices as the tracks 'to feed into the bus,' which is meaningful, but leaves 'name' and format constraints (index base, ordering, duplicates) undocumented.

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

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

States a specific verb and resource ('Create a new bus track') plus the compound routing behavior via sends. It is distinguishable from siblings like create_track or create_send by the combined create-and-route action, though it never names those alternatives.

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

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

Usage is implied: create a bus when you want multiple tracks summed through sends. There is no explicit when-to-use/when-not-to-use guidance versus create_send (routing to an existing bus) or create_track (plain track creation), which are the nearest siblings an agent would hesitate between.

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 burden but does disclose meaningful behavior: everything is written as a single MIDI item and all chords are voiced around middle C. It omits mutation side effects, what happens to existing item content, error conditions, and the response shape, leaving substantial 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?

Front-loaded with the core action and efficient across four short lines, with no filler. Slightly under-sizes the explanation of the non-chord parameters, but the structure itself is clean.

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

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

For a 4-parameter mutation tool with zero schema descriptions, no annotations, and no output schema, the description should cover positioning units, beats_per_chord behavior, and track targeting. It only fully addresses one parameter, leaving the agent under-specified 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 coverage is 0%, so the description must compensate, but it only really explains the 'chords' parameter (comma-separated, supported types). It leaves 'start_position' units unclear, never mentions 'beats_per_chord' behavior despite a default, and doesn't clarify '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 ('Create a chord progression on a track as a single MIDI item'), which is clear and actionable. However, it does not distinguish itself from sibling tools like create_midi_item or add_midi_note, which an agent could reasonably confuse with this higher-level helper.

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 never says when to prefer this over create_midi_item, add_midi_note, or create_drum_pattern, nor does it state prerequisites (e.g., that the track must exist). Usage is left entirely 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?

No annotations, so the description carries the full burden. It usefully discloses that all notes go to MIDI channel 9 per GM, but says nothing about side effects on the target track (overwrite vs. append), validation/error behavior on mismatched beats vs. pattern length, or whether a new MIDI item is created.

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, followed by the legend, a concrete 16-step example, and a channel note — all earning their place given zero schema documentation. Slightly dense but 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 mutation tool with no annotations and no output schema, the critical 'pattern' grammar is well specified, but the four other parameters and the resulting behavior/return are undocumented. Adequate for calling it with a plausible pattern, incomplete for calling it confidently.

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

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

Schema description coverage is 0%, so the description must compensate for five parameters and only really covers 'pattern' (with a full character legend and example). track_index, start_position (units unclear), beats, and repeats are left entirely unexplained in both schema and description.

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

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

States a specific verb+resource ('Create a drum pattern on a track') plus the unique mechanism ('step-sequencer string'), which implicitly separates it from add_midi_note (single notes) and create_chord_progression. An agent can pick this tool without opening the schema.

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

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

The step-sequencer framing implies when to use it (programmatic drum beats), but there is no explicit guidance such as when to prefer add_midi_note or what to do if the track already contains a MIDI item. Usage is inferred rather than stated.

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

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

No annotations are provided, and the description does not disclose side effects, permissions, or constraints (e.g., whether items can be overwritten, parameter limits). It only states creation and return value, lacking behavioral depth.

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

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

The description is very concise (two sentences) and front-loaded with the core action. However, it may be overly sparse, sacrificing useful details for brevity.

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

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

Given the lack of output schema, no annotations, and zero parameter descriptions in either schema or description, the tool is severely underdocumented. Missing details include error handling, return value format, and parameter constraints.

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

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

The description adds no information about the parameters (track_index, start_position, length) beyond the input schema. With 0% schema description coverage, the description should compensate, but it fails to explain units, valid ranges, or how parameters affect behavior.

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

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

The description clearly states the action ('Create an empty MIDI item on a track') and the resource (MIDI item). It also indicates the return value (item_id) and links to a sibling tool (add_midi_note), helping differentiate its role in the workflow.

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

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

The description implies a usage chain (create item then add notes), but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites beyond the implicit workflow.

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 does disclose the key side effect well — a new tab is created and the current project's unsaved state is preserved — but is silent on whether the new project exists on disk, what the name parameter governs, 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?

Two sentences, no waste, with the tab-creation and state-preservation behavior front-loaded ahead of parameter details.

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

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

No output schema and no annotations, so the description must cover behavior and inputs. It handles the state-safety question but leaves the name parameter and the time-signature format undocumented, which for a 0%-coverage schema is a real 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 names two of the three parameters (tempo, time signature) and their purpose but gives no format detail for time_signature (e.g. '4/4' string form), and the name parameter is never explained.

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: creates a new REAPER project with a defined tempo and time signature, in a new project tab. It implicitly distinguishes itself from load_project by stating a new tab is created rather than an existing project opened, though no sibling is named outright.

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 clause 'the current project stays open, unsaved changes included' implies this is the non-destructive path versus loading or overwriting, but the description never says when to use this versus load_project or save_project. Usage 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?

No annotations provided, and the description does not disclose any behavioral traits (e.g., whether it overwrites existing sends, if it requires specific track types, or what happens to the routing). The mutation effect is implied but not detailed.

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

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

The description is a single sentence with no extraneous content. While concise, it sacrifices detail that could aid an agent. It is efficiently structured but overly minimal.

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

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

Given the tool involves creating a routing connection between tracks, the description lacks details on routing implications, error conditions (e.g., invalid indices), and the return value. It is insufficient for an agent to understand the full impact.

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%, yet the description only mentions 'from one track to another' without explaining the parameters (source_track_index, dest_track_index, volume_db). The meaning of indices, default volume, and optional nature of volume_db are not clarified.

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

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

The description clearly states the verb 'create' and the resource 'aux send', with source and destination tracks specified. This distinguishes it from sibling tools like 'create_bus' or 'create_track'. However, 'aux send' might be slightly ambiguous without domain knowledge.

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

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

No guidance on when to use this tool versus alternatives like 'set_send_volume' or 'remove_send'. Missing context on prerequisites, such as whether tracks must already exist or have specific routing.

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

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

With no annotations, the description carries the full burden. It discloses that the track is appended at the end, but says nothing about what is returned (track index/ID), whether a project must be open first, or what happens on duplicate names.

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 lines, action front-loaded, zero filler. It is efficient though it trades away detail that would have been useful for an unannotated mutation tool.

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

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

For a no-annotation, no-output-schema mutation with an undocumented required parameter, the definition is thin: no prerequisites, no result shape, no failure behavior. The only additions are placement and the track_type vocabulary.

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 declares no enum, so listing "audio, midi, instrument, folder" is genuine added value for track_type. The required `name` parameter is never explained, and the audio default is left to 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 ("Create a new track") plus the placement semantics ("at the end of the project"), which separates it from insert_track_template and create_bus. It does not explicitly name a sibling alternative, but the action is unambiguous.

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

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

There is no guidance on when to use this versus insert_track_template or create_bus, nor any prerequisite such as a loaded project. The only usage signal is implicit in the append-at-end phrasing.

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

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

No annotations are provided, so the description must disclose behavior. It states 'delete' which implies destruction, but it does not mention side effects, permissions, or reversibility, 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 very short and to the point, but it lacks necessary details, so while concise, it fails to be sufficiently informative.

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

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

Given the single parameter and no output schema, the description should provide context about the action's outcome, but it does not, leaving the agent uncertain about what happens upon deletion.

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

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

Schema description coverage is 0%, so the description must compensate. It only says 'by its index' without clarifying indexing bases (0-based vs 1-based) or which track list is referenced, adding minimal value.

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

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

Description clearly states the verb 'delete', the resource 'track', and the method 'by its index', which is specific and distinguishes it from sibling tools like create_track or rename_track.

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

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

No guidance on when to use this tool versus alternatives; it only mentions the method of identifying the track but lacks context about prerequisites or use cases.

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 well: it explains that the tool renders the project, defines clipping precisely, and discloses the returned values (clipped sample count, peak level in dB, and a boolean result). It does not mention rendering cost, side effects, or prerequisites, but the core behavior is clear.

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

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

Two tightly written sentences with zero waste, front-loading the core action and then defining the return values. Every sentence earns its place.

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

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

For a zero-parameter tool with no output schema, the description is complete: it explains what is done, the exact clipping threshold, and what information is returned. An agent has enough to invoke it correctly without needing further details.

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

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

The tool has zero parameters, so the baseline is 4. The description correctly implies that no parameters are needed and focuses on the operation and return values instead.

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

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

The description states a specific action and resource: it renders the project and detects digital clipping, with a precise threshold (samples at or above 0 dBFS). It is distinguishable from general render or analysis tools, though it does not explicitly name sibling alternatives like render_project or analyze_loudness.

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: this tool is for checking clipping after rendering. However, the description gives no explicit when-to-use guidance or comparison to alternatives such as render_project or analyze_loudness, leaving the agent to infer the context.

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

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

With no annotations, the description carries the full behavioral burden. It defines what the trim/fade values do semantically (seconds to remove, fade length), which is useful, but it omits key behavioral facts: whether the edit is destructive to the underlying audio file, whether it is reversible, what happens to already-applied fades, or what the tool returns. 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?

The description is front-loaded with the core purpose in one sentence, followed by a compact parameter glossary that earns its place given the 0% schema coverage. There is no filler or repetition.

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

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

For a 6-parameter mutation tool with no annotations and no output schema, the description is moderately complete: the operation and value units are clear, and four parameters are explained. But it leaves the required track_index/item_index undocumented and provides no behavioral context about mutability or results, so an agent still lacks information needed to call it confidently.

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

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

Schema description coverage is 0%, so the description must compensate. It does well for four parameters, clarifying that start_trim removes seconds from the beginning, end_trim from the end, fade_in/fade_out set fade lengths in seconds. However, the two required parameters—track_index and item_index—are never explained, so the agent gets no guidance on how to identify the target item.

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: 'Trim an audio item and/or add fades.' An agent can tell exactly what operation is performed. It does not differentiate from any sibling, though no sibling performs the same operation, so ambiguity is limited.

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

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

There is no explicit guidance on when to use this tool versus alternatives, nor any prerequisites or when-not-to-use conditions. The reader must infer usage purely from the parameter list; the description never says 'use this to trim an existing audio item' or warns about related tools like adjust_playback_rate.

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

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

No annotations are provided, so the description carries full burden. It implies a read-only operation without stating it explicitly. The description mentions returned data (names, indices, values) but does not disclose any side effects or safety aspects.

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

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

Single sentence, no filler, communicates core purpose and output content efficiently.

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

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

Given the lack of output schema, the description should explain the return structure (e.g., array of parameter objects). It only mentions what is included but not how it is organized. For a tool with two parameters and no annotations, the description is minimal and leaves gaps in understanding the response format.

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%, meaning parameters have no descriptions. The tool description does not compensate: it does not explain what track_index and fx_index represent (e.g., zero-based?), or how to obtain them. This leaves the agent with insufficient context to correctly populate the parameters.

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

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

Description clearly states the verb 'get' and the resource 'parameters for an FX plugin', and specifies the returned content: names, indices, and current values. This distinguishes it from sibling tools like set_fx_parameter (which modifies) and list_track_fx (which lists FX, not parameters).

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

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

No guidance on when to use this tool versus alternatives such as set_fx_parameter or list_track_fx. It does not mention prerequisites, typical use cases, or exclusions.

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

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

No annotations exist, so description carries full burden. It states a read operation with no side effects, but does not mention prerequisites (e.g., project must be open) or error cases. Adequate but leaves some uncertainty.

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 sentence, no waste, front-loaded with action and resource. Every word earns its place.

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

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

For a zero-parameter tool with no output schema and no annotations, the description covers purpose and output fields. Could mention more details like units or format, but this is sufficient.

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

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

No parameters, so baseline is 4. The description adds value by enumerating the data fields returned, which is not in the input 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 specifies the verb 'Get' and the resource 'current project', and lists the exact information returned (name, path, tempo, tracks, length). This clearly distinguishes it from sibling tools like 'create_project' or 'get_track_info'.

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 context is implied: use when needing generic project information. No explicit guidance on when to avoid or alternatives, but given the tool's simplicity, this is minimally adequate.

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

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

No annotations provided, so description must disclose behavioral traits. It mentions 'detailed information' but does not specify side effects, access requirements, or output format. This is insufficient for an agent to gauge safety or expectations.

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

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

The description is a single sentence, front-loaded with the primary action. However, it is too brief, omitting necessary details for safe use. Conciseness here sacrifices completeness.

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

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

The tool is simple (one param, no output schema), but the description fails to explain the return structure or how the param is interpreted. Contextual completeness is low for a read operation; the agent may not know what to do with 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?

Only parameter is track_index, with 0% schema description coverage. The description adds no meaning about indexing (0- or 1-based), valid range, or required format. The schema provides only type and name, so the agent lacks critical usage 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 clearly states it retrieves detailed information about a track, listing FX and items. This verb+resource structure differentiates it from siblings like list_tracks (which likely provides summary) and get_fx_parameters (which focuses on single FX parameters).

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

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

No guidance on when to use this tool versus siblings. No mention of prerequisites or context. For example, it does not indicate if tracks need to exist first, or that it is a read-only operation.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about whether the import overwrites existing media, what happens on an invalid track_index, whether paths must be absolute, or what the call returns. The format-support note ('wav, aiff, mp3, flac, ogg, etc.') is the only added behavioral value.

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 immediately followed by the useful format-compatibility note. Nothing is padded, though the position unit could have been folded more tightly into the first clause.

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?

This is a project-mutating tool with no annotations, no output schema, and no parameter descriptions. An agent is left not knowing what the call returns (e.g., a new item reference needed for later edit_audio_item calls) or what side effects occur, which is materially incomplete for a write 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%, so the description must compensate, and it only adds meaning for one parameter: position is 'in seconds'. file_path (absolute vs relative, extension handling) and track_index (zero- or one-based, must track exist) remain fully undocumented in both schema and description.

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

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

States a specific verb and resource ('Import an audio file onto a track at the given position') with the unit of position clarified. An agent can distinguish it from create_midi_item or edit_audio_item by the audio-file framing, though no sibling is named explicitly.

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

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

The description never says when to reach for this versus create_midi_item, edit_audio_item, or insert_track_template, nor does it state prerequisites such as the track needing to exist or the file needing to be on disk. Usage is only inferable from the tool name and purpose sentence.

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 well: it discloses that templates can contain multiple tracks, existing tracks shift down when position is specified, and inserted tracks are left selected. It does not mention permissions, undo/reversibility, or error behavior, but covers the key mutation effects.

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

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

The description is front-loaded with purpose and preservation behavior, then cleanly documents the two parameters. Every detail earns its place, and examples make the parameter formats immediately usable.

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 mutation tool with no output schema and no annotations, the description is almost complete: it covers insertion effects, template formats, positioning, and selection behavior. It stops short of explaining return values or failure/undo behavior, but an agent has enough 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%, so the description must compensate, and it does. It explains that template accepts a name or path from list_track_templates, gives examples, and permits an absolute .RTrackTemplate path; it also explains position as a 0-based index that shifts existing tracks down, with omission appending at the end.

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: inserting a saved track template into the current project. It distinguishes this from generic track creation by explaining that FX state, routing, folder structure, envelopes, and items are preserved, matching REAPER's native 'Insert track from template' behavior.

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

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

The description clearly points to list_track_templates as the source for valid template names and paths, and allows an absolute .RTrackTemplate path. It implies when to use this tool, but does not explicitly contrast it with create_track or state when not to use it.

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

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

No annotations are provided, so the description carries the full burden. It says 'list all FX plugins' but does not disclose whether bypassed FX are included, what information is returned (e.g., names, parameters, status), or if it is read-only. For a simple list operation, more detail would improve transparency.

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

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

The description is a single sentence with no unnecessary words. It is perfectly concise and front-loaded.

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

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

Given no output schema, the description should clarify what is returned (e.g., FX names, IDs). It only states 'list all FX plugins', which is ambiguous about the output format. For a list tool, this is incomplete.

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

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

There are no parameters, and schema coverage is 100%. The description adds value by specifying the resource being listed. With zero parameters, a baseline of 4 is appropriate.

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

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

The description clearly states the verb 'List' and the resource 'all FX plugins on the master track'. It is specific and distinguishes from sibling tools like 'list_track_fx' (which lists FX on a specific track) and 'add_master_fx' (adds FX to master).

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

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

The description provides no guidance on when to use this tool versus alternatives. With many sibling tools related to FX and master track, some context on when to list master FX vs track FX would be helpful.

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 disclose behavior. It only says 'list', implying read-only, but lacks details on return format, side effects, or permissions required.

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

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

A single, concise sentence with no redundant information. Every word earns its place.

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

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

For a simple list tool with one parameter and no output schema, the description is minimally adequate but could specify what constitutes a 'send' or the return structure.

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%; the description does not mention the required 'track_index' parameter, nor does it add meaning beyond the schema's field name and type.

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

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

The description clearly states the action 'List all sends' and the resource 'from a track', using a specific verb and resource that distinguishes it from siblings like create_send or remove_send.

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

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

No guidance on when to use this tool versus alternatives such as create_send or get_track_info. It does not specify prerequisites or typical use cases.

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. It implies a read operation ('list') but provides no details on side effects, return format, or error behavior. Acceptable for a simple list but not explicit.

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 sentence, no fluff, front-loaded with the essential action and target. Highly efficient.

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

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

For a simple tool with one parameter and no output schema, the description covers the basic purpose but lacks details on return format and error handling, leaving gaps for full understanding.

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 single parameter 'track_index' has no schema description (0% coverage) and the tool description adds no extra meaning, such as whether indexing is 0-based or 1-based, leaving 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 clearly specifies the verb 'list' and the resource 'FX plugins on a track', distinguishing it from siblings like 'list_master_fx' which targets the master track.

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

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

No guidance on when to use this tool versus alternatives (e.g., for FX parameters use get_fx_parameters). The description only states functionality without contextual or exclusionary advice.

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

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

No annotations provided. Description fails to disclose behavioral traits such as whether the operation is read-only, what constitutes 'basic parameters', or what happens if the project has no tracks. This is minimal disclosure for a tool that likely performs a read 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?

Single, concise sentence with no extraneous information. Clearly front-loaded and efficient.

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

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

Given the simple nature of the tool (no parameters, no output schema), the description is adequate but leaves 'basic parameters' undefined. While it covers the core function, additional detail on what parameters are returned would improve completeness.

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?

No parameters exist in the schema, so the description's mention of 'basic parameters' refers to the output, not inputs. Since schema coverage is 100% (empty), the description adds no parameter info but also does not need to. Baseline score of 4 for zero-parameter tools 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?

Description clearly states it lists all tracks, specifying the resource (tracks) and action (list). However, it does not explicitly distinguish from the sibling tool 'get_track_info', which might be for individual tracks.

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

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

No guidance on when to use this tool versus alternatives like 'get_track_info' or other listing tools. The description does not mention context or prerequisites.

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

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

With no annotations, the description carries the burden and largely meets it: it discloses that the scan is recursive into subfolders and enumerates the exact shape of each entry ('name', 'path' relative form with an example, absolute 'file', contained track names). It doesn't mention cost, failure modes (e.g. missing folder), or ordering, which keeps it from 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?

Three sentences, front-loaded with the verb and resource, then the entry fields, then the downstream handoff. Every clause earns its place, and the 'Vocals/Lead Vox' example is a compact way to convey path format.

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 must describe the return values, and it does so field by field including the relative-vs-absolute path distinction. Combined with the insert_track_template pointer, an agent has everything needed to call it and act on 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?

Zero parameters, so baseline is 4; the description correctly adds nothing about inputs and instead spends its words on output field semantics. That is useful given the empty schema, though it belongs more to return-value clarity than parameter meaning.

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

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

States a specific verb+resource ('List the track templates') and pins down the location (.RTrackTemplate files in REAPER's TrackTemplates folder, subfolders included), which distinguishes it from sibling list_tracks and from insert_track_template. The scope of entries returned is spelled out so an agent knows exactly what it gets.

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?

"Pass either 'name' or 'path' to insert_track_template" tells the agent this is the discovery step preceding insertion, which is real routing guidance to a named sibling. It stops short of explicit when-not-to-use guidance or stating whether it is safe/idempotent, but the intended workflow 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 exist, and the description does not disclose behavioral traits such as overwriting settings, whether the preset name is case-sensitive, or return 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?

Single sentence with core action, but overly brief. Could be more structured but avoids fluff.

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

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

Given 3 required parameters and no output schema or annotations, the description is insufficient for safe and correct tool 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 coverage is 0%, and the description provides no additional meaning beyond parameter names. Lacks clarification on index base, preset naming convention, or constraints.

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

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

The description clearly states the verb 'load' and the resource 'saved preset for an FX plugin', distinguishing it from siblings like bypass_fx or set_fx_parameter.

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

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

No guidance on when to use this tool vs alternatives, no prerequisites (e.g., FX must exist) or exclusions provided.

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

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

No annotations are provided, so the description must disclose behavioral traits. It does not explain whether loading replaces the current project or merges, potential side effects, or error handling (e.g., missing file). The description is too minimal to guide safe invocation.

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, well-structured sentence that conveys the essential action and input. Every word earns its place with no redundancy.

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

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

Given the tool has one parameter, no output schema, and no annotations, the description should cover return value, effect on state, and error conditions. It lacks details on whether the loaded project replaces the current one or what the response indicates. This leaves significant gaps for an agent.

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 only parameter, 'project_path', is described as 'the given file path', which adds basic context beyond the schema's type string. However, it does not specify format validity (absolute vs. relative) or required file extension, leaving room for ambiguity. Schema coverage is 0%, so description partially compensates.

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

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

The description clearly states the verb 'Load', the resource 'REAPER project (.rpp)', and the input (file path). It distinguishes from siblings like 'create_project' which creates a new project rather than loading an existing one.

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

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

No guidance is provided on when to use this tool vs. alternatives like 'create_project' or 'save_project'. There is no mention of prerequisites (e.g., whether a project must already be open) or constraints on the file path format.

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 does disclose the mechanism (measure first, then write the master volume), which is useful. However it does not say whether the existing master volume is overwritten irreversibly, whether automation is respected, what happens with silence or already-normalized material, or whether the operation is offline or transport-dependent.

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 filler: the action sequence is front-loaded and the reference values follow. 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?

There is no output schema, yet the description never says what is returned (measured integrated loudness? the applied gain? the new master value) or what happens on failure, so an agent cannot predict the result shape. For a one-parameter mutation tool this is adequate but leaves the return contract 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?

Schema coverage is 0% and the single parameter has only a bare default of -14 with no description, so the description must compensate — and it does, explaining that target_lufs is an LUFS loudness level and giving concrete values tied to delivery contexts (-14 streaming, -16 podcast, -23 broadcast). It stops short of stating the default explicitly or allowable range.

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 ('Measure the project's integrated loudness, then adjust the master volume') and thereby implicitly separates itself from analyze_loudness and set_master_volume, though it never names those siblings. An agent can tell what it does, but must infer the boundary with the analysis and master-volume tools 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?

The common-targets list implies the post-mix/pre-render workflow, but there is no explicit 'use this instead of X' guidance against analyze_loudness, set_master_volume, apply_mastering_chain, or apply_limiter, several of which overlap in intent. Usage is implied rather than stated.

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

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

The description accurately conveys a non-destructive playback action, which is sufficient given no annotations. It could mention idempotency (e.g., does nothing if already playing) but is otherwise transparent.

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

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

The description is a single, focused sentence with no extraneous content, efficiently communicating the essential information.

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

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

For a simple, parameterless action, the description fully covers the tool's behavior and purpose. No additional context is needed.

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 no parameters, so the description does not need to add parameter details. Baseline 4 applies per rubric.

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

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

The description clearly states the action ('start playback') and the context ('from current cursor position'), distinguishing it from related tools like 'stop_transport' and 'start_recording'.

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

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

The description implies the use case but provides no explicit guidance on when to use this tool versus alternatives (e.g., when to use play vs record). No exclusions or prerequisites are mentioned.

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

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

No annotations provided, so the description carries full burden. It only states the action without disclosing side effects (e.g., immediate removal, undo behavior, error handling 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?

Single sentence with no wasted words. Front-loaded with the action and target.

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?

Essential context is missing: no mention of prerequisite steps (e.g., list_track_fx to get indices), no description of expected behavior for edge cases (e.g., invalid index), and no output schema to describe 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?

Schema coverage is 0% and the description does not explain the parameters. 'track_index' and 'fx_index' are just named; their meaning (e.g., fx_index is the index in the track's FX chain) is not elaborated, leaving the agent to infer.

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

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

The description clearly states the verb 'remove', the resource 'FX plugin', and the scope 'from a track by its index'. It distinguishes itself from sibling tools like add_fx and bypass_fx.

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

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

No guidance on when to use this tool vs alternatives (e.g., bypass_fx). No prerequisites mentioned, such as needing to list track FX first to obtain the correct 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?

No annotations are provided, and the description does not disclose behavioral traits such as irreversibility, existence checks, or side effects on track routing. It is too brief for a removal operation.

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

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

The description is a single sentence, 8 words, with no wasted text. It is front-loaded but could benefit from a bit more detail without becoming verbose.

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

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

Given no output schema, no annotations, and low complexity, the description fails to explain the outcome (e.g., is the send entirely removed or just detached?). It is insufficient for an agent to use correctly without additional schema info.

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

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

The schema has 0% description coverage. The description only mentions 'by its index', which vaguely refers to send_index but does not clarify source_track_index. Agent would need to infer or test.

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

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

The description clearly states the verb 'remove' and the resource 'send' with scope 'from a track by its index'. It distinguishes itself from siblings like create_send, list_sends, and set_send_volume.

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

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

The description provides no guidance on when to use this tool versus alternatives (e.g., remove_fx). It lacks context on prerequisites or when not to use it.

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

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

No annotations provided; description carries full burden. Only states 'rename a track' without disclosing that this is a mutating operation, whether it is reversible, or any side effects. For a mutation tool, this is insufficient.

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

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

Single sentence is concise but overly terse; lacks essential details. Despite brevity, it is not appropriately sized as it sacrifices completeness for minimalism.

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

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

Given no annotations, no output schema, and 2 parameters, the description is incomplete. Does not cover return value, success/failure conditions, or behavior when track_index is out of range. Agent lacks context to use tool reliably.

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

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

Schema coverage is 0% with 2 parameters (track_index, name) having no descriptions. Description adds no meaning beyond schema; does not clarify index base (0 or 1), name format restrictions, or validation. Agent must guess parameter semantics.

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

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

Description clearly states verb 'rename' and resource 'track', distinguishing it from sibling tools like 'delete_track' or 'create_track'. However, it lacks specificity on what renaming entails (e.g., does it also update internal references?).

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

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

No guidance on when to use this tool versus alternatives. No mention of prerequisites (e.g., track must exist, track_index must be valid) or consequences. Agent has to infer usage from 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 behavioral burden. It notes the LAME requirement for mp3, which is useful, but omits whether an existing file is overwritten, whether this is a long blocking operation, whether it mutates project state, and what it returns. For a write-to-disk tool with zero annotation coverage these are 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 purpose sentence comes first and the parameter notes are terse, information-dense bullets with no filler. It is slightly under-structured only in that the parameter lines aren't clearly marked as parameter documentation.

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?

Good parameter coverage, but for a rendering/mutation tool with no annotations and no output schema, the description says nothing about overwrite behavior, the returned result, failure modes, or the relationship to the sibling render tools. It is adequate but noticeably incomplete.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it gives valid values for format (with the LAME caveat), example rates for sample_rate, allowed depths for bit_depth including the 'WAV only' constraint, and channel meanings. Only output_path is unexplained, and its name and required status make it self-evident.

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 ('Render the entire project to a file'), which is unambiguous. However, it never distinguishes itself from the closely related siblings render_time_selection, render_stems, and render_regions, leaving the agent to infer the scope difference.

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 the other three render tools in the sibling list. There are no prerequisites, no exclusions, and no mention of what happens if the project is unsaved or the transport is running.

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

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

With no annotations provided, the description carries the full burden and does so well: it discloses file creation, temporary render-setting changes in dry_run, refusal to overwrite existing files, no deletion behavior, blocking until completion, and the complete/stalled/timeout statuses. The stall detection condition is also explained clearly.

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

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

The description is front-loaded with the core action and then organized around parameter names and behavioral conditions. It is dense but every sentence adds useful operational detail, and the length is justified for a six-parameter tool with no annotations.

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

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

For a tool with no annotations and no output schema, the description covers most behavioral and failure semantics thoroughly, including dry_run returns and final status values. The main gap is that the required output_directory parameter is not described, leaving the destination semantics partially implicit.

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 pattern variables and collision numbering, selected_only behavior, dry_run behavior, and both timeout-related parameters, but it never explains the required output_directory parameter.

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

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

The description gives a specific verb, resource, and scope: render each project region to its own file using project render settings. That scope implicitly distinguishes it from whole-project, stem, and time-selection renders without ambiguity.

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

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

It clearly explains when selected_only applies and what dry_run does, including the failure behavior when output files already exist. It does not explicitly name sibling alternatives such as render_project or render_stems, so selection guidance is strong but not fully comparative.

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 exist, so the description carries the full burden. It usefully discloses the solo-per-track mechanism and the file-naming convention, but does not say whether solo state is restored afterwards, whether rendering overwrites existing files, or whether the operation is realtime/long-running - significant gaps for a mutation-plus-file-write 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?

Three short sentences, front-loaded with the core behavior, then parameter semantics, then output convention - no filler whatsoever.

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 render tool with no annotations and no output schema, the description covers the essential behavior, subset selection and file naming; what is missing (solo-state restoration, per-file format details, what the call returns) is modest given the sibling render tools cover similar ground.

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 the non-obvious track_indices parameter (null = all tracks) and implicitly the output_directory via file naming, but format, bit_depth and sample_rate are only self-describing names with schema defaults and get no guidance from the 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 (render) and a specific output artifact (separate stem file per track), plus the mechanism used ('soloing each track individually'), which inherently distinguishes it from siblings like render_project, render_regions and render_time_selection.

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

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

The null-vs-list semantics for track_indices implies when to render a subset versus everything, but the description never says when to choose this tool over render_project or render_regions, nor any prerequisites (e.g. tracks must exist, project must be loaded).

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

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

No annotations are provided, so the description carries full burden. It indicates a write operation (rendering to file) but lacks details on file overwriting behavior, required permissions, or side effects. It is adequate but not thorough.

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

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

The description is a single concise sentence, but it sacrifices necessary detail for brevity. It could be more informative without being overly verbose.

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

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

Given no output schema, no annotations, and 7 parameters with 0% coverage, the description is insufficient. It does not explain return values, file formation, or that render uses project settings. For a tool with this complexity, more context is needed.

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

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

With 0% schema description coverage, the description fails to add meaning to any of the 7 parameters. It only vaguely implies 'time range' but does not explain format, sample_rate, bit_depth, channels, or output_path meaning.

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

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

The description clearly states the action 'render' and the resource 'specific time range of the project' with output 'to a file'. It effectively distinguishes from sibling tools like 'render_project' (full project) and 'render_stems'.

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

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

The description implies usage for partial renders but provides no explicit guidance on when to use this tool versus alternatives like 'render_project' or 'render_stems'. No exclusions or prerequisites are mentioned.

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

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

No annotations are provided, so the description must fully disclose behavioral traits. It only states the basic action and default path, missing details like overwriting behavior, success/failure indications, whether it modifies the undo state, or if it requires an active project. This is insufficient for a mutation tool.

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

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

The description is extremely concise with two short sentences. The first sentence immediately states the purpose, and the second provides the key default behavior. Every word earns its place.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the core functionality and default behavior. Minor gaps exist (e.g., no mention of return value or error conditions), but these are acceptable for such a straightforward 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?

The single parameter 'project_path' has no schema descriptions, but the description adds that omitting it saves to a default directory. This adds meaningful context beyond the schema, which only provides a type and title.

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

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

The description clearly states the action ('save the current project') and the default behavior when no path is given. It distinguishes from sibling tools like load_project, create_project, etc., which deal with different project 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?

The description mentions the default save location but does not provide guidance on when to use this tool versus alternatives, prerequisites (e.g., project must be open), or when not to use it. This leaves the agent without context for appropriate invocation.

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

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

The description accurately states the behavior but does not disclose side effects, such as whether playback stops or selection changes. With no annotations, the description should provide more context, though the simplicity of the action mitigates the need.

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, concise sentence front-loads the core information without any superfluous words. Every word contributes to understanding.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is largely complete. It could mention that the cursor is moved in the project timeline, but the current wording suffices for basic usage.

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

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

The schema defines 'position' as a number with no description. The description adds the unit 'in seconds', which is essential for correct usage. No further details (e.g., valid range) are provided, but the addition meaningfully improves the schema.

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

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

The description clearly states the action ('move'), resource ('edit cursor'), and unit ('in seconds'), making the purpose unambiguous. It distinguishes from sibling tools, which do not involve cursor positioning.

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

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

No guidance is provided on when to use this tool versus alternatives. Siblings like play_project or stop_transport might be relevant in some contexts, but no comparison is made.

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 exist, so the description carries the full burden. It does disclose one meaningful behavioral constraint beyond the schema — values are normalized floats in 0.0–1.0, which prevents the common misuse of passing plugin-native ranges. It says nothing about what happens on out-of-range values, invalid indices, persistence/undo, or whether the change is surgical vs. destructive.

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 filler, with the value-range constraint front-loaded and the prerequisite second. 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 four-required-parameter setter with no annotations and no output schema, the description covers the 'what value' and 'where to find params' halves but leaves index acquisition semantics unexplained. Adequate to attempt a call, but an agent could easily pass a wrong-basis track or FX index without warning.

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

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

Schema description coverage is 0%, so the description must compensate for four undocumented integers/number. It clarifies value semantics (normalized 0.0–1.0) and param_index (discoverable via get_fx_parameters), but track_index and fx_index are left unexplained — no zero-based indexing note, no pointer to list_tracks or list_track_fx.

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 ('a normalized parameter value on an FX plugin') and adds the value domain (0.0–1.0). It does not name the near-identical sibling set_master_fx_parameter, so an agent must infer that this one targets track FX rather than master FX.

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

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

Explicitly routes the agent to get_fx_parameters first to discover parameter names and indices, which is the key prerequisite for a correct call. It stops short of stating when NOT to use this tool (e.g., use set_master_fx_parameter for master-bus plugins), leaving one real ambiguity unaddressed.

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 bears full responsibility. It only states the action and value range, but does not disclose if the operation is destructive, what happens with out-of-range values, or any side effects on the plugin 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?

The description is a single sentence with 12 words, very concise. It front-loads the core action and value range. However, the brevity sacrifices necessary detail for completeness.

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

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

Given the lack of annotations and output schema, the three required parameters are fully underexplained. The description fails to guide on how to obtain fx_index and param_index, or what the tool returns. This is insufficient 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%, and the description adds no parameter-level explanation. The parameter names (fx_index, param_index, value) are not elaborated, leaving the agent to guess meanings like 'index of the FX plugin' or 'parameter index within that plugin'. The description only generalizes 'normalized parameter'.

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

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

Clearly states the verb 'set' and the resource 'master track FX plugin', with the specific constraint of normalized value range (0.0-1.0). The sibling tool 'set_fx_parameter' implies this is for master track only, providing implicit distinction.

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 only states what it does, but does not provide explicit guidance on when to use this tool versus alternatives like 'set_fx_parameter'. No when-not-to-use or context provided.

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

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

With no annotations, the description must convey behavioral traits, but it only states the action. It does not disclose what happens when volume is out of range, if the change is immediate, or any side effects. The description is too minimal for full transparency.

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

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

The description is a single, well-structured sentence of 7 words. Every word is necessary and front-loaded, with no extraneous information.

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

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

For a simple parameter setter with no output schema, the description is minimally acceptable but lacks details like valid range or relationship to other volume controls. An agent might need to infer or assume values, which could lead to errors.

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%, but the description only adds that volume is 'in dB'. No range, typical values, or constraints are provided. The parameter 'volume_db' is left largely undefined, forcing the agent to guess appropriate values.

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

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

The description 'Set the master track output volume in dB' clearly states the verb (Set), resource (master track output volume), and unit (dB). It differentiates well from siblings like set_track_volume (for non-master tracks) and set_master_fx_parameter (for FX parameters).

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

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

No guidance on when to use this tool versus alternatives like set_track_volume or set_master_fx_parameter. No prerequisites or context provided for the agent to decide appropriately.

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

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

No annotations provided, so description must carry full burden. It only states the basic operation without disclosing side effects, limits on dB range, immediate vs. queued effect, or whether the send volume is adjusted relative or absolute. Minimal behavioral context.

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

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

A single sentence that is efficient and front-loaded. Could be expanded without becoming verbose, but as is it is concise and to the point.

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 3 required parameters, no schema descriptions, no output schema, and no annotations, the description fails to provide enough context for correct invocation. Agent lacks guidance on parameter semantics and expected behavior.

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

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

Schema description coverage is 0%. Description adds meaning for volume_db (in dB) but does not explain source_track_index or send_index (e.g., indexing start at 0, how to obtain them). Inadequate compensation for missing schema descriptions.

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

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

The description 'Set the volume of a send in dB' clearly specifies the action (set), the resource (volume of a send), and the unit (dB). It distinguishes from sibling tools like set_track_volume and create_send.

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

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

No guidance on when to use this tool versus alternatives (e.g., set_track_volume, adjust_volume_automation) or prerequisites (e.g., the send must exist). Implied usage from name but no explicit 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 should disclose behavioral traits. However, it only states the basic action without mentioning any side effects, error conditions, or valid BPM ranges. This leaves an agent unaware of constraints.

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

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

The description is a single concise sentence with no wasted words. However, it could benefit from slightly more detail without becoming verbose.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is minimally adequate but lacks behavioral context like valid range or confirmation of effect. It meets the minimum but leaves gaps.

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

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

The schema coverage is 0% for the single parameter 'bpm', and the description adds no extra meaning beyond the basic type. It does not mention units, range, or typical values, failing to compensate for the lack of schema 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 clearly states the tool's purpose: setting the project tempo in BPM. It uses a specific verb-resource pair ('set the project tempo') and distinguishes itself from siblings like set_time_signature.

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

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

No guidance is provided on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description lacks context for appropriate use cases.

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?

Minimal behavioral details; no mention of side effects, permissions, or effects on existing 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?

Extremely concise, single sentence with clear examples; no wasted words.

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

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

Provides basic usage but lacks context on what changes occur (e.g., updates project metadata) or confirmation. Adequate for a simple setter.

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?

Description adds value by showing example time signature formats, but does not explain parameter constraints or ranges.

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

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

Clearly states the action and resource with example values. Does not explicitly differentiate from set_tempo, but examples make it unambiguous.

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

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

No usage context provided; no mention of when to use, alternatives, or prerequisites.

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

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

The description does not reveal behavioral details beyond the basic mutation. It omits what happens on invalid input, whether the change is reversible, or any side effects. With no annotations provided, the description carries full responsibility for disclosing behavior, which it fails to do.

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

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

The description is a single sentence that is highly concise and front-loaded with the core action, wasting no words. Every part is necessary.

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

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

The description does not state what the tool returns or what happens on success/error. Given the absence of an output schema, this information is missing. While the tool is simple, a complete description would at least hint at the result (e.g., 'returns the updated track color').

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

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

The description adds meaning to three parameters (r, g, b) by specifying their valid range (0–255). However, the track_index parameter is left unexplained, and schema coverage is 0%, so the description only partially compensates for the lack of schema descriptions.

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 precisely states the action ('Set') and resource ('track color'), and clarifies the input format with RGB value ranges. It clearly distinguishes from sibling tools like set_track_volume or set_track_pan, which serve different purposes.

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

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

No guidance is provided on when to use this tool versus alternatives, such as other track modification tools. The description does not mention prerequisites, typical use cases, or when not to use it.

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

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

With no annotations, the description must reveal behavioral traits. It only states 'Mute or unmute a track,' omitting details like whether the operation is undoable, affects playback, or triggers side effects. Minimal behavioral disclosure.

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

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

The description is concise at one sentence, but for a simple toggle tool, this is efficient. It lacks structure like bullet points, but front-loads the core action.

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

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

Given no output schema and no annotations, the description should cover return values, side effects, and safety. It does not explain what the tool returns (if anything) or whether it validates track_index. Incomplete for a mutation tool.

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

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

Schema description coverage is 0%, so the description should explain the parameters. It does not elaborate on track_index or muted. While parameter names are intuitive, the description adds no extra meaning beyond the schema itself.

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

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

The description clearly states the tool toggles track mute state, but does not distinguish from the sibling set_track_solo, which toggles solo. For an AI agent, this could cause confusion about which to use for muting vs soloing.

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 usage guidelines are provided. The description does not indicate when to use mute vs alternatives like set_track_solo, nor does it mention prerequisites (e.g., track must exist) or when not to use this tool.

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

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

With no annotations, the description carries the full burden. It discloses the pan value range but fails to mention potential side effects (e.g., overwriting automation) or whether the track must exist.

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

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

The description is a single sentence with a clear value mapping. Every word is necessary and focused, achieving maximal 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?

Given the tool's simplicity (2 params, no output schema), the description is nearly complete. It covers the pan parameter and purpose but could note the validity of track_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?

The schema has 0% description coverage, so the description must compensate. It explains the pan parameter's range but ignores track_index. This adds partial value beyond the schema.

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

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

The description clearly states the tool sets track pan, a specific resource. It defines the range of pan values (-1.0 to 1.0), distinguishing it from sibling tools like set_track_volume or set_track_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?

The description implies usage for setting static pan but lacks explicit guidance on when to use versus alternatives like add_pan_automation. No context on prerequisites or exclusions is provided.

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

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

No annotations provided, so description must carry full burden. It does not disclose side effects (e.g., affecting other tracks' solo states) or whether operation is toggle or set.

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

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

Extremely concise (4 words), but at the expense of informativeness. Could include structured details without losing conciseness.

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

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

No output schema, no parameter descriptions, zero behavioral context. Fails to provide a complete picture for the agent.

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 and no parameter info in description, the agent gets no added meaning beyond parameter names and types.

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

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

The description 'Solo or unsolo a track.' uses a specific verb (solo/unsolo) and resource (track), clearly distinguishing from sibling tools like set_track_mute or set_track_volume.

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

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

No guidance on when to use this tool versus alternatives (e.g., set_track_mute, set_track_volume). The description lacks context for selection.

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 disclose behavioral traits. It only mentions the volume range, omitting that this is a mutation operation, potential effects on automation, or permissions needed. The transparency is minimal.

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

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

The description is concise with two sentences, no extraneous words. However, it could be structured to include more essential details without losing brevity.

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

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

Given no output schema and no parameter descriptions, the description is too sparse. It does not explain return values, validation, or typical usage patterns, leaving the agent underinformed.

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 should clarify parameter meaning. It does not explain track_index (e.g., 0-based or 1-based) or volume_db (e.g., 0 dB = unity). No added value beyond the schema.

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

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

The description clearly states the action 'Set track volume' and includes the unit (dB) and range, distinguishing this tool from siblings like set_master_volume or set_send_volume. However, it could be more explicit about the target being an individual track.

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

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

No guidance is provided on when to use this tool vs alternatives (e.g., set_master_volume) or prerequisites (e.g., track must exist). The description lacks 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 full burden. It only states 'arm and start recording' without disclosing side effects, prerequisites, or whether it is destructive. Minimal behavioral context.

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

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

Two sentences totaling 11 words, no redundancy. Front-loaded the main action and followed with a necessary instruction. Efficient and structured.

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

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

Despite low complexity (single parameter, no output schema), the description omits key details: expected track state, error conditions, and what happens post-recording. Insufficient for an agent to use 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 mention the 'track_index' parameter at all. No explanation of indexing or allowed values, leaving the agent uninformed.

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

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

The description clearly states 'Arm a track and start recording,' which is a specific verb+resource action. It distinguishes from siblings like play_project or stop_transport.

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

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

The description provides a clear usage hint: 'Call stop_transport when done,' indicating a sequential action. It implies using this tool to record on a track, but lacks explicit exclusions or alternatives.

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

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

No annotations provided, so the description must carry the burden. It states the action but does not disclose idempotency, what happens if nothing is playing/recording, or whether it stops both simultaneously.

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

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

One short sentence, no wasted words, and the purpose is immediately clear.

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?

Adequate for a simple tool, but lacks detail on edge cases (e.g., calling when idle) and no output schema to clarify return 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?

No parameters exist, and schema coverage is 100%. With zero parameters, baseline is 4, and description adds no additional param info as none is needed.

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

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

The description 'Stop playback or recording.' uses a specific verb and resource, clearly distinguishing it from sibling tools like play_project and start_recording.

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

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

No explicit guidance on when to use or not use this tool, but the context and name imply its usage for stopping ongoing playback or recording. Lacks explicit alternatives or exclusions.

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