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

No annotations are provided, so the description carries the burden. It usefully discloses two behavioral traits: the default position is the playhead, and the playhead is left unchanged (a side-effect boundary versus live_set_transport). It omits any permission/state requirements or 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?

Two tight sentences, front-loaded with the core action and the position semantics, then the side-effect note. No filler; appropriately sized for a one-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 a single optional parameter, the description covers the critical call details: what it does, where, and the default position. Enough to invoke correctly, though a note on marker return/identity would round it out.

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

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

With only one optional parameter at 0% schema coverage, the description compensates well by explaining that 'seconds' is a position and that it defaults to the playhead. This adds real meaning beyond the bare 'number' type in the schema.

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

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

States a specific verb and resource ('Add a marker') with scope ('in the running Studio One'), so an agent can distinguish it from live_delete_marker and live_markers. It stops short of explicitly naming those siblings, but the add/list/delete distinction is clear enough.

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

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

There is no explicit when-to-use or when-not-to-use guidance, nor any named alternative. The intended context is only implied by the tool name and the mention of the playhead default.

Agents often have multiple tools that could apply. Explicit usage 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 disclose one useful trait, the default type (audioMono), but says nothing about side effects, whether the new track becomes selected, undo behavior, or that a Studio One connection/session is required.

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

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

One compact sentence with the verb, target, and value set front-loaded; no filler. It is efficient, though the parenthetical type list makes the tail slightly dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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-optional-parameter creation tool with no output schema, the description covers what gets created and which variant. It would be fully complete with a note on the open-song prerequisite and what happens to the new track.

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

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

Schema coverage is 0%, but the single parameter is an enum whose values the description simply repeats. It does add one piece of meaning the schema lacks, the '(default)' annotation on audioMono, which is genuinely helpful for an optional parameter.

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

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

States a specific verb and resource ('Add a track') plus the scope ('the song open in Studio One'), and enumerates all five creatable track types. An agent can tell exactly what this does and can distinguish it from sibling tools like live_delete_marker or live_select_track.

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

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

The phrase 'song open in Studio One' implies a prerequisite (an open song) but never states it as a condition, and there is no guidance on when to pick this over siblings or when-not to use it. Usage is only implied, not spelled out.

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

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

With no annotations, the description carries the full burden. 'List' weakly implies a non-mutating read, and listing the returned fields (volume, pan, mute, solo, record-arm) adds useful context about scope and freshness. It does not explicitly confirm read-only behavior, error conditions, or whether values reflect unsaved in-memory 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 sentence, front-loaded with the verb and resource, with the returned fields appended for precision. 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?

There is no output schema and no annotations, so the description must convey what comes back — and it does by naming the five channel-state properties. It stops short of documenting refresh/liveness semantics or behavior when Studio One is not running, which is a modest gap for a zero-parameter query.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No param guidance is needed or 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?

Specifies the verb (List), the resource (mixer channels of the song open in Studio One right now), and enumerates the state fields returned (volume, pan, mute, solo, record-arm). This distinguishes it from siblings like live_tracks or live_track_state, which operate on tracks rather than mixer channel strips.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 'open in Studio One right now' implies the precondition (a live session with a song loaded) and that this returns ephemeral live state rather than saved data. However, it never states when to prefer this over live_tracks/live_track_state or what happens if no song is open, leaving selection 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 burden. It usefully discloses the check_only dry-run behavior (report enabled without executing) and that the tool executes arbitrary commands, but says nothing about reversibility, whether a failed command raises or silently no-ops, or what the execute-path returns.

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

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

Two sentences, zero padding, with the core action and identifier format front-loaded ahead of the discovery hint and the check_only 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 generic, unannotated mutation gateway with no output schema, the description covers the happy path and the check_only probe but not the execute-path return value, error behavior, or which commands need args. Adequate but there are 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 50%. The description clarifies the category/name format via examples ('Transport/Start') and re-explains check_only, which the schema already documents. The args parameter ('flat [key, value, key, value...]') is left to the schema with no guidance in the description on which commands accept 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 (Run) and resource (any Studio One command) with a concrete disambiguation: commands are identified by category/name exactly as in Keyboard Shortcuts, with six worked examples (Transport/Start, Edit/Undo, File/Save, etc.). It is immediately distinguishable from siblings like live_undo or live_save, which are single fixed commands.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 discovery to live_list_commands ('Use live_list_commands to discover names') and explains the check_only probe path. It does not state when to prefer the dedicated siblings (live_undo, live_save, live_set_transport) over this generic command runner, so one inference remains.

Agents often have multiple tools that could apply. Explicit usage 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. 'Delete' implies a mutation, but the description does not disclose whether the deletion is undoable (a live_undo sibling exists), what happens if the marker is not found, or whether the Studio One connection must be live for it to succeed.

Agents need to know what a tool does to the 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 waste; the resource and the two addressing modes are conveyed immediately.

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

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

For a mutation tool with zero annotations, zero schema descriptions, no output schema, and no required parameters, the description leaves key gaps: error behavior, undo semantics, and parameter mutuality 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 clarifies that 'number' comes from live_markers and that 'seconds' is an exact position. However, it omits which parameter takes precedence when both are passed, or whether they are mutually exclusive.

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

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

States a specific verb (delete) and resource (marker) and scopes it to 'the running Studio One', which distinguishes it clearly from sibling live_add_marker and live_markers. An agent can identify this as the deletion counterpart without opening the schema.

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

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

It tells the agent the two ways to identify a marker (number or exact seconds), which is useful targeting context, but gives no when-to-use vs when-not guidance, no explicit statement that the two identifiers are alternatives, and no note that at least one must be supplied (required parameters = 0).

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the track's events are returned afterwards, that transposeUp/Down apply only to instrument parts, and that changes are reversible via live_undo, but it never warns that 'delete' is destructive, states permission/selection prerequisites, or says whether other tracks are 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?

Front-loaded with the core operation, and the action list plus the return/undo notes are dense and waste-free. Slightly long enumeration, but every clause carries information an agent needs to pick an action.

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

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

For a mutation tool with no annotations and no output schema, the description covers return behavior and reversibility reasonably well, but omits track-parameter meaning, permission or selection prerequisites, and the destructiveness of the delete action.

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

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

Schema coverage is only 33% (just the 'at' field). The description compensates for 'at' by clarifying it accepts seconds or bars and is needed for split/trimStart/trimEnd, but the required 'track' parameter is undocumented in both schema and description, 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?

States a specific verb (edit) and resource (all events on one track in the running Studio One) and enumerates the supported actions, so an agent can distinguish it from siblings like live_select_events, live_track_state, or live_command without opening the schema.

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

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

The only routing guidance is 'Use live_undo to revert', which points to the recovery path rather than telling the agent when this tool is preferable to alternatives such as live_command or live_select_events. Usage is implied by the action list but never stated explicitly.

Agents often have multiple tools that could apply. Explicit usage 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 so well: it discloses available globals, the install-time gating flag, the error-handling hazard (a modal Scripting Error dialog pops on throw or on calling a non-existent host member), and the guard idiom (typeof check). This is exactly the operational context an agent needs before invoking.

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

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

Front-loads purpose, then prerequisites, then the critical caveat. Dense but every sentence adds value; the warning about the modal dialog is slightly long-winded but warranted given the failure mode.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 tool with no output schema, the description covers purpose, gating condition, globals, an example, and failure behavior. Return value is only loosely characterized ('return the result'), which is a minor gap but the absence of an output schema makes that acceptable.

Complex tools with many parameters or behaviors need more documentation. 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 50%: `code` is documented in the schema, but `depth` has no schema description. The description compensates by explaining that host objects are 'described to a depth', giving the parameter meaning beyond the raw integer schema.

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

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

States a specific verb and resource: runs JavaScript inside Studio One's script engine and returns the result. This is unmistakably distinct from all sibling live_* tools (transport, markers, tracks, etc.), which perform fixed DAW operations rather than arbitrary scripting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 ('Only works when the bridge was installed with --allow-eval') and a concrete use case ('exploring the undocumented object model') with an example call. It does not name alternatives for the cases where eval is unavailable, so it stops 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?

With no annotations, the description carries the full burden and discloses key behaviors: the scale (~1,000 commands), optional substring filtering, with_state semantics, and the important caveat that many commands require a selection or open editor. It does not mention pagination, ordering, or read-only safety explicitly, but the read-like nature is evident. These additions are valuable beyond the bare schema.

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

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

The description is two sentences, front-loaded with the core purpose and then the behavioral details. Every clause earns its place by adding information about scope, filtering, state, and constraints. There is no redundancy or fluff.

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

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

For a list tool with no output schema and no annotations, the description covers purpose, both parameters, and important runtime caveats. It stops short of explaining the return format (e.g., command names vs. objects) or how to handle potentially large results, but the essential context is present. An agent can call it correctly with what is provided.

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

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

Schema description coverage is 0%, so the description must explain both parameters, which it does: filter is a substring filter, and with_state adds whether each command is currently enabled. It does not specify case sensitivity or exactly which field filter targets, but the semantics are clear enough for correct invocation.

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

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

The description states a specific verb and resource: list Studio One commands available to live_command, with an approximate count and optional filtering. It clearly distinguishes this discovery tool from the sibling live_command, which executes commands. An agent can immediately understand the tool's role without opening the schema.

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

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

The phrase 'available to live_command' provides clear context that this tool is for discovering commands before invoking live_command. It does not explicitly state when not to use it or name alternatives, but the implied workflow is strong enough. No exclusions or prerequisites are mentioned.

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

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

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses that the playhead briefly moves and is restored, that the tool refuses while playing, and that only markers 1-20 are visible. It also clarifies that marker names come from the last save.

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

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

The description is compact and front-loaded, with returned fields and caveats delivered in a single structured sentence. Every clause adds useful information without waste.

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

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

There is no output schema, so the description must explain return values; it names the returned fields (number, position, name). It also covers side effects and visibility limits, making it complete for a zero-parameter read tool.

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

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

The tool has zero parameters and an empty schema, so the baseline is 4. No parameter semantics are needed or missing.

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

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

The description states a specific resource and scope: markers of the currently open Studio One song, with returned fields. It implicitly distinguishes this read operation from siblings like live_add_marker and live_delete_marker.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 one usage constraint ('refuses while playing') and implies the tool reads markers, but does not explicitly say when to use it versus alternatives. There is no routing to sibling marker tools or other retrieval options.

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

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

With no annotations, the description carries the full burden and does well: it discloses the -144 silence floor, the repeated-sampling behavior, the highest-peak-per-channel return, and the clipping threshold of -0.1 dB. It omits that this is a non-mutating read with no side effects, but the behavioral disclosure of return semantics is strong for a metering 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-loaded with the core resource and value semantics before the optional-parameter behavior. Every clause carries information; nothing is 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?

No output schema exists, yet the description explains the return shape (highest peak per channel plus clipped channels) and the clipping threshold, which is exactly what the agent needs. For a single-optional-param read tool this is nearly complete, with only side-effect/auth context absent.

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

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

Schema coverage is 0% for the single duration_ms parameter, so the description must compensate, and it does: it explains that providing duration_ms triggers repeated sampling and aggregation to the highest peak. That is meaningful semantics beyond the bare integer schema, though the unit (ms is named) and blocking behavior are not elaborated.

Input schemas describe structure but not intent. Descriptions should explain 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: reading peak meters of every mixer channel in dB, with the silence floor clarified. Clear on its own, but it does not distinguish itself from sibling read tools like live_channels, which an agent might reasonably confuse for level data.

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

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

Usage is implied through the duration_ms branch ('samples repeatedly (e.g. while playing)'), giving a decent sense of when to poll vs take a single reading. However, there is no explicit when-to-use guidance relative to alternatives like live_channels, and no stated 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 notes the operation targets the live running session, but discloses nothing about failure modes (what happens if there is nothing to redo), reversibility, or effect on history.

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

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

A single short sentence with the verb front-loaded and zero filler. It earns its length, though it is arguably under-specified rather than genuinely concise.

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

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

For a simple one-parameter tool with no annotations and no output schema, the description still omits the meaning of 'steps', the undo/redo relationship, and any failure behavior, leaving real gaps for an agent.

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

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

The single parameter 'steps' has 0% schema description coverage and the description never mentions it. The 'edit(s)' pluralization is the only faint hint that the operation can cover multiple edits, which does not compensate for the undocumented integer parameter.

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

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

States a specific verb+resource ('Redo edit(s)') and scopes it to the 'running Studio One' instance. It is clear what the tool does, but it never distinguishes itself from the sibling live_undo, which is the obvious alternative an agent will weigh.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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, no mention of the precondition (a prior undo) and no reference to live_undo. The description only implies usage through the word 'Redo' itself.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the key distinction between overwriting the current file and creating a new version that preserves the old one, but it says nothing about permission requirements, overwrite risk on the default path, error behavior, 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?

A single sentence that leads with the primary action and then the conditional branch. No filler, no repetition of the tool name, and every clause adds information.

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

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

For a one-optional-boolean tool with no output schema and no annotations, the description covers both execution paths and the rationale for each. Only minor gaps remain, such as failure behavior and the requirement that a song be open.

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

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

Schema description coverage is 0%, so the description must explain the sole parameter, and it does: new_version corresponds to 'save it as a new version ... to keep the old one', while the default path overwrites the current file. That is enough meaning for the agent to set the boolean correctly, though it never names the flag itself.

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

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

States a specific verb and resource (save the open Studio One song) and enumerates the two modes it maps to, File/Save and File/Save New Version. It is clearly distinguishable from siblings like live_undo, live_redo, or live_command, though it 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 description implies which mode to pick by explaining that the new-version path exists 'to keep the old one', so the agent can infer intent from the new_version flag. It gives no explicit when-to-use framing, no prerequisites (a song must be open), and no mention of alternatives such as live_command for arbitrary actions.

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

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

No annotations, so the description must carry the full burden. It discloses that selection is stateful (can be cleared) and that it gates downstream edits, but says nothing about whether the params are mutually exclusive, what happens with conflicting flags, or what state is left behind.

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

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

Front-loads the core action in the first clause before listing follow-up commands. The example list is long but directly actionable, and no sentence is 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 4-param, no-annotation, no-output-schema tool the description covers purpose and follow-up workflow but leaves the interaction between all/none/track/tracks unspecified. An agent cannot tell whether flags are exclusive or combinable.

Complex tools with many parameters or behaviors need more documentation. 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 only 25% (only 'none' is documented), so the description must compensate, and it does map intent for three of four params: 'named track(s)' for track/tracks, 'every track' for all, and 'clear the event selection' for none. It stops short of explaining precedence or the expected track-name format.

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

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

States a specific verb (Select) and resource (events) plus the three scoping modes it supports (named track(s), every track, clear). An agent can distinguish it from live_select_track (track selection) and from the edit siblings it routes to.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 tells the agent this is a preparatory step and that live_command must be used afterwards for selection-based edits, listing concrete command examples. It gives clear context but no explicit when-not-to-use or alternative selection tool, so it stops 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 usefully discloses that the call mutates selection state ('Replaces the selection unless exclusive is false'), which is non-obvious, but says nothing about failure modes (unmatched name), required connection/state, or 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?

Two tight sentences, front-loaded with the core action and the behavioral caveat last. No filler, no restatement of the tool name.

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

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

For a two-parameter selection tool with no output schema and no annotations, the description covers purpose, downstream dependency, and the key side effect. It is nearly complete; only error handling and preconditions are unstated, which is a minor gap given the tool's simplicity.

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

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

With 0% schema description coverage, the description must compensate, and it does: 'by exact name' constrains the name parameter's matching semantics, and 'Replaces the selection unless exclusive is false' explains what the exclusive flag actually controls. Both parameters gain meaning beyond the bare schema.

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

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

States a specific verb (select) and resource (track), plus the environment ('running Studio One') and the reason it matters ('so that selection-based commands (live_command) act on it'). This distinguishes it from siblings like live_select_events (events) and live_tracks (listing) without the agent needing to open any schema.

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

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

The clause 'so that selection-based commands (live_command) act on it' tells the agent when this tool is the right prerequisite step, and the sibling live_command is named explicitly. There is no explicit when-not or exclusion guidance, but the usage context is clear.

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

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

With no annotations, the description carries the full burden. It does disclose the return shape ('Returns before/after') and the value domain (normalised 0..1, pan 0.5 = centre), which is real added context, but it says nothing about failure behaviour (unknown channel label), whether the change is undoable via live_undo, or persistence to the song.

Agents need to know what a tool does to the 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: purpose first, then value semantics, then return format. No filler, no restatement of the tool name, and the most decision-relevant facts are front-loaded.

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

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

For a narrow, three-parameter mutation with no output schema, the description covers purpose, value encoding, and return value adequately. It still omits prerequisites (a live Studio One connection), error cases, and whether the mutation is reversible, which matters given there is no annotation safety profile.

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

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

Schema coverage is only 33% (just 'channel'), so the description has to compensate, and it does for the riskiest parameter: 'value' is only typed as number in the schema, yet the description pins down the normalised ranges and the 0.5 centre convention per field. The field enum and channel label semantics are left to the schema.

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

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

States a concrete verb and resource ('Change one mixer channel') and scopes it to 'the running Studio One', which cleanly separates it from read-side siblings like live_channels and live_track_state. It stops short of naming a sibling or stating the single-field-per-call constraint, so it is clear but not fully differentiated.

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

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

There is no when-to-use, when-not, or alternative guidance at all. In a 26-tool live-* family that includes live_command and live_eval, the agent gets no help deciding whether a channel change belongs here or in a generic command tool.

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

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

With no annotations, the description carries the full burden. It usefully discloses the return value ('Returns the transport state') and that enable is optional, but says nothing about failure modes when Studio One is not running, what happens if only one of start/end is supplied, or whether the loop range is validated/rejected.

Agents need to know what a tool does to the 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, then the format hint, then the optional flag and return value — no wasted words and no redundancy with the schema.

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

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

For a small 3-parameter tool with no annotations and no output schema, the description covers purpose, parameter formats, the optional flag, and the return value. It leaves edge-case behavior (partial ranges, no-op calls since zero params are required) unexplained.

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

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

Schema coverage is 67% and the schema documents the dual number/string format for start/end, but 'enable' has no schema description at all; the description fills that gap by explaining it turns looping on or off. It also reinforces the bar-position format, adding value beyond the schema.

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

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

States a specific verb+resource (set the loop range) on a named target (running Studio One) and covers the optional enable behavior. It does not distinguish itself from the closely related sibling live_set_transport, which also manipulates transport state, so an agent must infer the boundary.

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

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

Usage is implied rather than stated: 'in the running Studio One' signals the precondition that the DAW must be running, but there is no when-to-use/when-not guidance and no mention of live_set_transport as the alternative for non-loop transport changes.

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

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

With no annotations, the description must carry the full behavioral burden. It discloses that the host must be running and that it returns the resulting transport state, but says nothing about side effects of tempo/position changes (e.g. seeking during playback), required permissions, whether unspecified fields are left unchanged, or whether all params are optional.

Agents need to know what a tool does to the 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 verb and resource, then the settable fields, then the return behavior. No filler; the only cost is a slightly dense enumeration mid-sentence.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 settable surface and the return value, which is the main thing. It stops short of preconditions, param interactions, and side-effect disclosure needed for full confidence before invoking.

Complex tools with many parameters or behaviors need more documentation. 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 only 17% (just position_bars), so the description does meaningful compensating work: it supplies units the schema lacks ('tempo (bpm)', 'playhead position (seconds)') and maps the bare boolean properties to loop/precount/preroll semantics. It does not, however, explain the interaction between position_seconds and position_bars or any defaults.

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

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

Clear verb+resource ('Set transport values') with an explicit enumeration of what can be set (tempo, playhead position, loop/precount/preroll). This distinguishes it from the read-oriented sibling live_transport, though it never names that sibling or addresses its overlap with live_set_loop.

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

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

Usage is implied by 'in the running Studio One' (requires a live host connection) and by 'set' vs the read sibling live_transport. However, there is no explicit when-to-use guidance, no mention of live_set_loop as an alternative for loop state, and no preconditions or required state.

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

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

With no annotations, the description carries the full burden, and it does disclose the key behavioral trait that the state is live and includes unsaved changes — a meaningful distinction from persisted reads. It stops short of describing side effects, permissions, or refresh semantics, but for a read-only snapshot tool this is solid coverage.

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

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

Two compact sentences, front-loaded with the identity of the resource and then the field inventory and the sibling contrast. The parenthetical field list is dense but each item is informative; no filler sentences.

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

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

There is no output schema, so the description usefully enumerates the return contents (transport sub-fields, track count, selected tracks). Combined with the song_read contrast, an agent has enough to call it and interpret the result, though deeper detail (e.g., position/tempo units) is absent.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; there is no parameter semantics to add or omit.

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

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

States a specific verb+resource: reading the song currently open in Studio One, and enumerates exactly what is returned (title, transport state, track count, selected tracks). It explicitly distinguishes itself from the sibling song_read, so an agent can choose between them without opening either schema.

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

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

The contrast with song_read ('includes unsaved changes') gives clear selection guidance: use live_song when the current, possibly-unsaved state matters. It does not spell out explicit when-not conditions or name other alternatives, 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 burden, and it does disclose useful behavior: this is a read-only reachability probe that additionally returns remediation guidance on failure. It does not spell out what a successful result contains, but for a zero-parameter probe the disclosed behavior is close to complete.

Agents need to know what a tool does to the 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 question front-loaded and the secondary output behavior trailing. 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?

With no output schema, the description does need to hint at returns, and it does by noting the fix instructions on failure. The only gap is that it does not describe what a successful response reports, which is a minor omission for a simple connectivity check.

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

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

The tool takes no parameters, so the baseline is 4; there is nothing for the description to clarify beyond what the empty schema already conveys.

Input schemas describe structure but not intent. Descriptions should explain 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 check — whether a running Studio One instance is reachable via the MCP Bridge device — which is a distinct resource/verb combination an agent can tell apart from the sibling live_* action tools. It is phrased as a question rather than an imperative, but the intent is unambiguous.

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

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

Usage is only implied: the 'Explains how to fix it if not' clause suggests it is a diagnostic to run when the bridge may be down, but the description never explicitly says when to call it or which siblings it should precede. No alternatives or exclusions are named.

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

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

With no annotations, the description carries the full burden and does well: it discloses that takes do not wrap (next on last take changes nothing) and states what is returned (take count and now-playing clip names). It omits side-effect detail for 'unpack' (that it creates separate tracks) and any permission/live-connection 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?

Three tight sentences: resource and operations first, then return values, then the no-wrap caveat. Every sentence carries information and nothing is padded.

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

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

For a 2-parameter tool with no output schema and no annotations, the description supplies action semantics, return shape, and boundary behavior. The only real gap is how the 'track' argument should be identified, a minor omission.

Complex tools with many parameters or behaviors need more documentation. 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 effectively documents the 'action' enum by narrating all four values, but the required 'track' parameter is only implied by 'a track's takes' with no indication of accepted format (name vs. index). Baseline 3 is right given partial compensation.

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

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

States a specific resource (a track's takes/layers in the running Studio One) and enumerates the exact operations available (list, next/previous, unpack). No sibling tool covers takes, so the agent can route unambiguously from the name plus this sentence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 spells out what each action does and when the boundary behavior applies, giving clear context for choosing among the four actions. It does not name alternatives or state when not to use the tool, which keeps it 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 disclosure burden. It usefully describes the payload (media type, colour, mixer channel, takes, selection) and the default-on events behavior, but never states that this is a read-only/no-side-effect operation or any access 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 dense sentence that front-loads the resource and scope before the field list. No filler, though it is a little crammed and would read better split into purpose plus return detail.

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

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

For a read-only list tool with no output schema and no annotations, the description supplies substantial return-value context. It omits the max_events default (50) and pagination/ordering behavior, leaving minor 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 100%, so the schema already documents name, events, and max_events. The description only echoes the events default ('by default'), adding nothing beyond the schema, which matches the baseline 3.

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

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

Names the resource (tracks) and its scope ('of the song open in Studio One right now'), and enumerates the fields returned. The verb is only implicit (a read/list) and it does not differentiate itself from nearby siblings such as live_channels or live_track_state, so it is clear but not fully self-locating.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 versus alternatives. With siblings like live_channels, live_track_state, live_select_track, and live_takes in the same namespace, an agent gets no routing guidance about which to call.

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

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

No annotations, so description carries full behavioral load. It discloses non-obvious traits: returns the mixer channel, restores track selection, and that mute is not on Studio One's undo stack. It does not cover permissions, error behavior, or how duplicate/hide affect project 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?

Three sentences, front-loaded with purpose and action list, then return/side-effect and undo caveat. No redundancy; each sentence adds useful information.

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

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

No output schema and no annotations, with 2 params at 0% schema coverage. The description covers return value, selection restoration, and undo caveat for a multi-action tool, making it mostly complete, though it omits error handling and optionality of track for showAll.

Complex tools with many parameters or behaviors need more documentation. 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 description must compensate. It explains action enum semantics (including showAll unhides every track) and that track is specified by name. It does not clarify that track is optional/ignored for showAll, and adds little about track name format.

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

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

States specific actions (toggle arm/monitor/mute/solo, hide, duplicate, showAll) on the track resource, and mentions live_undo as an undo alternative. It does not differentiate from other track-management siblings like live_tracks or live_add_track, but the verb+resource is clear.

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

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

Provides explicit guidance for mute: use toggle again rather than live_undo, naming the alternative and condition. For other actions it only implies usage through descriptions, with no when-to-use versus add_track/select_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?

With no annotations, the description carries the full behavioral burden. It discloses that the tool acts on a running Studio One and returns transport state, but says nothing about permissions, side effects, reversibility, error handling, or what happens if Studio One is not running.

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

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

A single, front-loaded sentence with no wasted words. The core action and return are stated immediately and efficiently.

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

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

For an action tool with no annotations and no output schema, the description is too sparse. It mentions a return value but omits required usage context, parameter meanings, and behavioral details like side effects or error conditions.

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

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

The schema description coverage is 0%, so the description should compensate, but it does not. It only implies that the action parameter selects a transport button; it does not explain the enum values or their effects.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Press') and resource ('transport button in the running Studio One') and says it returns the resulting state. It does not distinguish itself from sibling tools like live_set_transport or live_command, so it falls short of a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives such as live_set_transport or live_command, nor any prerequisites or exclusions. Usage is only implied by the verb 'Press'.

Agents often have multiple tools that could apply. Explicit usage 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 only that intent is to reverse edits; it says nothing about whether the undo is itself redoable, whether it fails when there is no history, or what state is affected. For a mutating tool with zero annotation coverage this is thin.

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

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

A single tight sentence with the action front-loaded and no filler. It is efficient, though its brevity is partly the source of the gaps noted in other dimensions.

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

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

For an undo tool with no annotations, no output schema, and an undocumented optional parameter, the definition is too sparse. An agent knows what it does but not when it will fail, whether it is safe to repeat, or how to control the number of undone steps.

Complex tools with many parameters or behaviors need more documentation. 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 'steps' parameter, and the description never mentions it at all – 'edit(s)' is the only nod to multiple steps. It also does not explain the default step count or why the schema permits negative values, which is exactly the kind of meaning the description should supply.

Input schemas describe structure but not intent. Descriptions should explain 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 (undo) and the affected resource (the last edit(s)) in a named environment ('the running Studio One'). An agent can distinguish it from the sibling live_redo, though the description never explicitly names that inverse relationship.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 mention of the obvious alternative live_redo. Eligibility is only hinted at by the phrase 'in the running Studio One', which implies the app must be running but is never stated as a prerequisite.

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

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

No annotations are provided, so the description carries the full burden. It discloses ordering (newest first) and a downstream use, but does not explicitly state that this is a read-only, non-destructive operation or mention any permission or rate-limit concerns. For a simple list tool the 'List' verb implies read-only, but with zero annotation coverage a 3 is appropriate.

Agents need to know what a tool does to the 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 core action and scope, with no wasted words. The ordering constraint and downstream use are included efficiently.

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

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

For a one-parameter list tool with no output schema, the description adequately explains what is returned (autosaves and backups) and how the results can be used. It could be slightly more complete by noting the read-only nature explicitly, but overall it provides enough context 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 100%, so the single 'song' parameter is already fully documented as 'Song title or .song path'. The description only implies that this parameter identifies the song whose history is being listed, adding no format or syntax details beyond the schema.

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

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

The description uses a specific verb (List) and a precisely scoped resource (a song's autosaves and backups in its History folder), with the ordering (newest first) made explicit. It distinguishes itself from siblings like song_list and live_song by targeting history artifacts rather than the songs themselves.

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

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

It clearly states the context in which the returned paths are useful: 'Each path can be passed to song_read to compare versions.' That gives the agent a concrete follow-up action, though it does not explicitly exclude alternatives or say when to prefer this over other song-related 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 usefully discloses ordering (newest first) and the on-disk source locations, but says nothing about default/max limit behavior, error handling when the directory is missing, or recursion depth.

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

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

A single front-loaded sentence with zero waste; the verb, ordering, and source paths are all stated compactly.

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

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

Adequate for a simple list tool with no output schema (return values needn't be explained). However, the undocumented limit parameter and absent error/permission behavior leave gaps for a tool with no annotations to lean on.

Complex tools with many parameters or behaviors need more documentation. 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 50%: the query param is documented in the schema, but limit has no description anywhere. The prose adds no parameter meaning (e.g., default limit, matching semantics), so it fails to compensate for the uncovered parameter.

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

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

States a specific verb+resource ('List Studio One songs on disk'), plus scope details (newest first) and the source directories. An agent can tell it apart from song_read (which reads a single song) by scope, though the description never names that 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?

Usage is only implied: it's a discovery/browse operation versus song_read for reading one song. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must infer the 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 are provided, so the description carries the full burden. It does add one genuinely useful behavioral fact: the result reflects the last save, not unsaved edits, which separates it from live_* tools. However it says nothing about file-not-found/ambiguous-match behavior, permissions, or how a title match is resolved beyond the schema's note.

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

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

Two sentences, no filler, and the return-content inventory is front-loaded before the staleness caveat. The enumeration is dense but earns its place since no output schema exists to describe the payload.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 and no output schema, the description usefully enumerates return contents and flags staleness. The remaining gap is the lack of explicit routing against song_list/live_song and of error/ambiguity behavior, but for a read-only inspection tool this is largely 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 100% and each parameter (song, track, detail enum) is already documented with its semantics in the schema. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb (Read) and resource (a Studio One song from its .song file) and enumerates the exact payload: tempo, time signature, markers, arranger sections, tracks/takes/clips, mixer channels, media files. This clearly distinguishes it from live_* siblings that query a running session rather than a saved file.

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

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

The description implies usage (read a saved .song file) but never explicitly says when to choose it over song_list, song_history, or the live_song/live_tracks family. The stale-vs-live distinction is implied by the last sentence rather than stated as routing guidance.

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