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

With no annotations, the description carries the full behavioral burden and does real work: it discloses that replace=True destroys existing clip contents and that notes beyond clip length are retained but silent until the loop is extended. These are non-obvious mutation side effects an agent would otherwise miss. It does not cover permissions or the coordinates needed to target the clip.

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 primary action, then the replace caveat, then the loop-length edge case. No filler and 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 mutation tool with no annotations and no output schema, it covers the destructive replace path and the beyond-length behavior well. However, it omits how track_index/slot_index identify the target clip, which is essential context an agent needs to invoke it correctly.

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

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

Top-level schema coverage is 0%: track_index, slot_index, and notes have no descriptions, and the description only explains replace=True. The nested Note fields carry their own schema descriptions, but the description does not compensate for the undocumented top-level parameters, leaving the clip-targeting coordinates unexplained.

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

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

States a specific verb and resource: 'Write MIDI notes into an existing clip.' The word 'existing' tells the agent a clip must already be present, implicitly distinguishing it from create_clip. It stops short of explicitly naming sibling alternatives, but the core purpose is unambiguous.

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

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

There is no explicit when-to-use guidance or comparison against siblings like create_clip, set_clip, or remove_notes. The only usage-adjacent content is the replace parameter behavior, which is a mechanic rather than a routing rule. An agent must infer the appropriate context itself.

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

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

With no annotations, the description carries the full burden, and it does well: it discloses supported formats (WAV/AIFF/FLAC), the full metric set, and interpretation thresholds (fireplace ~25-30 dB, crackle_ratio >= 4, hum > 3x local median). It omits that the operation is read-only/non-destructive and gives no performance or failure behavior, so not a full 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?

Front-loaded with the core purpose in the opening clause, then a dense but earnable list of metrics and their interpretive thresholds. It is long and abbreviation-heavy (p95-p10, p99/median), but nearly every clause adds discriminative value.

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

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

No output schema exists, so the description must describe the return values, and it does so comprehensively, including metric semantics and how to read them. The main gap is the unexplained section_seconds parameter and the absence of any note on cost/behavior for large files.

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. 'path' is self-evident, but 'section_seconds' is never explained — the phrase 'loudness per section' only indirectly implies it, with no units, default-null behavior, or effect on output documented.

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 ('analyze a WAV/AIFF/FLAC') and enumerates exactly what it measures (LUFS, peaks, crest factor, correlation, texture). The detail is enough to tell it apart from a plain level meter, but it never names or contrasts the closest sibling (measure_levels), so sibling differentiation is left implicit.

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

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

Usage is implied rather than stated: the 'texture' block is framed for Foley/ambiences and the tonal_peak note ('on music it is just a note, so ignore it there') guides context. However, there is no explicit when-to-use, when-not-to-use, or routing to alternatives such as measure_levels.

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 add real behavioral context: supported formats, that the clip lands 'unwarped (natural speed)', and that it bypasses Session. It omits error/validation behavior, permission needs, and what happens if the target track is not an audio track, leaving gaps 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?

Two tight sentences with zero filler, front-loading the core action and constraints in the first sentence and the unwarped behavior in the second. Every clause earns its place.

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

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

For a 3-param mutation tool with no annotations and no output schema, the description is fairly complete: it explains the placement path, time units, formats, and default warping behavior. Remaining gaps are the semantics of track_index and any failure conditions, which are minor given the rest of the coverage.

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

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

Schema description coverage is 0%, so the description must compensate. It gives useful semantics for `time` (beats, with bar N starting at (N-1)*4 in 4/4) and `file_path` (absolute path with accepted formats), but says nothing about `track_index` — e.g. whether it is absolute or relative to a selection.

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 (place) and resource (audio file on an Arrangement timeline), with the scope clarified as bypassing the Session slot path. It is clearly distinguishable from Session-oriented siblings like create_clip and load_audio_clip, though it never names any 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 phrase 'without going through a Session slot' implies the alternative path an agent would otherwise take, giving an implicit when-to-use signal. However, it does not name the competing tool (e.g. load_audio_clip) or state any exclusions, so the routing decision is left partly 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 exist, so the description carries the full burden. It discloses that the operation copies (a mutation) and explains the time addressing scheme with the bar/beat formula, which is genuinely useful. It says nothing about whether existing arrangement clips are overwritten, whether the operation is destructive, or what the call returns.

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

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

Two tight sentences, verb front-loaded, with the parenthetical bar-conversion formula earning its space as immediately actionable detail. No filler.

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

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

For a 3-parameter mutation tool with no annotations and no output schema, the description covers the core action and time semantics but omits overwrite behavior, ordering/quantization effects on existing arrangement clips, and the meaning of two of its three parameters. Adequate but with clear gaps.

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

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

Schema description coverage is 0% across three required parameters, so the description must compensate. It fully specifies the semantics of `time` (beats, with bar N at (N-1)*4 in 4/4) but leaves `track_index` and `slot_index` completely undefined beyond their names, which under-documents the source addressing.

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

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

The description states a precise verb and resource: 'Copy a Session clip into the Arrangement timeline.' It also disambiguates the source (Session clip) from the destination (Arrangement timeline). It does not distinguish itself from the similarly named sibling arrangement_audio_clip, which is the only thing keeping it from 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?

'Use it to lay out a full song from scenes' gives one concrete use case, so usage is implied rather than merely absent. However, it names no alternatives (create_clip, arrangement_audio_clip) and gives no when-not or prerequisite conditions, so the agent must infer 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 burden. 'List the contents' strongly implies a non-destructive read and it discloses the path grammar ('First segment is the category'), but it says nothing about what 'contents' are returned (folders vs devices) or any rate behavior. Adequate but thin for a no-annotation 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?

A single front-loaded sentence that names the action and resource, followed only by examples that earn their place. No filler.

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

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

For a one-optional-parameter read tool with no output schema, the description supplies the essential path format the agent needs to invoke it. It stops just short of describing the return contents, which would fully close the loop given 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?

Schema description coverage is 0%, so the description must compensate, and it does: the multiple example paths ('audio_effects/Delay & Loop', 'instruments/Drift') and the 'First segment is the category' rule convey hierarchy and accepted syntax beyond the bare 'Path' string typing.

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 ('List the contents of a browser folder') and reinforces scope with concrete example paths. It is clearly a browsing/listing operation distinguishable in spirit from search_browser and load_device, but it never explicitly differentiates itself from 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?

It gives path value examples but no guidance on when to use browse versus search_browser, load_device, or device_property, and no prerequisites or exclusions. The agent must infer the browsing-then-loading workflow entirely on its own.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that this is a bulk removal scoped to Arrangement and that Session clips are preserved, but says nothing about reversibility/undo, confirmation, or return behavior for an unambiguously destructive 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?

One sentence, front-loaded with the destructive action and immediately qualified by the scope limitation. No wasted words.

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

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

For a simple one-parameter destructive tool with no annotations or output schema, the description covers action and scope but omits any note on reversibility or prerequisites, leaving meaningful gaps for a destructive operation.

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

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

Schema coverage is 0% and the single parameter track_index is undocumented in both the schema and the description. The intent of the index is inferable, but the description adds no meaning such as indexing basis or whether it must exist.

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

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

The description states a specific verb+resource ('Remove every clip from a track's Arrangement timeline') and delimits scope by noting Session clips stay, which effectively distinguishes it from delete_clip and stop_track_clips without naming them.

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

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

The parenthetical scoping note implies when this is the right choice (clearing the Arrangement only), but there is no explicit when-to-use guidance or named alternative for removing a single clip versus all clips.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It discloses only that the clip is empty and what length means; it says nothing about what happens if the target slot already holds a clip, whether the clip is auto-named, what identity is returned, or any permission/error behavior for a mutation.

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

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

Two short sentences with zero filler; the core action is front-loaded and the unit clarification follows immediately. Nothing needs trimming.

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

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

For a mutation tool with no annotations, no output schema and 0% parameter documentation, the description leaves too much open: no return value, no conflict/overwrite semantics, and three of four parameters unexplained. It does not carry the load the structured fields leave behind.

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 none of the four parameters are described, yet the description compensates for only one: the 'length in beats (4 = one 4/4 bar)' note is genuinely useful. track_index, slot_index and name remain completely undefined 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 ('Create an empty MIDI clip') plus the exact location ('in a Session View slot'), which cleanly separates it from load_audio_clip, add_notes, delete_clip and the other clip siblings in the same namespace.

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

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

There is no when-to-use, when-not-to-use, or alternative guidance. An agent must infer on its own that this is the from-scratch path versus load_audio_clip (audio) or add_notes (populating notes into an existing clip).

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the default append behavior (index=-1) but says nothing about what a newly created scene looks like, whether the name is auto-generated when null, or what happens if index is out of range.

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

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

Two short sentences with the core action front-loaded and no filler. It is appropriately sized, though the brevity comes partly from what it omits rather than pure efficiency.

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

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

For a 2-parameter mutation tool with no annotations and no output schema, the description leaves significant gaps: the meaning of a null name, the return value, and error/edge behavior for index are all unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully explains the index parameter's default sentinel (-1 appends at bottom), which the schema only states as a bare default. However, it says nothing about the name parameter's null default or auto-naming behavior.

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

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

States a specific verb and resource ('Add a scene'), and the parenthetical '(row)' clarifies the domain concept of a scene in this toolset. This distinguishes it from rename_scene, delete_scene, duplicate_scene, and fire_scene without naming them.

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

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

No guidance on when to create a scene versus using duplicate_scene, nor any prerequisites (e.g., whether the session must be in a particular view). The agent must infer usage entirely from the name.

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

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

No annotations, so the description carries the full burden. It discloses only that index=-1 appends at the end, omitting side effects, permissions, return values, and behavior for invalid indices or name defaults. This is thin 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?

Two short sentences, front-loaded with the core action and followed by a relevant default caveat. 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?

Given no annotations, no output schema, and 0% parameter description coverage, the description is too sparse. It omits return information, error conditions, and how the new track interacts with existing tracks.

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

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

Schema coverage is 0%, so the description must compensate. It does clarify type values (midi/audio/return) and the index=-1 default behavior, but leaves name entirely unexplained. Partial compensation warrants a mid-range score.

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 a specific verb and resource: create a track of three possible types. It does not explicitly differentiate from siblings like duplicate_track or create_scene, but the resource 'track' is unambiguous.

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

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

No when-to-use or when-not-to-use guidance. The index=-1 note is a usage hint but not a condition for choosing this tool over alternatives such as duplicate_track.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Delete' implies a destructive, possibly irreversible mutation, but the description says nothing about undo, whether deletion of an empty slot errors, or what happens to the underlying audio. Only the barest destructive intent is conveyed.

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

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

The single sentence is front-loaded and waste-free, but brevity here reflects under-specification rather than disciplined conciseness for a destructive two-parameter 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?

With no annotations, no output schema, and 0% parameter description coverage, the definition is too thin for a destructive mutation tool. An agent lacks the information to call it safely or 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, and it largely does not. It hints at the slot_index ('in a slot') but never mentions track_index or explains indexing conventions (zero-based?), leaving one required parameter wholly undocumented.

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

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

The description names a specific verb (Delete) and resource (the clip in a slot), which lets an agent distinguish it from delete_track, delete_scene, and delete_device. However, it offers no explicit differentiation from sibling deletion tools or clarification of what a 'slot' is.

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 alternatives such as delete_scene, delete_track, or set_clip. The agent must infer that this removes a clip from a session slot, with no prerequisites or exclusions stated.

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

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

With no annotations, the description carries the full behavioral burden but supplies almost none of it: it omits that deletion is destructive/irreversible, whether the underlying device is unloaded or merely detached, and whether indices shift after removal. 'Remove' implies mutation but nothing about side effects or error conditions is disclosed.

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

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

A single short, front-loaded sentence with zero filler. It is efficient, though the brevity is achieved by omission rather than by careful compression.

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

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

For a destructive mutation with no annotations, no output schema, and zero parameter documentation, the definition is materially incomplete. An agent cannot determine indexing conventions, the meaning of 'kind', or what happens to the surrounding chain after 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 should compensate, yet it explains none of the three parameters. Worse, 'a track's chain' implies a track-only scope while the 'kind' enum also permits 'return' and 'master', leaving that parameter's meaning and the index base for track_index/device_index 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 (Remove) and resource (a device from a track's chain), so an agent can tell it apart from create/load devices. However, it does nothing to distinguish itself from near-siblings like delete_track, move_device, or delete_clip beyond the noun, and the destination scope ('chain') is stated without explaining the track/return/master dimension.

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

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

No when-to-use guidance, no prerequisites, and no reference to alternatives such as move_device or delete_track. The agent must infer that this is the removal counterpart to load_device purely from the name.

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

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

No annotations are provided, so the description carries full behavioral disclosure. It usefully states that clips are also deleted, which is important cascade information beyond the schema. However, it omits permission requirements, irreversibility, and whether confirmation is needed for a destructive 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 front-loaded sentence with no filler. It efficiently conveys the core action and the cascade effect, so every part 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 destructive, unannotated tool with a required parameter and no output schema, the description is too sparse. It does not explain how to specify the scene_index or cover the risks of an irreversible deletion, leaving an agent without essential context to call it correctly and safely.

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

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

Schema description coverage is 0% and the description says nothing about scene_index—not its meaning, expected range, whether it is zero-based, or how to identify the target scene. The schema only provides the parameter name and integer type, so the description fails to compensate for the documentation gap.

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

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

The description states a specific verb and resource: 'Delete a scene row and its clips.' It is clear enough to distinguish from siblings like delete_clip and delete_track by naming the scene row and the cascade to its clips. However, it does not explicitly contrast with those siblings, so it falls short of the highest clarity tier.

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

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

The description offers no guidance on when to use this tool versus alternatives such as delete_clip or duplicate_scene. Usage is only implied by the tool name and the word 'Delete.' There are no exclusions, prerequisites, or conditions 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 carries the full behavioral burden and largely fails it. For a destructive, likely irreversible operation it says nothing about consequences (e.g. clips/automation on the track being lost), permission requirements, undo behavior, or what happens if the index is invalid. Only the track/return distinction adds any behavioral information.

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

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

A single short sentence with no filler and the verb front-loaded. It is efficient, though the brevity veers toward under-specification for a destructive 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?

With no annotations, no output schema, and 0% parameter documentation, the description leaves critical gaps for a destructive operation: irreversibility, side effects on contained clips, and index semantics. It is not sufficient on its own for an agent to call this safely.

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

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

Schema description coverage is 0%, so the description must compensate and does so only partially. It clarifies that the target may be a regular track or a return track (corresponding to the 'kind' enum), but gives no meaning for 'track_index' — whether it is zero-based, positional, or how returns are indexed.

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

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

The description states a specific verb+resource ('Delete a track or return track'), and the mention of 'return track' hints at the kind parameter's scope. It does not differentiate this tool from its deletion siblings (delete_clip, delete_device, delete_scene), but the resource is unambiguous.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling tools. The agent must infer that this is the correct tool for removing a track rather than a clip or device.

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

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

With no annotations, the description carries full behavioral burden. It usefully discloses the read-vs-write trigger (omitting value) and gives a value-semantics example, but says nothing about permissions, side effects of setting, chaining behavior, or error cases for a 7-parameter 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?

A single compact sentence with the read/set distinction front-loaded and the illustrative example trailing. Efficient, though the parenthetical grouping makes the mode semantics slightly harder to parse than it needs to be.

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

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

For a 7-parameter mutation tool with no annotations and no output schema, the description is far too thin: it does not cover most parameters, chain/chain-device nesting, or the effect of setting a property. An agent would be guessing on the majority of the call surface.

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 clarifies the value parameter (omit for read) and one enum example under name ('voices'); it leaves kind, track_index, device_index, chain, and chain_device entirely unexplained.

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

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

The description states a specific verb pair ("Read ... or set") and a clearly bounded resource ("a device property that is not an automatable parameter"), which implicitly separates it from the sibling parameter tools. However, it never names get_device_parameters/set_device_parameters directly, so the agent must infer the boundary itself.

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

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

It gives a usable mode switch ("value omitted" = read, provide value = set) and a concrete scenario (Simpler 'voices', 1 = mono for 808 glide). It lacks explicit exclusions or a named alternative for automatable parameters, so the routing is clear-context rather than fully specified.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the destructive trait that the target slot is overwritten, which an agent needs to know before calling. However, it says nothing about the source clip's fate, permission/auth needs, or response behavior.

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

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

Two short, front-loaded sentences with no filler; the action and its key side effect lead. Slightly terse for the amount of undocumented behavior, but 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 mutation tool with no annotations, no output schema, and 4 fully undocumented required parameters, the description covers the essential overwrite warning but omits source-clip behavior, indexing semantics, and error conditions. Adequate minimum but with clear gaps.

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

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

Schema coverage is 0% and all four parameters (track_index, slot_index, target_track, target_slot) have only generic titles. The description's source/destination framing loosely implies two coordinate pairs but never explains which parameter is which (e.g. slot_index vs target_slot) or the units/indexing, so it fails to compensate for the coverage gap.

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

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

States a specific verb (copy/duplicate) and resource (clip) plus the destination (another slot), which cleanly separates it from create_clip, delete_clip, set_clip, and duplicate_scene/duplicate_track. It stops short of explicitly naming or contrasting itself against those siblings.

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

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

'Good for making variations' implies a use case, but there is no explicit when-to-use vs alternatives guidance, no prerequisites, and no statement of when this should be avoided versus e.g. create_clip or set_clip. Usage is only implied.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that all clips are copied and the duplicate lands immediately below, but it does not cover side effects such as selection changes, undo behavior, naming, or permissions.

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

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

One compact sentence, front-loaded with the verb and resource, with a second clause adding placement detail. 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 one-parameter mutation tool with no annotations and no output schema, the definition omits parameter meaning and usage context. It states the basic effect but is not complete enough to invoke correctly without inspecting the 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?

Schema description coverage is 0%, and the single required parameter scene_index is undocumented in the schema. The description never explains which scene is duplicated or how scene_index is interpreted, so it does not compensate for the coverage gap.

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

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

States the specific verb 'Duplicate' and resource 'scene', and adds that all clips are included and where the copy lands. It does not explicitly distinguish itself from create_scene or duplicate_clip, so sibling differentiation is only implicit.

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

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

No when-to-use guidance, prerequisites, or alternatives are provided. The description implies copying an existing scene but does not say when to choose this over create_scene or duplicate_clip.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose two non-obvious traits: devices and clips are copied along with the track, and the copy is inserted directly after the original (no ordering ambiguity). It does not say whether routing, color, or automation carry over, whether the source is left untouched, or that the operation is additive rather than 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?

One front-loaded sentence with the verb first and no filler; the parenthetical and trailing clause both carry information. Nothing to trim.

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

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

For a one-parameter mutation tool with no annotations and no output schema, the description conveys the essential outcome (a new track appears right after the source, with its devices and clips) so no return value explanation is needed. The only real gap is the indexing convention for track_index and the effect on the current selection.

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

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

The single parameter 'track_index' has 0% schema description coverage and the description adds nothing about it. The critical ambiguity is whether the index is 0-based or 1-based and how it maps to the visible track list, which the description never resolves.

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

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

States a specific verb ('Duplicate') and resource ('a track'), and adds real scope detail: the copy includes devices and clips, and lands immediately after the source. The noun 'track' inherently separates it from duplicate_clip/duplicate_scene, but the description never explicitly contrasts with those siblings, so it falls short of a 5.

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

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

Usage is only implied by the name and action; there is no when-to-use/when-not framing and no pointers to alternatives such as create_track, set_track, or duplicate_clip. For a common operation with many adjacent siblings this is adequate but leaves routing to the agent.

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

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

With no annotations, the description carries the behavioral burden, and it does disclose one meaningful trait: playback begins on the next launch-quantization boundary rather than immediately. However, it omits other relevant behavior such as whether the clip must already exist, what happens with an empty slot, or any permission requirements.

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

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

A single short sentence, front-loaded with the action and followed by the only non-obvious nuance. No filler or redundancy.

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

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

For a two-parameter trigger tool with no output schema this is minimally viable: the action and timing are covered, but parameter meaning and edge cases (missing clip, empty slot) are absent, leaving gaps an agent would need to guess at.

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 says nothing about track_index or slot_index, so neither parameter's meaning (e.g., whether indices are zero-based, or how they map to tracks/scenes) is explained anywhere. The description fails to compensate for the coverage gap.

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

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

"Launch a clip" states a specific verb and resource, and the parenthetical clarifies the timing semantics. It is readily distinguishable from fire_scene, stop_track_clips, and create_clip, though it does not explicitly name any sibling.

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

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

The description gives no when-to-use or when-not-to-use guidance and never mentions alternatives such as fire_scene or stop_track_clips. An agent must infer that firing is the way to trigger playback from the verb 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals only that clips are launched, but says nothing about playback timing, transport requirements, whether it affects all clips in the scene, or what side effects occur. The minimal action statement is not enough for a mutation-like 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?

A single, front-loaded sentence with no wasted words. It is appropriately sized for the tool's apparent simplicity.

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

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

Given no annotations, no output schema, and 0% schema description coverage, the one-sentence description is not complete enough. It omits parameter meaning, when to use the tool, and any behavioral or return expectations.

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

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

schema description coverage is 0% and the single required parameter scene_index has no description in the schema. The tool description does not explain what scene_index means, its expected range, indexing basis, or how it relates to the scene row, leaving the parameter undocumented.

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

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

The description states a specific verb ('Launch') and resource ('every clip in a scene row'), which distinguishes it from the sibling fire_clip (single clip). It does not explicitly name or contrast with alternatives, but the scope is clear enough for an agent to identify the operation.

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

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

The description gives no guidance on when to use this tool versus fire_clip, stop_track_clips, or other playback-related siblings. It only states the action without context, exclusions, or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden. 'List ... already on' implies a read-only operation and it usefully discloses the coordinate unit (beats), but it omits error behavior for an invalid track and any return-shape hints, so disclosure is only partial.

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

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

A single front-loaded sentence with the resource stated first and the unit qualifier last; nothing is wasted. It is efficient though perhaps too terse to be maximally helpful.

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

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

For a read tool with no output schema, no annotations, and an undocumented required parameter, the description is thin. It does not indicate what the returned clips contain or how track_index must be supplied.

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

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

Schema coverage is 0% and the single parameter (track_index) is never explained. 'On a track's' only loosely ties it to a track; nothing addresses index origin, zero/one-based indexing, or validity, so the description fails to compensate for the coverage gap.

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

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

States a clear verb ('List') and resource ('clips on a track's Arrangement timeline'), which distinguishes it from session-clip siblings like fire_clip and create_clip. It does not, however, explicitly name a sibling or contrast condition.

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

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

There is no when-to-use guidance, no exclusions, and no pointer to alternatives such as get_notes or arrangement_audio_clip. Usage is only implied by the Arrangement-timeline scoping.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the read-only nature implicitly through 'List' plus the returned fields, but says nothing about permissions, whether values are refreshed live, or side effects, so coverage of traits beyond the return shape is thin.

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

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

Two tight sentences, front-loaded with what the tool returns and followed by the only non-obvious input rule. No filler or repetition of structured data.

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 documents the return shape (raw vs displayed value, min/max, switch options), which is exactly what is needed for a getter. The remaining gap is the unexplained indexing parameters, which keeps it from being fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain chain and chain_device (and ties them to the nested-rack case), but track_index, device_index, and the kind enum remain undocumented in both schema and description, leaving 3 of 5 parameters unclarified.

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

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

The description names a specific verb and resource ('List every parameter of a device') and enumerates exactly what is returned (index, name, raw value, min, max, displayed value, switch options). The read/list framing cleanly distinguishes it from the write sibling set_device_parameters without needing to open either schema.

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

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

It supplies one concrete usage cue: for a device nested in a rack, pass chain + chain_device and see get_rack. That is a useful conditional, but it never states when to use this tool versus set_device_parameters/set_parameter_real, so the when-not guidance is left 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 are provided, so the description carries the full behavioral burden. It hints at read-only behavior via 'List' and discloses the output shape, but does not state prerequisites, what happens when the device is not a Drum Rack, or error/failure 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?

A single front-loaded sentence with zero waste; the parenthetical efficiently conveys the return mapping.

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

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

For a 3-parameter tool with no annotations and no output schema, the description is too thin. It covers the return concept but omits parameter meaning, preconditions, and usage context.

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

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

Schema coverage is 0% and the description never mentions track_index, device_index, or kind. With three undocumented parameters and zero compensation in the description, an agent cannot know how to target the correct track, device, or kind.

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 ('List') and resource ('filled pads of a Drum Rack') and even clarifies the return shape (MIDI note -> sample name). It does not distinguish itself from device-oriented siblings like get_device_parameters or get_rack, but the core purpose is unambiguous.

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

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

No when-to-use guidance, no prerequisites (e.g. a Drum Rack must be loaded on the target device), and no alternatives named. The agent must infer usage entirely from the name and one-line description.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Read' implies a safe, non-destructive operation and 'plus clip info' hints at the return payload, but there is no mention of error conditions (missing clip/slot), permissions, or whether the read is exhaustive for the clip. Most behavioral context is left unstated.

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

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

A single efficient sentence with the core action front-loaded. Nothing is wasted, though it is arguably too terse given the undocumented parameters.

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

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

For a read tool with no annotations, no output schema, and two fully undocumented required parameters, the description is too thin. It gestures at return contents ('plus clip info') but leaves both the addressing parameters and the failure behavior unspecified.

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 never mentions track_index or slot_index, the two required parameters. An agent must infer that these identify the target clip from context alone; the description does not compensate for the schema gap.

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

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

States a specific verb (read) and resource (notes of a MIDI clip), which is clear and unambiguous. The parenthetical '(e.g. something the user played)' adds a helpful mental model. It does not explicitly differentiate from siblings like add_notes or remove_notes, though the read verb implies the 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?

No guidance on when to use this versus alternatives, nor any prerequisites such as the clip needing to exist. The only hint is '(e.g. something the user played)', which describes a source scenario but is not an actionable usage rule.

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. 'Show' implies a read-only operation and it discloses the returned content (chains and devices), but it omits permissions, error behavior, pagination, or output structure details.

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

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

The definition is a single, front-loaded sentence with no wasted words. The parenthetical adds useful context about rack types without bloating the description, though it slightly interrupts the main 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?

There is no output schema and no annotations, and the input schema has 0% description coverage. The description gives only a high-level purpose and does not explain parameters, return format, or prerequisites, leaving significant gaps for an agent 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% for all three parameters (kind, track_index, device_index). The description adds no parameter meaning, such as what the indices refer to or how the 'kind' enum changes behavior, so it fails to compensate for the undocumented schema.

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

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

The description states a specific verb ('Show') and resource ('chains of a rack ... and the devices inside each'), clearly explaining what the tool retrieves. It also gives a purpose ('to edit parameters the macros hide'), which implicitly distinguishes it from generic device-parameter tools, though it does not name a sibling alternative.

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

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

It provides a clear usage context: use this to see inside racks and reach parameters that macros hide. There are no explicit exclusions or named alternatives, but the intended scenario is clear enough for an agent to select it 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, so the description carries full behavioral burden. It implies a read (nothing about mutation, permissions, defaults, or behavior for non-'track' kinds) and only hints at output shape via '(by display name)'. That single phrase is the only extra behavioral context beyond the name.

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 resource and scope front-loaded and no filler. Appropriate size, though it is sized for a much simpler tool than the schema implies.

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

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

With no annotations, no output schema, and 0% parameter coverage, the description is too thin: it does not explain the kind enum, index semantics, or the return shape for a tool whose output is a routing list.

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 never mentions the 'kind' parameter (track/return/master) or how track_index is interpreted, leaving both parameters unexplained beyond the generic word '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?

States a specific verb-resource ('routings of a track') and narrows scope to current and available input/output routings. It does not differentiate itself from the sibling set_routing, which an agent would have to infer is the write counterpart.

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

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

No statement of when to use this versus set_routing or get_track_info, and no prerequisites. The agent gets no routing guidance beyond the description of what is fetched.

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

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

With no annotations and no output schema, the description carries the full behavioral burden, and it does the most important part well by enumerating the return payload (tracks with devices and clips by slot, return tracks, master, scenes, selection). 'Snapshot' clearly implies a read-only operation, though it says nothing about payload size or performance for large sets.

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 tightly-packed sentence that front-loads the resource ('Snapshot of the Live set') before the itemized contents. Every listed element is meaningful content rather than filler, though the dense enumeration is slightly hard to scan.

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

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

For a zero-parameter, read-only tool with no annotations or output schema, the description is nearly self-sufficient: it tells the agent exactly what comes back. The remaining gap is routing guidance against the numerous get_* siblings and any note about response size.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is no parameter surface for the description to explain, and nothing is missing.

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

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

States a specific verb+resource ('Snapshot of the Live set') and enumerates exactly what the snapshot contains (tempo, tracks, devices, clips, return tracks, master, scenes, selection). This distinguishes it implicitly from narrower siblings like get_track_info or get_arrangement_clips, but never names them explicitly, so differentiation is left to inference.

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

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

Usage is only implied: a full-session snapshot is self-evidently the 'get everything' call. There is no explicit guidance on when to prefer this over the many narrower get_* siblings (get_track_info, get_device_parameters, get_routing), and no stated exclusions or prerequisites.

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

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

With no annotations, the description carries the full burden, but it does disclose the expected response contents (mixer, clips, device list with indexes), which is valuable given there is no output schema. It does not describe error behavior for invalid indexes or whether it requires the track to already exist.

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

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

A single tight sentence that is front-loaded with the primary purpose and the returned payload. Nothing is wasted, though there's little content to structure.

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

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

For a simple read tool with no annotations and no output schema, listing the returned fields is helpful, but the two undocumented parameters (especially the kind selector) leave the definition short of complete.

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

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

Schema description coverage is 0%, so the description must compensate, and it does not: track_index and the kind enum (track/return/master) are unexplained. Notably, kind changes what the index refers to, yet the description speaks only of "one track", leaving a meaningful semantic gap.

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

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

States a specific verb+resource ("Detailed info for one track") and enumerates the payload (mixer, clips, device list with indexes), which helps distinguish it from generic readers like get_session_info or get_routing. It lacks any naming of the closest alternatives, but the intent is clear.

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

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

No when-to-use, when-not-to-use, or alternative routing is given. An agent must infer that this is a read of a single track versus get_session_info, get_routing, or the get_* clip tools, with no stated conditions to guide the choice.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It discloses supported formats and that the destination must be empty, but omits side effects, error behavior when the slot is occupied, permissions, and whether session state is otherwise affected.

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 front-loaded sentence: verb, resource, path format, and target slot are delivered without filler. It is appropriately sized for the operation.

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

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

For a simple load operation, the description covers purpose and file path well. However, with three required parameters undocumented in the schema and no annotations or output schema, it leaves index semantics and error/side-effect behavior unclear.

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

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

Schema description coverage is 0%, so the description must explain all three parameters. It clarifies file_path as an absolute path and lists formats, and implies track_index/slot_index target an audio track and Session View slot, but gives no index base, valid ranges, or precise semantics for the two integer parameters.

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

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

Specific verb 'Load' plus resource 'audio file' and a precise target: an empty Session View slot on an audio track. Supported formats and absolute-path requirement further disambiguate it from siblings like arrangement_audio_clip and load_device.

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

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

States the context clearly: Session View, audio track, empty slot. It does not name alternatives or when-not-to-use cases, such as arrangement_audio_clip for arrangement placement or create_clip for MIDI, so it lacks explicit 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 are provided, so the description carries the full behavioral burden. It usefully discloses the append-to-chain semantics and the recommended follow-up call, but says nothing about permissions, what happens if both path and query are given, or error behavior for an invalid path.

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

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

Three tight sentences, front-loaded with the action and placement behavior, then the two input strategies, then the follow-up step. No wasted text.

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

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

With no annotations and no output schema, the description still covers the mutation, the placement, the input source, and the post-call needed to find the new device index. Missing only edge-case behavior and documentation of kind/category.

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 all five parameters. It adds real meaning for path (source is browse/search_browser) and query (example values like 'Reverb', 'Drift'), but leaves kind and category — the latter an 11-value enum — completely unexplained.

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

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

States a specific verb (load) and resource (instrument/effect/kit/preset) plus the target (track) and the placement behavior (appended to its chain). This clearly distinguishes it from create_track, though it does not explicitly name sibling 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?

Gives concrete guidance: supply an exact browser path obtained from browse/search_browser, or a query name, and call get_track_info afterward to resolve the new device's index. It lacks explicit when-not-to-use cases or precedence rules when both path and query are supplied.

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

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

With no annotations, the description carries the burden and does well: it discloses that this is a live polling operation requiring playback, and it explains the meter scale including the dB conversion (0.917 = -0.3 dBFS). It stops short of stating whether the call blocks for the poll duration or how the per-track data is structured, but the temporal behavior is well conveyed.

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

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

Front-loaded with the core action and scope, then a useful parenthetical on scale semantics and prerequisites. Slightly dense but every sentence serves a 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?

No output schema exists, so the description correctly specifies what is returned (peak and average per track/return/master) plus scale interpretation. Adequate for a live measurement tool, though blocking/latency behavior remains 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 coverage is 0% for the single 'seconds' parameter, so the description must compensate. 'Poll ... while the set plays' implies a measurement window, but the description never explicitly states that 'seconds' sets the polling duration. Marginal value added over the bare schema.

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

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

States a specific verb (poll the output meters) and the exact resource returned (peak and average level per track, return, and master). This is clearly distinguishable from siblings like get_track_info or analyze_audio, which don't measure live output levels.

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 a clear prerequisite ('Start playback first') and a concrete use case ('balance and catch clipping'). It doesn't explicitly name an alternative tool or when NOT to use it, but the context 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?

With no annotations, the description carries the full behavioral burden but only discloses the reordering effect. It says nothing about permissions, how indices shift for other devices after a move, out-of-range behavior, or whether the move is reversible. For a mutation tool this is a significant gap.

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

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

A single compact sentence with the core action front-loaded and the load_device contrast and example following efficiently. No wasted words, though it could have spent a few more tokens on parameters.

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

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

For a three-required-parameter mutation with zero annotation coverage, 0% schema description coverage, and no output schema, one sentence is insufficient. An agent lacks the parameter indexing semantics needed to call it correctly across track/return/master kinds.

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

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

Schema description coverage is 0%, so the schema provides no help beyond names and types. The description never explains track_index, device_index, new_index, or the kind enum's role, only implying that new_index is the target position via the example. It does not compensate for the coverage gap.

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

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

Specific verb+resource: 'Reorder a device in its chain' clearly states the action and target, and the parenthetical contrast with load_device distinguishes it from a nearby sibling. It does not explicitly name other siblings like set_chain, but the core purpose is unambiguous.

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

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

The description explains when this tool is needed: load_device always appends at the end, so use move_device to reposition. The EQ-before-Limiter example makes the use case concrete. It stops short of stating exclusions or the full set of alternatives, so it is strong but not exhaustive.

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

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

No annotations are provided, so the description carries the full disclosure burden. It usefully explains non-obvious direction semantics ('zoom left' = zoom out in time, 'scroll left' = toward bar 1) and gives a rough scale (~3 steps fit a 64-bar song). It leaves the modifier parameter, other views, and any side effects or reversibility unaddressed.

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

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

Two tight sentences, front-loaded with the core action and followed by the clarifying example. No padding, though the wording is slightly convoluted.

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 5 parameters at 0% schema coverage, no annotations, and no output schema, the description only explains one parameter's semantics in one view. An agent would have to guess the effect of 'modifier', the meaning of 'steps' numerically, and behavior in views other than the Arranger.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate and largely does not. It clarifies 'direction' for zoom/scroll in the Arranger and hints at 'steps' magnitude, but 'view', 'modifier', and the action enum's behavior remain undefined 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 pair (zoom/scroll) and resource (view), and the arrow-key analogy makes the intent immediately clear. It is distinguishable from siblings like show_view, though the description never names an alternative explicitly.

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

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

The arrow-key analogy implies when this is used (navigating the Arranger viewport), and the Arranger example gives concrete context. However, there is no guidance on when to prefer this over show_view, nor on how action/direction/modifier should be combined.

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. The wording strongly implies a safe, read-only diagnostic and identifies one returned value, but it does not explicitly confirm side effects, permissions, or response format.

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 compact sentence with no wasted words. It is front-loaded with the action and outcome.

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

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

For a zero-parameter health-check tool, the description is nearly complete: it states what is checked and one key result. With no output schema, it could specify the exact return shape, but the missing detail is minor.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed because the input schema is an empty object.

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

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

The description names a clear verb and resource: it checks whether the bridge is alive and reports Live's version. It is specific enough for an agent to understand the tool's core function, but it does not explicitly distinguish itself from siblings such as get_session_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?

The description implies a health-check or connectivity use case, but it does not state when to use this tool versus alternatives like get_session_info. No prerequisites, exclusions, or routing guidance are provided.

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

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

No annotations are provided, so the description carries the full burden. 'Quantize ... notes' implies irreversible mutation of note timing, but the description never discloses that it alters existing note positions destructively, whether the change is undoable, or permission requirements.

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

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

Two tight sentences with the core purpose front-loaded and the parameter note appended; no filler words. Brevity works against completeness elsewhere, but the sentences present do earn their 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 four-parameter, zero-coverage mutation tool with no annotations and no output schema, the description is too sparse: it never defines grid values, the two required indices, or the effect on existing note data. Only the amount semantics are covered.

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

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

Schema description coverage is 0%, so the description must compensate. It explains only 'amount 0-1 (1 = hard quantize)', adding real value for one of four parameters, while grid (despite a meaningful enum), track_index, and slot_index are left entirely unexplained in both description and 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 (quantize) and an unambiguous resource (a clip's notes), which no sibling tool duplicates, so an agent can identify it immediately. It does not name a contrasting sibling, but none competes for this operation.

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

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

There is no guidance on when to use this versus other clip-edit tools (set_clip, add_notes, set_clip_automation), nor any prerequisites or exclusions. The use case is inferable from the verb but never stated.

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

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

With no annotations, the description carries the full behavioral burden. 'Hot-reload' usefully implies no full restart, but it says nothing about side effects on running state, what happens if the source file has errors, required permissions, or whether session data is preserved.

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

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

A single front-loaded sentence that states the action, target, and precondition with no waste.

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

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

For a simple zero-param operation the description is nearly sufficient, but with no annotations and no output schema it leaves out failure behavior and any effect on the currently running Live session.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; the schema is trivially complete and the baseline for a parameterless tool is 4.

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 ('Hot-reload') and resource ('the Remote Script inside Live') plus a trigger condition. It is clearly distinct from every sibling tool, none of which touch the Remote Script, though it does not explicitly name that differentiation.

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

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

It gives a clear trigger context — 'after its source file was updated' — which tells the agent when this tool applies. It does not spell out when NOT to use it or name an alternative, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that deletion is destructive and that omitting the window deletes all notes in the clip, but it says nothing about permanence, permissions, side effects, or whether the deletion can be undone.

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

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

A single front-loaded sentence with no filler. The purpose and the important default behavior are stated immediately, and every phrase 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 six-parameter destructive tool with no annotations, no output schema, and no schema descriptions, the definition is far too thin. It omits required track/slot context, parameter mappings, and any behavioral detail an agent needs to invoke it safely.

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

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

Schema description coverage is 0% across six parameters. The description implies a pitch/time window that maps conceptually to four optional parameters, but it does not name any parameter and never mentions the required track_index and slot_index 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?

States a clear verb and resource: 'Delete notes' inside 'a pitch/time window'. This distinguishes it from add_notes and get_notes, but it does not explicitly name or contrast with any sibling tool.

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

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

The description gives the default scope ('the whole clip') but no when-to-use guidance, no prerequisites, and no alternatives. It does not say when to prefer this over deleting a clip or using another notes 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?

No annotations are provided, so the description carries the full burden. It implies a mutation but says nothing about whether the scene must already exist, whether the index is zero- or one-based, or what the result is. For a state-changing tool this is a meaningful gap.

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

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

One short sentence, front-loaded with the verb and resource. The parenthetical examples add minor value without bloat, though they could have been spent on parameter semantics instead.

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

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

For a trivial two-parameter tool this is close to adequate, but with zero schema coverage, no annotations, and no output schema, the indexing semantics and failure behavior are undocumented. An agent could call it, but might pass the wrong scene_index.

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

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

Schema description coverage is 0%, so the description must compensate, but it does not. It clarifies neither the scene_index convention (0-based? by position?) nor that name is the new label, though the example names hint at typical 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?

States a specific verb (Rename) and resource (scene), which cleanly distinguishes it from siblings like create_scene, delete_scene, duplicate_scene, and fire_scene. No explicit sibling routing, but the purpose is unambiguous.

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

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

There is no guidance on when to use this versus duplicate_scene or create_scene, no prerequisites, and no indication of what happens on failure. The examples of names are illustrative, not usage guidance.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses blocking semantics for wait_seconds (a real behavioral trait beyond the schema), but says nothing about the return format, terminal states, or whether the render continues in the background — leaving significant behavioral gaps for an un-annotated 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?

A single tight sentence with the purpose front-loaded and the parameter note trailing. No wasted words, though the clipped phrasing ('up to that long') is slightly terse.

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

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

With no annotations and no output schema, the description is short on essentials for a status tool: it doesn't describe what the progress report contains or what states a caller should test for. Given the low structured-data richness, more disclosure 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?

Schema coverage is 0% for the single parameter, so the description must compensate. It does explain that wait_seconds causes the call to block up to that duration, which is meaningful beyond the bare 'number' schema, but it omits the unit, default-no-wait behavior, and any upper bound.

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 the resource and concept clearly: 'Progress of the current render'. An agent can tell it reports render status, and it is distinguishable from the sibling render_to_wav (which initiates a render). It lacks an explicit verb but the noun phrase is unambiguous.

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

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

No guidance on when to call this versus alternatives, no mention that it follows render_to_wav, and no polling/state-transition advice. The only usage information is an incidental note about wait_seconds.

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

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

With no annotations, the description carries the full behavioral burden and does so richly: real-time recording cost ('takes as long as the music plays'), synchronous vs async return behavior, the save requirement and re-save side effect, solo/mute obedience, the 16-track stem limit, and the analysis attached to results. This is exactly the runtime context an agent needs.

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 purpose and dense with substantive detail; almost every clause adds operational information. The single long paragraph mixes defaults, timing, and result semantics, which slightly hurts scannability, but there is little wasted text.

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

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

Given no output schema and no annotations, the description covers mechanism, timing, side effects, and result contents (LUFS, true peak, bands, per-section loudness, stem level summary). It is nearly complete, with the main omissions being the unexplained start_bar/output_dir/section_bars parameters.

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

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

Schema coverage is 0%, so the description must compensate, and it explains several params well: stems (names or ['all']), end_bar (None renders to last clip), tail_bars (keeps reverb/delay tails), wait_seconds (returns immediately unless > 0), and filename via the stems-path convention. However, start_bar, output_dir, and section_bars are never explained, leaving real gaps.

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 Arrangement to WAV') and immediately explains the mechanism ('by recording in real time (Live has no export API)'). The default behavior (master mix to one file on Desktop) and the stems variant are distinguishable from siblings, and it explicitly references the companion render_status 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?

Gives clear context for the two main modes (master vs stems) and when to set wait_seconds > 0 versus polling render_status. It also notes the saved-set prerequisite. It stops short of naming explicit when-not-to-use conditions or alternative export paths, so it falls just short of a 5.

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

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

No annotations are provided, so the description must carry the behavioral burden. It implies a read-only lookup by describing name-matching scope, but says nothing about pagination, result limits, ordering, or return format for a search that can obviously return many items.

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

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

Two tight sentences with the core action front-loaded and the scope fallback second. No filler, though the category clause could have been tightened into an explicit default note.

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

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

For a 3-parameter tool with no annotations, no output schema, and 0% schema coverage, the description is only minimally sufficient. It omits max_results behavior and result format, which an agent would need to invoke and interpret it reliably.

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

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

Schema description coverage is 0%, so the description must compensate. It explains `query` (name containment) and partially explains `category` through the default-scope sentence, but leaves 7 of 11 enum values unaddressed and never mentions `max_results` or its default of 25.

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 ('Find') and resource ('loadable items') with concrete examples (devices, presets, kits, samples), which is clear. However, it does not distinguish itself from the sibling 'browse', which likely overlaps heavily with search-driven browser navigation.

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?

'Without a category it searches instruments, drums, effects and sounds' implies default scope but gives no explicit when-to-use guidance, prerequisites, or routing versus siblings like 'browse' or 'load_device'. Usage is inferable but not stated.

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

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

With no annotations, the description carries full burden, but it does disclose a meaningful behavioral trait: the operation is a UI selection ('highlight... in the clip view') rather than a data mutation. It omits error behavior, whether playback/selection state changes, and any permission 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, front-loaded sentence with no filler. It is appropriately sized for a simple two-parameter selection tool, though it is arguably too sparse to carry the definition's weight.

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

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

No annotations, no output schema, and 0% parameter coverage leave the description doing all the work, yet it says nothing about index semantics, failure modes, or interaction with the current track/clip selection. Incomplete for calling the tool correctly.

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

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

Schema coverage is 0% and neither track_index nor slot_index is explained. The description adds no meaning about indexing base, valid ranges, or whether slot_index is session-slot only, so agents get no help beyond bare integer properties.

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

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

States a clear verb (highlight/select) and resource (a clip slot in Live's UI), and adds the effect that the user sees it in clip view. It does not explicitly distinguish itself from siblings like select_track or fire_clip, but the resource is unambiguous.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as select_track or fire_clip. The phrase 'so the user sees it' hints at a UI-navigation purpose but leaves selection conditions for the agent to infer.

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 one real side effect: selection is a UI-state change that surfaces the track's devices panel. It says nothing about permissions, what happens on an invalid index, or whether the selection persists across other calls, leaving meaningful behavioral gaps for an unannotated 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?

A single tight sentence that front-loads the action and appends the useful side effect as a parenthetical. Nothing is wasted, though the brevity is partly what leaves the parameter and usage gaps.

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

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

For a 2-parameter tool with 0% schema coverage, no annotations, and no output schema, the description covers only the high-level action. An agent must guess at the kind/index semantics and at error behavior, so the definition is incomplete 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 neither parameter is mentioned in the description. The ambiguous interaction between the "kind" enum (track/return/master) and "track_index" — e.g. whether the index space shifts for returns or master — is left entirely unaddressed, and the description adds nothing beyond the bare schema.

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

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

States a specific verb and resource ("Select a track") and clarifies the scope as UI selection rather than a data read, which separates it from get_track_info and set_track. It does not explicitly name or exclude the nearest siblings, 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?

The parenthetical "shows its devices at the bottom" implies why an agent would select a track (to expose its device chain before device operations), giving a usable hint. However, there is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives like select_clip or get_track_info.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, yet it says nothing about whether this mutates a live clip, whether the clip must already exist, required permissions, reversibility, or error behavior. The 'gain raw 0..1' vs 'gain_display' hint is a useful unit caveat but is parameter-level rather than behavioral.

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 dense paragraph with no filler, and the reference data (warp modes, ranges) is packed efficiently. The fragmentary lead sentence is weak but does not bloat the text.

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

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

For a 7-parameter mutation tool with no annotations and no output schema, the description covers the musically complex parameters well but omits any explanation of track_index/slot_index addressing and warping, and gives no mutation or return context.

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

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

Schema description coverage is 0%, so the description must compensate, and it does substantial work: warp_mode values with meanings, pitch_coarse in semitones (-48..48), pitch_fine in cents (-50..50), and gain's raw 0..1 range. It leaves track_index, slot_index, and warping unexplained, but the added semantics clearly exceed the bare schema.

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

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

The opening 'Audio clip playback.' is a topical fragment, not a verb+resource statement, so it never explicitly says the tool sets audio clip playback parameters. The parameter notes (warp_mode, pitch, gain) let an agent infer the purpose, but there is no differentiation from close siblings like set_clip, load_audio_clip, or arrangement_audio_clip.

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

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

There is no when-to-use or when-not-to-use guidance and no named alternative, despite several sibling tools that touch clip properties. The only hints ('check which your edition has', 'read gain_display') concern value selection rather than tool 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?

No annotations are provided, so the description carries the full behavioral burden. It usefully adds the volume scale semantics (0.85 = 0 dB, 1.0 = +6 dB) and pan range, which are not obvious. Yet it omits mutation side effects, whether the device must already be a rack, and the effect of leaving mute/solo/volume unset.

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?

Delivered as a single dense sentence with the core operation front-loaded, followed by the practical volume/pan scale. The parenthetical and colon make it slightly run-on 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 an 8-parameter mutation tool with no annotations, no output schema, and 0% schema coverage, the description covers volume and pan well but says nothing about mute/solo behavior or return values. It is adequate but leaves clear gaps an agent would want filled.

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

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

Schema description coverage is 0% across 8 parameters, so the description must compensate. It clarifies the three most ambiguous params (chain as a rack pad, volume 0-1 with dB mapping, pan -1..1), but leaves kind, mute, solo, track_index, and device_index to inference.

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: 'Mix one chain of a rack, e.g. a single Drum Rack pad.' An agent can identify what object is being modified. It names get_rack as the companion for listing chains but does not explicitly differentiate from set_track or set_device_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?

Usage is implied via the reference to get_rack ('get_rack lists them'), giving the agent a cue about the prerequisite lookup. However, there is no explicit when-to-use, when-not-to-use, or named alternative among the many sibling set_* tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not state whether the clip must already exist, what happens to unset fields (the schema defaults them to null), whether changes are reversible, or any permission/error behavior 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?

A single efficient sentence that front-loads the primary operation (rename) and lists the remaining options compactly with no filler. It reads as a field list rather than a structured statement, 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 7-parameter mutation tool with no annotations and no output schema, the description is too thin. It omits required-parameter meaning, any return/error behavior, and the interaction between optional fields, so an agent cannot confidently invoke it in all cases.

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

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

Schema coverage is 0%, so the description must compensate. It meaningfully maps to five of seven parameters (name, loop_start/loop_end as 'loop region (beats)', looping, color_index) and even gives a unit hint ('beats'). However the two required parameters, track_index and slot_index, are never explained, leaving a real gap.

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

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

The description names a specific resource (clip) and enumerates concrete operations: rename, loop region, looping on/off, color. This clearly separates it from create_clip, delete_clip, and duplicate_clip. However it does not differentiate itself from the very similar sibling set_audio_clip, leaving ambiguity between the two.

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

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

There is no statement of when to use this tool versus alternatives such as set_audio_clip, create_clip, or set_clip_automation. The description only lists what can be changed, providing no context, prerequisites, or exclusions to guide 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 carries the full burden. It does a good job explaining step semantics ('each holds value from time for duration beats'), but omits notable behavior: the `clear` parameter defaults to true, meaning an existing envelope is destroyed by default. Auth/permission requirements and return behavior are also unstated.

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 purpose then mechanics, no filler. It is appropriately sized for the tool. Slightly terse given that it must also carry the parameter guidance the schema lacks.

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 9-parameter mutation tool with no annotations, no output schema, and 0% schema coverage on top-level params, the description should disclose the destructive `clear` default and clarify the indexing/kind/chain parameters. It only covers the points array, leaving key calling details missing.

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

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

Top-level schema description coverage is 0%, so the description must compensate. It clarifies the point fields (time/value/duration semantics and raw value range), but the other parameters — track_index, slot_index, device_index, kind, chain, parameter, and especially the destructive `clear` default — get no explanation 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?

Specific verb (draw) + resource (clip envelope for a device parameter) with a concrete example ('an Auto Filter sweep'). It is distinguishable from siblings like set_device_parameters or create_clip. It does not explicitly route the agent against the nearest siblings, but the purpose is unambiguous.

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

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

The description implicitly tells the agent how to use the tool ('use many short steps for a smooth ramp') but gives no when-to-use/when-not guidance versus set_device_parameters or set_parameter_real, nor any prerequisite like calling get_device_parameters first. 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?

With no annotations, the description carries the full burden and does substantial work: it documents that multiple values are applied at once, that raw values are non-linear and should be verified against the returned 'display', how switch parameters and bypass are expressed, and how to reach devices inside racks. It omits permission/auth requirements, error behavior, and reversibility.

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?

Dense, front-loaded prose with inline examples that each earn their place; no filler sentences. The rack note and display-verification caveat are placed at the end appropriately.

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 covers the hard part (values semantics, switches, racks, non-linear units) but leaves the addressing parameters (kind, track_index, device_index) undocumented, which an agent needs to call it correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It ably explains the nested 'values' object, key forms (names or string indexes), and the chain/chain_device rack parameters, but leaves 'kind' (track/return/master), 'track_index', and 'device_index' 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 ('Set several parameters at once') and clarifies the batch nature, which naturally distinguishes it from the single-parameter sibling set_parameter_real and the read-side get_device_parameters. It does not name those siblings explicitly, so it falls just short of the top mark.

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 rather than stated: batching, raw-number-vs-option-name value forms, bypass via {"Device On": 0}, and rack pathing via chain + chain_device. There is no explicit when-to-use-this-instead-of guidance and no exclusions or prerequisites.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose real behavior: units are display units (not raw), seconds are auto-converted, and the raw value is found by bisection 'without side effects' (implying repeated probing that does not audibly alter state). However, as a mutation tool it never states whether the target parameter persists, what happens if bisection fails or the parameter is out of range, or any performance cost of the search.

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

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

Three tight sentences with no filler: the unit semantics (the crux) are front-loaded, followed by the mechanism, then the sibling routing. The parenthetical examples like '(e.g. 150, 5000)' earn their space by clarifying accepted input formats 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?

There is no output schema or annotation set, so the description is the sole spec, and for a 7-parameter mutation tool it is only partially complete. Purpose, unit semantics and alternative routing are well covered, but the chain/chain_device parameters, failure behavior, and whether the discovered raw value is reported back are all left to inference.

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

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

Schema description coverage is 0% across 7 parameters, so the description is the only source of meaning. It thoroughly explains the semantics of 'target' (Hz for frequencies, dB for gains/thresholds, ms for times, % for amounts) and, by extension, the kinds of 'parameter' it applies to, which is genuinely useful. It leaves 'kind', 'chain', 'chain_device', 'device_index' and 'track_index' entirely undocumented, notably the ambiguous chain vs chain_device distinction.

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

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

States a specific verb and resource (set a parameter) and immediately distinguishes itself from siblings by declaring it works in Live's display units (Hz/dB/ms/%) rather than raw values. It also names set_device_parameters as the tool it supersedes for EQ/filter/compressor work, so an agent can tell the two apart without opening either schema.

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

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

Explicitly routes the agent: 'Prefer this over set_device_parameters for EQs, filters, compressors.' This names the alternative tool and the condition that selects it, which is exactly the when-to-use-vs-alternatives guidance the dimension asks for. The only minor gap is that it does not spell out the inverse case (when raw values are preferable), but the selection rule is unambiguous.

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

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

No annotations are provided, so the description carries the full behavioral burden. It never says whether existing routing is overwritten, what happens when input_type/output_type are omitted (null), whether named inputs must already exist, or what the call returns — significant gaps 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?

Two tight sentences front-load the core action and examples without filler. Efficient, though the examples could be replaced by more substantive parameter guidance.

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 5 parameters at 0% schema coverage, no annotations, and no output schema, the description is too thin to let an agent invoke this correctly. It leaves the semantics of output_type, kind, and input_channel entirely unaddressed.

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

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

Schema description coverage is 0% across 5 parameters, and the description only illustrates input_type. It never explains kind, output_type, input_channel, or the required track_index, so four of five parameters are undocumented in both schema and prose.

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 (route) and resource (a track's input/output), and the examples clarify what 'routing by display name' means in practice. It names the complementary sibling get_routing, so an agent can distinguish the write tool from its read counterpart.

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

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

The pointer to get_routing is useful for discovering valid routing options, and the two input_type examples imply usage, but there is no explicit statement of when to use this versus set_track or set_sidechain, nor any prerequisite or exclusion guidance.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the important dual-mode behavior (omit source to list), but says nothing about what happens on invalid input, whether the device must already exist, permission/auth needs, or return format. Adds some value but far short of full behavioral coverage 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 purpose is front-loaded in the first sentence, which is good. The second sentence packs useful specifics (the ghost-trigger example, the required follow-up call) but is dense and slightly rambling; still, every clause carries information.

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

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

For a 5-parameter read/write tool with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It never explains 'kind', 'channel', the index parameters, or what the listing mode returns, leaving the agent guessing on the majority of the interface.

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

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

Schema coverage is 0% across 5 params, and the description only explains 'source' (a track name, omit to list). It says nothing about track_index, device_index, the 'kind' enum (track/return/master), or the 'channel' default 'Post FX'. Most parameters 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+resource: 'Read or set the sidechain source of a Compressor (or any device with its own input routing).' This is clear and reasonably specific. Sibling differentiation is weak, though it does point to set_device_parameters as the complement for enabling S/C On, which helps separate the two tools.

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

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

Gives concrete usage context: supply 'source' as a track name, then enable with set_device_parameters {'S/C On': 1}, and omit 'source' to list available sources. That covers the main workflow and the read-vs-write switch. It lacks explicit exclusions or guidance for edge cases (invalid source, no Compressor present).

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 is silent on whether omitted parameters are left unchanged, whether changes persist, whether this interrupts playback, or what permissions are needed — all critical for a 7-parameter mutation tool. Only the song_time/start_time playback-state nuance is disclosed.

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

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

Two short sentences: the first front-loads the affected settings, the second carries the highest-value caveat. Nearly zero waste, though the fragment style of the opening sentence sacrifices some grammatical clarity 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?

For a 7-parameter mutation tool with no annotations, no output schema and 0% schema coverage, the description covers parameter meanings but omits the update semantics (partial vs. full replacement), side effects on playback, and error behavior. Adequate but with clear gaps given the tool's complexity.

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

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

Schema description coverage is 0%, so the description must compensate, and it largely does: it maps metronome, loop, loop_start, loop_length, song_time, start_time and record_mode to their meanings, adds the unit (beats) for loop start/length, and gives a precise semantic distinction between song_time and start_time. It falls short of full compensation but adds substantial meaning beyond the bare schema titles.

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

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

The description enumerates the configurable state (metronome, arrangement loop, playhead, record mode) but never names the verb or resource explicitly — no 'sets song-level options' or equivalent. An agent can infer it is a setter for song playback settings, but the purpose is implied rather than stated, and no sibling (e.g. transport, set_tempo) is differentiated.

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

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

It gives one genuinely useful conditional rule: song_time moves the playhead only while playing, while stopped use start_time. That is real when-to-use guidance, but it covers only the playhead params and never contrasts this tool with alternatives like transport or set_tempo, nor says when the tool should not be called.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the valid range (20-999), which the schema does not, but says nothing about persistence, effect on playback, or whether the change is reversible.

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

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

A single front-loaded sentence with the action first and the constraint trailing; every element earns its place.

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

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

For a one-parameter, no-output-schema tool, the description plus schema supply everything needed to call it correctly. Only ancillary behavior (persistence, side effects) is absent, which is minor at this complexity.

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

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

Schema coverage is 0% and the schema entry is only "Bpm": number, so the description must compensate. It does, supplying both the unit (BPM) and the accepted range (20-999), which is exactly the missing semantic 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?

Specific verb+resource ("Set the song tempo") with the unit of measure (BPM). It is clearly distinct from the sibling set_time_signature, though it does not explicitly name or contrast with it.

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

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

No when-to-use or when-not-to-use guidance is offered; the description is purely a statement of effect. For a simple setter this is largely obvious, but nothing routes the agent or states 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 of behavioral disclosure. It does not state whether this is a global or per-clip change, whether existing clips are retimed or altered, whether the change is reversible, or what the response looks like 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?

A single short sentence that front-loads the verb and resource with no filler. It is efficient, though the example clause adds only marginal value given the schema's two-integer structure.

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

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

For a 2-parameter mutation tool with no annotations, no output schema, and 0% schema description coverage, the description is under-specified. It omits scope, side effects on existing material, and parameter format details an agent would need 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 for the two undocumented required parameters. The examples '4/4, 3/4, 6/8' hint at the value space but could mislead an agent into passing a combined string, since the schema actually expects separate numerator and denominator integers; no ranges or validity constraints (e.g. denominator as power of two) are given.

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

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

The description states a specific verb and resource ('Set the song time signature'), which is clear enough for an agent to identify the operation. However, it does not distinguish this tool from the closely related sibling set_tempo, which also sets a global song-level musical property.

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

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

There is no guidance on when to use this tool versus alternatives such as set_tempo or clip-level settings. The phrase 'song time signature' weakly implies a global scope, but no prerequisites, exclusions, or sibling routing are provided.

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

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

No annotations are provided, so the description carries the full behavioral burden, yet it only implies mutation via 'Change'. It never states whether changes apply in real time, are undoable, require the track to be armed, or that omitted fields are left unchanged (a hint appears only for sends). 'Track properties' and track_index resolution semantics are left unstated.

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?

Tight and front-loaded: the purpose leads, then a compact spec list of ranges. Every clause earns its place, though 'about 0.025 per dB near the top' is somewhat trivia-heavy for a tool with six undocumented parameters.

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 11-parameter mutation tool with zero annotations and no output schema, coverage is thin: only 4-5 parameters get semantics, no usage context is given, and the effect of omitted fields is unspecified. An agent could call it but might misuse or under-specify arguments.

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

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

Schema coverage is 0% across 11 parameters, so description must compensate. It does add valuable semantics for volume (0.0-1.0, dB mapping), pan (-1..1), color_index (0-69), and sends (per return track, None leaves unchanged), but arm, mute, solo, name, kind, and monitoring are entirely 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 clear verb+resource ('Change track properties'), which is enough for an agent to know it mutates a track. However, it doesn't differentiate from siblings like set_clip, set_routing, or set_device_parameters beyond the resource name, so an agent must infer scope from the tool name alone.

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

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

No when-to-use, when-not-to-use, or alternative guidance is given. The description never mentions get_track_info as the read counterpart or set_routing for routing changes, so the agent gets no routing signal among the many sibling mutation tools.

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

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

With no annotations, the description carries the full behavioral burden. It says the tool shows a view and optionally hides others, but omits whether hidden views persist, how to restore them, permission requirements, or side effects on the Live UI state.

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

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

A single front-loaded sentence with an embedded example. Every clause adds useful information, and there is no filler.

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

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

For a simple two-parameter UI tool with no output schema or annotations, the description provides enough information to invoke it correctly. It is slightly incomplete regarding sibling routing and persistence behavior, but the core invocation is clear.

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 valid 'view' strings and demonstrating the 'hide' array format, though it still does not define all accepted 'hide' values or null/default behavior.

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

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

States a specific verb ('Show') and resource ('view of Live's window') and enumerates valid view names. However, it does not differentiate from the sibling tool navigate_view, which may also affect views.

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 example 'view='Arranger', hide=['Browser', 'Detail'] for a clean Arrangement' implies a usage scenario, but there is no explicit guidance on when to use this tool versus navigate_view or other view-related siblings.

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

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

With no annotations and no output schema, the description carries the full behavioral burden yet only says what gets stopped. It does not disclose what happens when nothing is playing, whether it affects only the current clip or the whole track's playback state, or whether it errors on an invalid index.

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

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

One short sentence with zero filler, and the action is front-loaded immediately. There is nothing to trim.

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

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

For a trivial one-parameter playback action this is close to sufficient, but with no annotations and no output schema the description leaves the index semantics and the no-op/error behavior undocumented, which an agent would need in order to call it correctly.

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

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

Schema description coverage is 0% and the single required parameter 'track_index' has no documentation anywhere. The description's 'on one track' weakly implies the parameter selects a track but adds no meaning about index base, valid range, or how to obtain it.

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

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

States a specific verb ('Stop') and resource ('whatever clip is playing on one track'), which is clear enough to distinguish it from clip-starting siblings like fire_clip. It stops short of naming any sibling, so it does not fully earn a 5.

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

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

The phrase 'on one track' implies this is a per-track stop as opposed to a global transport stop, but no when-to-use condition, prerequisite, or alternative (e.g., transport, fire_clip) is stated. Usage is only inferable.

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 deliver real behavioral context for two of seven actions: undo/redo operate on Live's own global history (not a per-tool stack) and back_to_arranger re-arms Arrangement follow after Session clips were launched. However, play/stop/continue/stop_all_clips behavior, failure modes, and whether transport state is global or per-track are unstated.

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 tool's identity and then the non-obvious action semantics. No filler, though the quoted action names could be structured more scannably.

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 is the only behavioral source. It covers the two hardest-to-guess actions adequately but leaves four of seven enum values and the overall tool semantics (global vs per-track transport) unexplained, which is thin for a seven-action control surface.

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?

A single enum parameter with 0% schema description coverage, so the description must compensate. It adds meaning for 'undo', 'redo', and 'back_to_arranger', which is genuine value, but the other four enum values are left with no semantics beyond their literal names.

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

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

"Transport control" names the resource and the enum enumerates the concrete actions, so the domain is clear. But the description never enumerates or characterizes the core actions (play/stop/continue/stop_all_clips) and gives no differentiation from siblings like stop_all_clips or fire_clip, so an agent must open the schema to know what this tool actually does.

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

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

There is no guidance on when to choose this tool over alternatives such as stop_all_clips, fire_clip, or stop_track_clips, and no prerequisites or sequencing hints. The explanatory clauses about undo/redo and back_to_arranger describe behavior, not when to use them.

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