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 side effect ("Writes a PNG of the plots next to the file") and the plot default, states the measurement noise floor, and explains the gating caveat that can hide real changes. What it does not state is whether it only reads (implied but never asserted), whether the file must be local, or whether other formats are 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 and no filler sentences, but it is essentially one very long run-on sentence packed with a comma-separated inventory of metrics. Since there is no output schema, that inventory largely earns its place; still, the density (band edge frequencies on every band, nested parentheticals) makes it harder to scan 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 tool with no output schema, listing the returned measurements and the reference-difference behavior is exactly the right compensation, and the noise-tolerance note arms the agent to interpret results correctly. Remaining gaps are minor: it references an output field (`loudnessDeltaLu`) that appears nowhere in the input schema without saying so explicitly, and it never confirms the tool is read-only apart from the PNG write.

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 60%, and the description adds real meaning to the biggest gap: the `reference` parameter is explained as another WAV (a capture before a change or a commercial track) that yields a difference per measure, with the useful note that band differences are loudness-independent. `plot` is reinforced by "writes a PNG ... next to the file", and sections are implied by "loudness per section", though the `segment` default of 10 s is left entirely 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?

Opens with a specific verb and resource ("Measure a WAV") and then enumerates exactly what is measured: EBU R128 integrated/short-term/momentary loudness and LRA, sample/true peak, crest factor, PLR, per-band energy, low-end below 120 Hz, L/R correlation, stereo width, and section loudness. It also names its input sources (an audio_capture, a bounce, any mix), which cleanly separates it from the capture/bounce siblings that produce those files.

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 usage context: use a reference WAV when comparing before/after or against a commercial track, and use the ungated loudnessDeltaLu rather than integrated LUFS for short excerpts because integrated is gated for whole songs. It also warns that repeat captures differ by ~±0.2 dB true peak and ~±3% width, so smaller moves are noise — practical when-to-trust-it guidance. It stops short of explicitly naming an alternative tool or a when-not-to-use condition.

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 load and does most of it: nothing gets installed, existing output routing is untouched, transport/playhead are restored, metronome and precount are silenced, and the capture is audible. It does not mention macOS audio-capture permission prompts or failure modes (no audio playing, tap denial), which is the main behavioral gap for a system-level recorder.

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

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

Front-loads the core action and mechanism, then layers conditional behavior; nearly every clause carries information. Some sentences are long and semicolon-chained, but 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 capture tool with no annotations and no output schema, the description covers side effects, defaults, and cleanup behavior well. It never states what is returned (the written path, duration, or a confirmation), which an agent needs since no output schema exists.

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 75%, and the description adds real meaning on top: 'out' defaults to the studio-one-mcp data folder, and from_seconds/from_bars act as alternatives used only when transport is stopped, falling back to the playhead. It does not restate the 600-second cap or clarify how from_seconds and from_bars interact if both are supplied.

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 a specific verb and resource (record what Studio One plays to a WAV file) plus the mechanism (macOS process tap) and format (32-bit float, session rate). The line 'Never records in Studio One' explicitly separates it from the live_record / live_bounce siblings, so an agent can select it 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?

Gives the downstream handoff ('Pass the file to audio_analyze') and the exact behavior when transport is stopped, which tells the agent it can call this at any time. It stops short of naming alternatives it competes with (e.g. live_bounce for an in-app offline render), so the exclusion 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 supplied, so the description must carry the behavior, and it does: it discloses the mutation's side effect (track outputs are rerouted), the reversibility guarantee ('One live_undo removes it'), the persistence of selection, and the return payload. It does not cover failure modes, e.g. what happens with an unknown track 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?

Three short sentences, front-loaded with the action, followed by the return value and the undo guarantee. Every sentence carries information an agent needs; 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?

For a two-parameter mutation with no annotations and no output schema, the description covers effect, return shape, reversibility, and selection preservation. The remaining gap is error behavior for invalid track names, which is minor but non-trivial for a routing change.

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%: 'tracks' is documented as 'Exact track names' in the schema itself, while 'kind' has only an enum. The description adds meaning to 'kind' by explaining what each option does, but contributes nothing to 'tracks' beyond the schema. Baseline 3 fits with schema doing half the work.

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

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

States a specific verb and resource ('Create a bus... or a VCA') and immediately explains the effect: 'their outputs are routed into it'. This distinguishes it from the sibling add tools (live_add_track, live_add_instrument_track, live_add_send) by naming the routing/VCA concept 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 clarifies the bus-vs-VCA choice inline ('routed into it' vs 'controls them'), which is real decision guidance for the enum. It does not name alternatives such as live_add_send or state prerequisites/exclusions, so it stops short of full when/when-not guidance.

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

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

With no annotations, the description does meaningful work: it discloses the live-session requirement ("running Studio One") and, notably, the reversibility contract — "One live_undo removes the track and the instrument." That is a concrete behavioral fact an agent could not infer from the schema. Remaining gaps, such as failure mode for an invalid instrument name, keep it below 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?

A single sentence with no filler, and the core action is front-loaded. The nested parentheticals carrying the plugin source, kind filter, and examples make it dense to parse in one pass, but nothing is superfluous.

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

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

For a two-parameter creation tool with no annotations and no output schema, the description covers what it creates, how to source the instrument, and how to undo it. It does not say where the track is inserted, what is returned (e.g. a track identifier), or what happens if the instrument name is unknown, leaving the agent under-informed for post-call handling.

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 50%, with `instrument` having no schema description, so the description must compensate — and it does, explaining the value source (live_plugins, kind "instrument") and supplying examples. The optional `name` parameter is covered only partially, since the default behavior (instrument name) lives in the schema rather than the description.

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

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

States a specific verb and resource ("Add an instrument track") and narrows the scope precisely: it creates a track hosting a new instrument instance, sourced "by name, from live_plugins with kind 'instrument'". The examples ("Mai Tai", "Presence") make the expected value concrete and separate it from live_add_track and live_add_plugin.

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 routes the agent to live_plugins for valid instrument names and implies this is the tool for instrument tracks versus generic track creation, which is real selection guidance. It stops short of explicitly contrasting with siblings like live_add_track or live_add_plugin, so no exclusion statement is given.

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

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

With no annotations at all, the description carries the full behavioral burden. It does disclose one genuinely useful side effect — "The playhead is left where it was" — which an agent could not infer from the schema, but it is silent on what is returned (e.g. the new marker's identifier), what happens on an out-of-range or duplicate position, and whether the change is undoable.

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

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

Two sentences, both front-loaded with the key facts (what it does, where it places the marker, the default, and the non-side-effect on the playhead). Nothing redundant or 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 simple zero-required-parameter mutation tool with no output schema, the definition covers placement semantics adequately, so nothing blocks a correct call. It stops short of saying what the call yields on success or how failures surface, which matters given the live-DAW context and absence of annotations.

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

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

Schema coverage is only 33% (the `name` property has no description), so the prose must compensate. It usefully adds the default ("default: the playhead") and the seconds-or-bars convention for `at`, and implies `name` is optional, but it never explains the separate `seconds` parameter or when to use it instead of `at`, leaving an unresolved overlap the agent must guess at.

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

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

The description gives a specific verb+resource ("Add a marker in the running Studio One") plus scope details (position in seconds or bars, default playhead, optional name), which clearly separates it from siblings like live_rename_marker, live_delete_marker and live_markers. It never names an alternative explicitly, but the operation 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 tool obviously applies to adding, and the default-to-playhead note tells the agent calling it requires no arguments at all. There is no explicit guidance on when to prefer this over a sibling (e.g. versus live_markers for inspection) or any preconditions such as needing markers enabled or a focused song.

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 supplied, the description carries the full burden and does a solid job: it declares the operation is a live mutation, states what is returned ('the channel's inserts afterwards'), describes reversibility ('One live_undo removes it'), and explains the operation runs through the MCP Track Edit task, which tells the agent changes are grouped/undoable. It omits error behavior and any prerequisite state validation, which keeps it below a 5.

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

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

Three short sentences, front-loaded with the action and target, then return value, then undo/implementation context. Every sentence contributes information an agent needs, 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 two-parameter, no-output-schema mutation tool, the description covers purpose, target scope, effective return value, and undo path. What is missing is behavior on invalid input (unknown plug-in, invalid channel label) and any confirmation of whether the channel must already exist, which is a modest but real gap.

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

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

Schema description coverage is 100%, so a 3 is the baseline; the description adds genuine meaning by tying the 'plugin' parameter to the vocabulary exposed by live_plugins, indicating the value must be a recognized plug-in name rather than arbitrary text. The 'channel' parameter is left entirely to the schema's 'Exact channel label', which is adequate but adds nothing in the description.

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

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

The description states a specific verb and resource ('Add a plug-in ... to a channel's inserts in the running Studio One') and even names where valid plug-in names come from ('from live_plugins'), which separates it from live_inserts and live_plugin_params. It stops short of explicitly contrasting itself with adjacent write tools such as live_add_send or live_add_instrument_track, but the operation 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?

It gives clear context for use: the plug-in name must come from live_plugins, and the add targets an existing channel's inserts in the live session. The mention of 'One live_undo removes it' effectively tells the agent how to back out. There are no explicit exclusions or failure conditions (e.g. unknown plugin name, missing channel), so it falls short of full when-to-use/when-not guidance.

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

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

With no annotations, the description carries the full burden and does well: it discloses the creation side effect (new FX channel), the irreversibility caveat ("Not reliably undone by live_undo, so ask before adding"), and what is returned. It stops short of stating any prerequisite state (e.g. whether the channel must be selected or the plugin loaded in the project), leaving a small gap for a mutation tool.

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

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

Three tightly packed sentences, front-loaded with the action, then the mechanism, then alternatives and the risk warning. No sentence is redundant and nothing is buried mid-paragraph.

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 supplies the action, its side effects, the return payload, the irreversibility warning, and sibling routing. An agent could invoke it correctly without opening any other field.

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 100%, so the baseline is 3, but the description adds provenance for `plugin` — names come "by name, from live_plugins" — which tells the agent where valid values originate, beyond the schema's example strings. It adds little extra for `channel` beyond the schema's "Exact channel label."

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

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

Opens with a specific verb and resource: "Add an effect send to a channel in the running Studio One," and immediately explains the side effect (Studio One creates a new FX channel plus a send to it). It distinguishes itself from live_add_bus by noting that sending to an existing bus or FX channel cannot be scripted, and from live_set_send by routing level changes there.

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?

Explicit alternatives are named with their conditions: use live_plugins for plug-in names, live_set_send for the send level, and the tool states a hard exclusion (existing-bus sends are not scriptable). It also gives a consent rule — ask before adding when the user has not clearly asked for it.

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

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

No annotations are provided, so the description carries the full 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 zero annotations the description carries the full burden and does so well: it discloses playback-dependent jump behavior, the sync-point concept, undo cost (one undo step per edit, two for move-with-content), that delete is destructive and closes the gap, and that the loop range 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?

Dense but each clause carries information — action semantics, undo cost, position format. It is a single long run-on paragraph rather than a structured list per action, which costs some scannability for a 13-action tool.

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

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

For an 8-parameter, 13-action mutation tool with no annotations and no output schema, the description covers action semantics, destructive effects, undo accounting, and position formats. It does not describe what 'sections' returns or how syncMode setting interacts afterward, leaving a small residual gap.

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

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

Schema coverage is already 88%, so the baseline is 3; the description adds real meaning beyond it by tying params to actions (to/end/name/start/content/sync), specifying position syntax ('seconds or bars like "9.1.1.0"'), advising 'to' be a section boundary, and warning goto-while-playing only reaches sections 1-16.

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

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

Opens with a specific verb+resource (arranger sections in the running Studio One) and then enumerates all 13 actions in plain terms, so an agent knows exactly what domain this covers. Naming 'createFromMarkers' implicitly separates it from the sibling marker 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?

Guidance is given per action: 'next / previous: step while playing', 'goto ... while playing it jumps at the arranger's sync point, while stopped it moves the playhead', and 'Editing (each one live_undo)' cross-references the undo sibling. There is no explicit statement of when to prefer live_markers/live_markers-family tools over this one, so not 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 supplied, so the description carries the full burden, and it does: it discloses that no dialogs appear, that the operation is undone by a single live_undo, that the rendered .wav survives undo in the Bounces folder, and that toNewTrack mutes the originals. Those are exactly the side effects an agent needs before mutating a session.

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 dense sentences, front-loaded with the verb and resource before the mode breakdown and the caveats. Every clause carries non-obvious information (muted originals, surviving .wav, undo count, dialog exclusion); nothing 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 two-parameter mutation with no annotations and no output schema, the description covers modes, reversibility, and residual artifacts thoroughly. The only real gap is how to identify the target track, and secondarily whether anything is returned; both are minor against the otherwise strong behavioral 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 does well for the enum parameter, spelling out what inPlace and toNewTrack each produce, but leaves the required 'track' parameter undefined — no indication whether it takes a track name, index, or ID, despite many sibling tools that could identify a 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 (bounce/render) applied to a specific resource (all events on one track in the running Studio One), and disambiguates the two modes in one clause each. It also explicitly excludes what it is not (mixdown/stem export), so an agent can separate it from adjacent rendering operations 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?

Gives explicit when-to-use (per-track bounce, with the two mode variants), an explicit when-not (mixdown and stems are not offered because they open dialogs), and names the sibling that reverses it (one live_undo). Routing information is complete rather than implied.

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

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

With no annotations, the description carries the full burden, and it does disclose that the mutation targets a live running DAW session and that the "all" value scopes the entire insert rack. It says nothing about whether the change is undoable, how a missing channel or invalid slot is handled, or what the call confirms on success.

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

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

A single front-loaded sentence with no filler, and the dual-scope behavior is stated early. It reads slightly run-on with the parenthetical and trailing clause, 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 live mutation tool with no annotations, no output schema, and zero schema descriptions, the definition covers the core action and scope but omits return/confirmation behavior and the meaning of the channel identifier. An agent could invoke it, but with avoidable guesswork about addressing the channel.

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 partially does: it explains that slot accepts a number sourced from live_inserts or the literal "all", and that bypassed controls bypass vs un-bypass. The channel parameter is left entirely unexplained (name? index? track vs bus?), which is a real gap for a 3-param required-only 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 names a specific verb pair (bypass/un-bypass) and the exact resource (one plug-in slot on a channel in the running Studio One, or the whole insert rack via slot "all"). An agent can immediately distinguish it from live_inserts, which is cited as the source of slot numbers.

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 usage prerequisite (slot numbers come from live_inserts) and the condition for the bulk case (slot "all" for the whole rack). It stops short of stating when not to use it or naming an alternative tool for related operations, so it lacks explicit 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 exist, so the description carries the full burden, and it discloses significant traits: changes are net (moved-and-back counts as no change), authors are not reported, and reset re-baselines 'from now'. It stops short of explicitly saying the call is read-only relative to the song or that it maintains hidden per-song snapshot state that can be reset.

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?

Core behavior is front-loaded in the first clause, followed by the enumeration and then the two important caveats (net changes, first call is a look). The long category list is informative but dense and could have been grouped more tightly.

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

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

There is no output schema, so the description must convey what comes back, and the enumeration of change categories does that adequately. The shape of the returned diff (grouping, field names) is never described, which leaves a gap for an agent that needs to parse results.

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

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

Only one optional parameter and the schema already documents it at 100% coverage, so the baseline is high; the description adds a nuance beyond the schema by clarifying that reset means re-baselining from the current moment rather than clearing history.

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 and operation: a diff of the currently open song since the previous call, with an explicit enumeration of tracked categories (tracks, events, mixer, tempo/loop, markers/arranger). This is unmistakably different from snapshot-style siblings like live_song or live_track_state.

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 real usage context: the first call for a song is a baseline look and reports nothing, so an agent knows not to interpret an empty first result as an error. It does not name alternatives (e.g., song_diff, song_history) or state when to prefer those over this.

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

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

With no annotations supplied, the description carries the full burden and does explicitly declare "read-only", which is the key safety fact an agent needs. It also enumerates exactly which channel attributes are reported. It stops short of covering failure behavior (e.g., no song open, Studio One not reachable) or result ordering.

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 with the action and scope front-loaded, followed by the returned-field list. The enumeration is dense but each item is informative. Slightly heavy inline listing could have been trimmed, 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?

No output schema exists, so the description compensates by naming the returned fields, which is the right move for a zero-parameter read tool. Remaining gaps are environmental preconditions and error cases rather than anything that would cause a wrong 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?

The tool takes zero parameters, so there is no parameter semantics to document and the baseline of 4 applies. The description correctly adds no spurious input claims, confirming the call is argument-free.

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 ("List") plus a precisely scoped resource: the mixer channels of the song currently open in Studio One. The parenthetical enumeration of returned attributes (volume, pan, mute, solo, record-arm, input monitoring, automation mode, routing) makes it clearly distinguishable from siblings like live_tracks, live_song, live_meters, and live_inserts.

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 this reads live mixer state rather than saved song data, which is useful context. However, it never states when to prefer this over live_tracks or live_meters, nor does it point to live_set_channel for modification. Usage must be inferred from the tool name and field list.

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 at all, the description carries the full burden and does meaningful work: operations execute in order, results report what each op touched plus the notes afterwards, delete requires a filter, and quantize deliberately leaves Studio One's own quantize setting alone. It stops short of covering failure behavior, partial application, or permission/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?

Front-loaded with the outcome first, then operations in execution order, then filters, return value, and undo. Every clause carries information, but the middle section is a dense run-on of shorthand notation (e.g. '1/8T (triplet)', '1/8. (dotted)') that would scan better as a list.

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 seven-operation batch mutation with no annotations and no output schema, the description supplies the essential missing pieces: operation ordering, per-op field semantics, filter semantics and defaults, beat reference frame tied to live_notes, return payload, and undo granularity. What remains absent, such as error/partial-failure handling, is minor relative to what is 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 effectively 0% for the nested ops fields, and the description compensates strongly by mapping each op to its fields: transpose needs semitones, velocity takes set 1-127 or add, length takes set beats or scale, quantize takes grid formats plus strength 0-1, add takes a notes array. The only unexplained input is the top-level 'track' string — neither the schema nor the description says whether it is a name, index, or id.

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

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

States a specific verb and resource — editing notes of an instrument track's parts in the running Studio One — and scopes it to the MCP Edit task that ships with the device. That verb+resource+scope combination separates it cleanly from sibling tools such as live_edit_events and live_notes.

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 operational guidance: 'delete (needs a filter)', 'check with live_notes' before undoing, and 'one live_undo per operation, usually'. It routes the agent to live_notes for beat positions and live_undo for rollback, but never states explicitly when to prefer this over live_edit_events or what to do when a track isn't an instrument 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 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 it does disclose two genuinely useful traits: edits are a single undoable unit ("one live_undo reverts the whole edit") and copy mutates the clipboard ("uses the clipboard"). It does not say what happens when an event number is invalid, whether editing affects live playback, or what any action returns. Useful but incomplete for a mutation tool with zero annotation coverage.

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

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

The resource definition is front-loaded and each action is a compact labelled clause, so an agent can scan to the relevant line. The brace shorthand ("edit {event, and any of: ...}") is efficient but verges on telegraphic and would be harder to parse than plain sentences. Almost no wasted words overall.

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 10-parameter tool with no annotations and no output schema, the definition covers the list output shape (ordering, start/end in seconds, gain and fade for audio) and the mutate semantics reasonably well. It omits which parameters are required per action (edit/duplicate/copy all need event; duplicate needs times), what non-list actions return, and any 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 coverage is only 20%, so the description has to compensate, and it largely does: to is a new start, to_track moves the event, gain_db sets while add_gain_db is relative, fade_in/fade_out are audio-only seconds, times is a repeat count placed right after the original, and event is a number from list or a name. The position format (seconds or bars like "9.1.1.0") is restated. Only the required `track` and the conditional requirement of event/times per action are left unaddressed.

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

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

The description opens with a concrete verb+resource ("One event (audio clip or instrument part) on a track in the running Studio One") and then enumerates the four operations it multiplexes: list, edit, duplicate, copy. An agent can immediately tell this is the per-event tool rather than a track or song tool. It stops short of naming or contrasting the near-identical siblings live_edit_events and live_select_events, 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?

Each action gets a one-line gloss ("list: the track's events...", "edit {...}: one live_undo reverts...", "copy {...}: pastes a copy at a position"), which implies when each is appropriate. However, there is no explicit guidance on which of these actions to prefer over live_edit_events or live_select_events, nor any stated prerequisites or failure conditions. Usage is implied rather than prescribed.

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 implies a read-only inspection and enumerates returned values, but never explicitly says it performs no mutation, what happens if the channel is invalid, or what prerequisites/permissions are needed.

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 redundant wording. The parenthetical scope and returned-field list are compact and each clause 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?

For a simple inspection tool with no output schema, the description identifies the scope and enumerates the returned fields (slot, plug-in name, bypassed, bypass-all). It is nearly complete, though it lacks sibling differentiation and error/edge-case behavior.

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

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

The schema only says channel is a string with no description. The description clarifies that specifying one channel narrows the result to that channel and omitting it covers each mixer channel, which is useful semantics, but it does not define the channel identifier format (name vs. index) or explicitly state that the parameter is optional.

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 the resource (plug-ins/inserts) and scope (each mixer channel or one channel), plus the returned fields. It is clearly an inspection tool for channel inserts, though it never uses an explicit verb like 'list' and does not explicitly contrast with live_plugins or live_plugin_params.

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 does not state when to use this tool versus alternatives such as live_plugins, live_bypass_insert, or live_plugin_params. The only guidance is implicit from the phrase 'on each mixer channel ... (or one channel)'.

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, the description carries the full burden; it does disclose that this reads the running Studio One instance, that macros may be built-in or user-created, and that most act on the current selection. It does not state that the operation is read-only, nor anything about ordering, pagination, or failure behavior when 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 dense sentence that front-loads the core action and appends the optional behaviors. It is efficient, though the parenthetical and trailing clause make it slightly harder to parse at a glance.

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-optional-parameter read tool with no output schema, the description covers what is returned (titles, plus runnability when requested) and the selection caveat. Only the filter semantics and read-only nature are left 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%, so the description must compensate for both parameters. It explains with_state well ('adds whether each can run right now') but only says 'optionally filtered' for filter, leaving unclear what field is matched (title? substring? case sensitivity).

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

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

The description gives a specific verb and resource ('List the macros in the running Studio One') and scopes it to the Macros panel including built-in and user macros. It implicitly separates itself from live_run_macro by being a listing operation, though it 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?

It hints at usage by explaining that with_state reports whether each macro can run right now and that most act on the selection, which tells an agent when the state flag matters. However, there is no explicit when-to-use/when-not guidance and no named alternative such as live_run_macro.

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

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

With no annotations, the description carries the full burden and discloses key behavior: it briefly moves the playhead and restores it, refuses while playback is active, and only exposes markers 1-20. It does not detail error behavior beyond refusal or whether the playhead movement is observable, but the side effect and precondition are clearly stated.

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-loads the returned data, then adds the playhead side effect, playback refusal, and visibility cap. No sentence 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 zero-parameter read tool with no output schema, the description supplies the return fields, side effect, precondition, and visibility limit. That is sufficient for an agent to call it correctly.

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

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

There are zero parameters, so the schema is empty and the description has no parameter semantics to add. Baseline 4 applies for a no-parameter tool.

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

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

The description identifies the resource (markers currently open in Studio One) and the returned fields (number, position in seconds/bar display, name), so an agent can tell it is a read/list operation. It does not explicitly name sibling alternatives like live_add_marker or live_delete_marker, but the 'right now' scope distinguishes it from mutation 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?

It implies use when you need current marker data and notes the 'refuses while playing' precondition, but it does not explicitly say when to choose this over live_add_marker, live_rename_marker, or live_delete_marker. The 1-20 visibility limit is a usage constraint rather than alternative routing.

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

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

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?

With no annotations supplied, the description carries the full burden and does substantial work: it discloses the captured state, the explicit exclusions, that restore applies a partial/differential update ('sets only what differs'), and the undo interaction caveat. The remaining gap is name-collision behavior on save and whether snapshots persist for the life of the project, which matter for a state-capturing 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 core action and its scope are front-loaded in the first sentence, followed by three short sentences that each add one distinct fact (differential restore, exclusions, undo caveat). No filler and 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 tool with no annotations and no output schema, the description covers capture scope, exclusions, restore semantics, and the undo relationship. What 'list' returns (names only, or names with timestamps) is left unspecified, which is the one thing an agent must guess before calling with action='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 description coverage is 0%, so the description must compensate for both parameters. It conveys the three action values through their verb phrases and implies 'name' is the snapshot label for save, but it never says that 'name' is required for save and restore yet ignored for list, leaving the enum/required interaction to inference from the schema.

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

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

The description names a specific verb set (save/restore/list) against a specific resource (the whole mix of the running song) and enumerates exactly what is captured: every channel's volume, pan, mute, solo, input monitoring, and each send's level and mute. This distinguishes it from live_plugin_snapshot (plugin-level) and live_save (session-level) without the agent 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 gives a concrete routing rule against a sibling: 'Mixer changes are not reverted by one live_undo; restore a snapshot instead,' which tells the agent when to pick this over live_undo. It also scopes out record-arm and automation mode, implying those belong to live_record_setup or live_set_automation, but it never states when to choose snapshotting over live_save or live_plugin_snapshot, so the alternative guidance is partial rather than 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?

With no annotations supplied, the description carries the full burden and does disclose the critical traits: 'Read-only' and that unsaved edits are included, which tells the agent it reads live memory rather than persisted data. It also pins down unit conventions (MIDI pitch numbering with middle C = C3, velocity 0-127, seconds vs quarter-note beats), though it says nothing about truncation behavior or ordering of results.

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, then enumerates return fields with their units. No filler or repetition; the parenthetical about middle C = C3 is the only slightly heavy clause, but it prevents a real interpretation error.

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 the description compensates well by enumerating the returned fields and their units. The remaining gaps are modest: no statement of result ordering or what happens when max_notes truncates the note list, and no error behavior for an unmatched track name.

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 100%, so the two parameters are already documented (exact track name, max_notes default 500). The description adds no meaning beyond the schema for either parameter — its detail is spent on return-value semantics instead — 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?

The description names a specific resource and scope: MIDI notes inside an instrument track's parts, read from the running Studio One instance. An agent can distinguish it from mutating siblings like live_edit_notes, but the sibling is never named and the verb is implied by a noun phrase rather than stated outright.

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

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

The phrase 'in the running Studio One, unsaved edits included' implicitly tells the agent to use this for live in-memory state rather than a saved song file (song_read). However, there is no explicit when-to-use/when-not guidance and no named alternative for editing notes or reading track structure.

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 load and does it well: it discloses a genuine upstream limitation ('Studio One cannot list a plug-in's parameters'), explains the workaround source for names (presets and Studio One's remote-control map), and scopes reliability to PreSonus plug-ins. It does not say anything about read-only safety or what happens if a named parameter does not exist, which is the remaining 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?

Three tight sentences, front-loaded with the returned fields and the example value formats ("2.0:1", "-12.0 dB"), which earn their space. The plug-in-coverage caveat follows logically rather than padding the opening.

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 convey return shape, and it does by listing the five fields per parameter. Given no annotations and four parameters, the definition is nearly complete; the only unaddressed item is the `channel` identifier format and behaviour when a requested parameter name is invalid.

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 50%: `filter` and `params` are documented in the schema, and the description reinforces `params` with the non-PreSonus use case. However, neither `channel` nor `slot` has any schema description, and only `slot`'s provenance is explained ('from live_inserts'); the format of `channel` (name vs. index) is never addressed 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?

The description names the specific resource ('Parameters of one plug-in on a channel in the running Studio One') and enumerates what is returned (name, value, display text, range, normalised value), which clearly separates it from the write-side sibling live_set_plugin_param and from live_inserts. It is a noun phrase rather than a verb+resource, but the operation 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?

It tells the agent where the required `slot` comes from ('slot from live_inserts') and gives a conditional fallback: for non-PreSonus plug-ins, pass names in `params`. That is real routing guidance, though it does not explicitly state when not to use this tool (e.g. versus live_plugins or live_set_plugin_param).

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 present, the description carries the full behavioral burden; it discloses that this is a read-style enumeration of installed plug-ins and which plug-in formats are covered. However, it says nothing about what each entry contains beyond a name, ordering, or what happens when nothing matches. Given zero annotation coverage, more disclosure of the return shape and failure modes would be expected.

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

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

It is a single front-loaded sentence with no filler, but the heavy nested parentheticals ('default; the names live_add_plugin and live_add_send take') make it harder to parse than necessary. The information is dense and useful, just awkwardly structured.

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

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

There is no output schema and no annotations, so the description is the only source of behavioral detail, and it leaves the `filter` parameter entirely unexplained and does not describe the shape of returned entries. For a lookup tool whose whole value is producing names an agent will feed into add_plugin/add_send, this is under-specified.

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

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

Schema description coverage is 0%, so the description must explain both parameters. It handles `kind` partially — it names the instrument case and its enum value and the effects default — but never states the literal value "effect" even though the enum contains it. The `filter` parameter is not mentioned at all, leaving half the parameters 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?

The description names a specific resource (plug-ins installed in the running Studio One, covering PreSonus, VST and AU formats) and its scope (by name, optionally filtered by kind). It also ties itself to the sibling tools that consume the returned names (live_add_plugin, live_add_send, live_add_instrument_track), which distinguishes it from live_plugin_params or live_inserts. The only weakness is that the verb is implicit in a noun phrase rather than stated as 'list'.

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

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

It states the default behavior (audio effects) and how to switch to instruments, and it identifies the downstream tools that consume the output, which tells an agent when this list is the right input source. It does not explicitly say when not to use it or how it relates to live_inserts/live_plugin_params, so a small amount of 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 exist, so the description carries the full burden; it does usefully disclose the storage location (studio-one-mcp data folder), the coverage limit (PreSonus plug-ins, all known parameters), and that restore only writes differing parameters. It is silent on what save does when the name already exists, whether slots are overwritten, and what error behavior looks like when a plug-in kind mismatches.

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 dense sentences, front-loaded with the three actions and followed by the storage/coverage caveat. No filler, though the second sentence packs several distinct facts (location, plug-in scope, parameter naming reference, restore diffing) without structural separation.

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 multi-action, 5-parameter tool with no annotations and no output schema, the description covers save and restore reasonably but leaves the list action's return shape and the 'slot' parameter entirely unaddressed. Adequate for the main flow, incomplete for the full 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 only 20% across 5 parameters. The description adds meaning for 'name' (snapshot label), 'plugin' (list filter), and implicitly 'channel' (any channel), but 'slot' is completely unexplained in both schema and description, and the save/restore vs. list distribution of parameters is not spelled out.

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 three concrete actions (save, restore, list) on a concrete resource (a plug-in's settings) and frames the tool as a remote stand-in for presets, which is a clear purpose. It does not name any sibling (e.g. live_mix_snapshot or live_plugin_params) to distinguish against, 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?

Implies usage via 'restore them onto the same kind of plug-in (any channel)' and the 'stand-in for presets' framing, plus the constraint that save/restore operate on raw parameter values for PreSonus plug-ins. There is no explicit when-to-use vs. live_mix_snapshot or live_plugin_params, and no exclusion or precondition stated for the list action.

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 well: it discloses the mutation (a new take is written), the confirmation gate, the track-arm side effect including that the track is left unarmed, and the 600-second cap. It omits what happens on failure (transport not running, no armed track) and whether the write is undoable.

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

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

Three tight sentences, front-loaded with purpose then the confirmation gate then the optional behaviors. Phrasing like 'which should mean the user asked for it' is slightly loose but conveys a useful semantic about what confirm 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?

For a 5-parameter mutation tool with no annotations and no output schema, the description covers the essential call-correctly information: gating, mode selection, side effects, and the stop condition. The remaining gap is error/return behavior and the undocumented `precount` flag, 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 already 80%, and the description adds real meaning on top: `from` accepts seconds or bar positions, `seconds` is optional and its absence means indefinite recording, and `track` is armed then left unarmed. Only `precount` is left 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 and resource: recording a new take into the running Studio One song. It is clearly distinguishable from read-only siblings like live_takes or live_transport, though it doesn't name the nearest alternative, live_record_setup, so the agent must infer the split.

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 hard precondition (confirm: true, which should mean the user asked for it) and describes the two operating modes: stop after `seconds`, or record until live_transport stop. It stops short of saying when to use this versus live_record_setup, which is the main nearby ambiguity.

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 load and does so well: it discloses that record modes cannot be read back and are reported as set rather than confirmed, that setting punchFrom/punchTo repurposes the loop range without enabling looping, and that punch-out is not independently readable once punch-in is on. It does not cover permission or state-reset behavior, keeping it short of a 5.

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

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

Front-loaded with the no-argument read behavior, then set behavior, then caveats; every sentence is informational. The paragraph is dense and slightly run-on, but 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 13-parameter, output-schema-less, annotation-less mutation tool, the description covers inputs and even sketches the result payload ('shows punch-in and whether any autopunch is on'). Only error/failure behavior is left 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 coverage is only 23% across 13 params, yet the description accounts for nearly every one and adds meaning the schema lacks: punchFrom/punchTo as seconds-or-bars positions, precountBars as a bar count, and the grouping of replace/loopTakes/loopMix/takesToLayers/inputQuantize/noteErase as record modes. It explains the semantics of the punch range rather than restating 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?

States a specific verb+resource: reads and sets recording/metronome and auto-punch configuration in the running Studio One. Scope is clear enough to separate it from live_record (capturing takes) or live_set_loop, though no sibling is named explicitly.

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

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

The 'with no arguments, reads the metronome' clause tells the agent exactly how to use it as a getter versus a setter, which is the main branching decision. It gives no explicit exclusions or pointers to overlapping siblings such as live_set_loop, which handles the loop locators this tool touches.

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 does real work: it discloses that the operation targets the running application (in-memory, not the saved song) and that it is a single-step undoable mutation, which is exactly the risk information an agent needs. It stops short of describing failure behavior when the marker reference is invalid or when the new name collides with an existing one.

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 action and scope, with the undo note last. Nothing is repeated from the schema 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 two-parameter tool with no output schema and no annotations, the description supplies the essentials: what it mutates, where, and how to reverse it. Remaining gaps are edge-case behavior (invalid reference, duplicate name) rather than anything blocking a correct first call.

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

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

Schema coverage is 0%, so the description must compensate, and it does for the ambiguous parameter: it explains that 'marker' accepts either an integer index (per live_markers numbering) or the marker's current name, resolving the anyOf that the schema leaves unexplained. The 'name' parameter is only implicitly characterized as the new name, not as a replacement value constrained to be unique.

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

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

States a specific verb and resource (rename a marker) plus the target environment (running Studio One), and clarifies the identifier forms accepted. It also names live_markers as the source of the numbering scheme, so it is distinguishable from live_add_marker and live_delete_marker without opening any schema.

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

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

Usage is implied rather than stated: it signals the tool acts on a live session and that live_undo is the reversal path. It never says to call live_markers first to discover valid indexes, nor when to prefer renaming over deleting and re-adding a marker.

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 supplied, the description carries the full burden and does the important part: it discloses that the tool mutates the song, acts on selection state, and that most (not all) edits are reversible via live_undo. It does not describe what happens when the title does not match a known macro or what the call returns, which leaves a behavioral gap for a mutation tool.

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

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

Three sentences, front-loaded with the action and resource before the caveats. Every clause earns its place: the example disambiguates title format, the selection note prevents a common misuse, and the undo note bounds risk.

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, no-annotation, no-output-schema mutation tool, the definition covers the essentials an agent needs: how to name the macro, what it acts on, that it edits the song, and how to undo. The main remaining gap is error/not-found behavior and the shape of the result, which the description only partially implies through check_only.

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 for both parameters: title is sourced from live_macros and shown in concrete format via an example, and check_only is explained as a report-enabled-without-running flag. Matching behavior (exact vs. fuzzy title resolution) is left unspecified.

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 ("Run a Studio One macro by title") and anchors the title to its source tool, live_macros, which cleanly separates it from sibling live_macros (enumeration) and live_command (single command). The concrete example macro name makes the resource 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?

Gives real preconditions — macros usually act on the current selection, with explicit pointers to live_select_events / live_select_track — plus a check_only mode for a no-op availability check and live_undo for reversal. It stops short of stating when to prefer this over live_command for a single command, so no explicit exclusion is offered.

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?

With no annotations supplied, the description carries the full behavioral burden, and it does disclose the key side effect: the existing selection is replaced unless exclusive is false. It stops there, saying nothing about failure behavior when the exact name does not match, whether the call errors or no-ops, or what the call reports back.

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 no filler; the action and the downstream consequence are front-loaded before the selection-replacement caveat.

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 is the only place an agent could learn what a successful selection returns or how an unmatched name surfaces. For a selection-mutating tool with no annotations, the definition is adequate but leaves those two questions 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 only 33% — name and exclusive are undocumented in the schema — and the description compensates by defining the matching rule (exact name) and spelling out exclusive's meaning in prose. Only kind's collision-disambiguation role is left entirely to the schema enum description, so minor gaps remain.

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 by exact name") plus the execution context ("running Studio One"), and links the action to its downstream consumer (live_command). It does not differentiate itself from the other look-alike selector in the sibling list (live_select_events), 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 phrase "so that selection-based commands (live_command) act on it" implies the workflow context for calling this tool, which is more than nothing. However, it never says when to use this instead of live_tracks or live_select_events, nor what to do when the track is not present, so usage is only implied rather than stated.

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

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

No annotations are supplied, so the description carries the full burden. It implies a read by describing returned fields, but never states read-only semantics, whether it requires a running Studio One instance (only hinted by 'the running Studio One'), what happens if no session is open, or whether the call has any side effects.

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

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

A single compact sentence with no filler, and the returned fields are listed inline. The colon-and-list construction is slightly awkward and the scope qualifier could be front-loaded more cleanly, but nothing is wasted.

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

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

With no output schema and no annotations, the description partially compensates by enumerating the returned fields (destination, level, mute) and the level range. It still leaves the channel identifier format, read-only nature, and failure behavior unspecified, which matters for a session-dependent tool.

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

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

Schema coverage is 0% and the single 'channel' parameter is an untyped string in the schema. The description adds real meaning by indicating that omitting channel yields sends for every channel while supplying one narrows to a single channel, but it does not explain the expected identifier format (name, index, or ID).

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

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

The description names the resource (sends on mixer channels) and the data exposed (destination, level, mute), and notes the single-channel variant. However, it is phrased as a noun fragment rather than a verb+resource, so it never explicitly says it reads/lists sends; an agent could momentarily confuse it with live_set_send or live_add_send, which are not mentioned.

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 statement and no named alternative. The parenthetical '(or one channel)' implies you can scope to one channel, but nothing says when to prefer this over live_add_send/live_set_send or live_channels, and there are no prerequisites or exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It usefully explains that touch, latch, and write record fader and plug-in moves while the song plays and that the tool returns before/after, but it does not clarify overwrite risks, permissions, transport prerequisites, or what happens to existing automation.

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

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

The description is short, front-loaded with the core action, and contains no wasted wording. It packs mode enumeration, key behavioral context, and return behavior into a compact statement.

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

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

For a simple two-parameter mutation tool with no annotations and no output schema, the description covers the main purpose, mode semantics, and that a before/after result is returned. It remains incomplete because channel identification is unspecified and important mutation side effects are not addressed.

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 needs to compensate. It gives partial meaning for the mode values by explaining touch, latch, and write behavior, but it leaves read and off unexplained and gives no guidance on how the channel string should be identified.

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: setting a mixer channel's automation mode. It enumerates the modes and explicitly points to live_channels for viewing mode values, which helps distinguish this tool from the read-only 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 parenthetical about live_channels implies when to use that sibling for checking modes, but the description does not explicitly say when to use this tool versus alternatives such as live_write_automation. Usage is mostly inferable from the purpose rather than stated as guidance.

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

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

With no annotations, the description carries the full behavioral burden and does add real value: exact value domains for volume/pan versus the boolean-ish fields, and the promise that a before/after pair is returned. It omits whether the mutation is undoable, what happens if the channel label does not match, and whether changes are persisted to the song or only live in the mixer.

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, front-loaded sentences with no filler; the purpose leads and the value semantics follow immediately. 'Returns before/after' is terse to the point of ambiguity about what is actually returned.

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-required-parameter live mutator with no annotations and no output schema, the description covers the value contract well but leaves the return shape ('before/after' of what) and failure behavior undefined. Adequate to invoke correctly, incomplete for predicting the result.

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

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

Schema coverage is only 33% and the schema types 'value' as a bare number, so the description's normalisation rules (volume/pan 0..1, pan 0.5 = centre, mute/solo/recordArmed/monitor 0 or 1) carry the critical semantics and directly compensate for the coverage gap. 'channel' is only explained by the schema, and the description adds nothing about whether the label is case-sensitive.

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 — 'Change one mixer channel in the running Studio One' — with the scope qualifier 'one' making clear it is a single-channel, single-field setter. It never names the adjacent siblings (live_set_send, live_set_plugin_param, live_set_automation) that also write values, so sibling 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?

'in the running Studio One' implies a live-connection prerequisite, which is useful usage context. There is no explicit when-to-use versus alternatives guidance, no note that one call changes exactly one field, and no guidance on what to do for multiple channel 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 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 carries the full burden and does well: it discloses the return payload ('before/after') and states the change is reversible by re-setting the 'before' value. It does not say whether the change is immediate/audible, whether it applies to a live mixer or saved state, or what happens on invalid input.

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 compact sentences, front-loaded with the action and followed by the value-mode rule and the return/revert behavior. No filler, and the mutual-exclusivity constraint is stated explicitly with 'exactly one of'.

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 the critical unknowns: value encoding, return shape, and rollback. Remaining gaps (error behavior, whether 'slot' indexes inserts, unit expectations per parameter) are minor but real.

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

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

Schema coverage is 0%, so the description must compensate, and it does for the hardest part: text vs normalized (0..1) vs value (raw within min..max) are given precise semantics plus concrete examples ('4.0:1', '-12 dB', 'Standard'). It leaves 'slot' and 'param' unglossed, so an agent must infer that slot is an insert index.

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

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

States a specific verb and resource: 'Set one plug-in parameter on a channel in the running Studio One', and scopes it to a single parameter so it cannot be confused with batch tools like live_plugin_params or live_plugin_snapshot. It also names the sibling that supplies parameter names.

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?

Points the agent at live_plugin_params as the source of the names it needs, which is the key prerequisite, and explains the three mutually exclusive ways to supply a value. It does not state when to avoid this tool (e.g. use live_set_automation for automation curves), which keeps it below 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 supplied, so the description carries the full burden. It does disclose that the target must be a 'running' Studio One instance (live connection required), that level is bounded 0..1 (stricter than the schema), and that level/mute are applied 'and/or' (partial update). It does not state what happens on an invalid channel or index, whether omitted fields are left untouched, or whether the change is undoable via live_undo.

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 action front-loaded and the range constraint attached directly to the parameter it governs. The trailing parenthetical is slightly awkward in placement but adds needed provenance information with no wasted prose.

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

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

For a mutation tool with no annotations, no output schema, and 0% schema description coverage across four parameters, the description is on the thin side. It covers intent and the level range but omits error behavior and result, which an agent needs to call and recover from this write operation 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 coverage is 0%, so the description must compensate. It adds real meaning for 'level' (0..1 range, absent from the schema) and for 'index' (provenance from live_sends), and maps 'mute' to the muted flag. It says nothing about the format or identity of 'channel' (name vs. path vs. id), leaving one of the two required parameters ambiguous.

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

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

Names a specific verb (Set) and resource (send level and/or mute on a channel), scoped to the running Studio One instance. It is distinguishable from live_sends (read) and live_add_send (create), though it never names those siblings explicitly.

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

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

The parenthetical '(index from live_sends)' implies the prerequisite that the index must be obtained from live_sends first, which is useful ordering guidance. However, there is no explicit when-to-use or when-not-to-use guidance relative to live_add_send or live_set_channel, so the agent must infer the boundary.

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 add/duplicate are undoable ("each one live_undo"), that retrospective recall is limited to instrument tracks, and that takes do not wrap at the ends. It still omits whether unpack is destructive or how it interacts with existing tracks, and says nothing about failure modes for an invalid take number.

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?

Everything is packed into one dense, front-loaded sentence that starts with the resource and then walks the action space, with no filler. The heavy parenthetical nesting makes it harder to scan than a short bulleted action list would be, but no sentence 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?

Even without an output schema, the description states what is returned (the number of takes and the names of clips now playing), which is what an agent needs to chain calls. Combined with the non-wrapping edge case and undo semantics, it is nearly complete; only per-action failure behavior and track-selection prerequisites are missing.

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

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

Schema coverage is only 33%, but the description compensates by explaining the take parameter as 1-based and only relevant for goto, tying it to the action enum, and by defining each of the eight action values in prose (including duplicate vs add). The track parameter itself gets no explanation beyond being implied by "A track's takes", which is a minor 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 ("A track's takes (layers) in the running Studio One") and enumerates the operations it supports (list, next/previous/goto, add, duplicate, unpack, retrospective), so the agent knows exactly what domain this tool covers. It does not explicitly name a sibling tool it supersedes or differs from (e.g. live_tracks, live_track_state), which keeps it 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 implied through the action list: goto needs a 1-based take number, add/duplicate each registers a live_undo, unpack splits takes into separate tracks, and retrospective applies to instrument tracks. However, there is no explicit guidance on when to choose this tool over neighbours like live_track_state or live_add_track, and no prerequisites (e.g. Studio One must be running, track must be selected) are stated.

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

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

With no annotations supplied, this description carries the full behavioral burden and does so unusually well: it discloses the side effect that the playhead is restored, the failure mode that Studio One has refused an undo immediately after a tempo edit, and the asymmetry that setting a segment back is exact. It stops short of describing what data comes back from 'at' or what error surfaces when the refused-undo case occurs, which keeps it below a 5.

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

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

Front-loaded and waste-free; the action enumeration comes first and constraints and warnings follow. The telegraphic style ('at: tempo at one or more positions') buys density at some cost in readability, and the parenthetical '(stopped)' in the opening line is never explained.

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

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

For a three-parameter mutation tool with no annotations and no output schema, this is close to complete: undo path, verification step, side effects, and sibling alternatives are all covered. Missing only the return shape of the 'at' action and the exact precondition implied by '(stopped)'.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: it explains that positions are seconds or bars like "9.1.1.0", that 'at' accepts one or more positions, and that 'set' defaults to the playhead. The notable gap is bpm — neither the schema nor the description says it is required for 'set'/'insert' or how it interacts with segment bounds.

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 the resource (the tempo map of the running Studio One) and enumerates every mode of the tool — 'at', 'set', 'insert' — with a specific verb for each, so an agent knows exactly what operation each enum value performs. It also names the sibling (song_read) that covers the whole saved map and time signatures, making it distinguishable at a glance.

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?

Explicit routing is present for the hard cases: removal must go through live_undo, 'and usually two steps' at that, with a stated verification procedure ('check with action at afterwards'), and whole-song or time-signature queries are redirected to song_read. It also states the default targeting behavior for 'set' (the playhead) so the agent knows a position is optional.

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 supplied, the description carries the full behavioral burden, and it does disclose one important trait: 'Each insert or remove is one live_undo', which tells the agent mutations are undoable atomically. It omits error behavior (e.g. removing a bar with no signature change), whether removing the initial signature is legal, and whether any permission or connection state 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?

The definition is compressed into three front-loaded clauses mapping directly to the enum values, with no filler or repetition. The grammar is telegraphic ('at: the signature in effect at positions'), which costs a little readability but earns its space.

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 five-parameter mutation tool with no annotations and no output schema, the description covers the operations and their parameters but does not describe the shape of what 'at' returns (e.g. a numerator/denominator pair, possibly multiple for a list of positions). Adequate, not complete.

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

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

Schema coverage is 0%, so the description must compensate, and it largely does: 'at' is defined as seconds or bars defaulting to the start, 'bar' is tied to insert/remove, and 'numerator'/'denominator' are scoped to 'insert'. It does not state validity constraints such as denominator being a power of two, which is the remaining 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?

The opening line 'Time signatures in the running Studio One' names the resource but supplies no verb, leaving the tool's nature (read vs write) to be inferred. The following clauses do name three concrete operations (at/insert/remove) with their payloads, which rescues the definition, but an agent must read past a vague headline to learn what it does.

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

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

The three mode clauses implicitly define when each is used: 'at' for querying the signature in effect, 'insert' for adding a change at a bar, 'remove' for deleting one. There is no explicit when-not guidance, no mention of prerequisites (a live Studio One connection), and no differentiation from related siblings such as live_tempo.

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 supplied, the description carries the full burden and does so: it discloses which actions are undoable ('remove, move, folder and renameEvents undo with live_undo'), which are not ('Rename and colour are not on the undo stack'), and how to reverse route by routing back to the 'before' channel the result gives. It also notes side effects an agent would otherwise not predict — the mixer channel is renamed with the track, a created folder is expanded so the track stays visible, and the track selection is kept. This is exactly the behavioral context annotations would normally provide.

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?

Every clause carries information and the key constraint (exact name, running Studio One) is front-loaded, so it is efficiently sized for seven actions. However, it is delivered as one long run-on sentence with nested parentheses and semicolons, which is hard to scan for an agent trying to map action to parameter. A short per-action structure would have cost no extra 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 an 11-parameter, seven-action mutation tool with no annotations and no output schema, the description covers undo semantics, prerequisites, side effects, and visibility. It is thin on failure behavior (what happens when the exact track name is not found, or when 'kind' is omitted and names collide) and on the shape of the returned result it twice refers to. Those are the only meaningful omissions.

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 already high (82%), so the baseline is 3, but the description adds real meaning: 'kind' is explained as the disambiguator when an audio stem and its MIDI render share a name, 'to' is a channel name, 'create: true' means create the folder if none exists, and 'numbered' produces (01), (02)… in time order. It also clarifies the before/after pair as a reorder anchor. Minor gaps remain (e.g., the exact 'track' matching rules beyond 'exact name').

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

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

The description opens with a specific verb+resource ('Edit a track by exact name in the running Studio One') and then enumerates all seven actions (rename, color, remove, move, route, folder, renameEvents) with a one-clause gloss for each. An agent can tell this is the track-mutation tool rather than a listing or event tool. It stops short of naming siblings it overlaps with (e.g., live_select_track, live_set_channel, live_edit_events), 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?

Usage is spelled out per action: rename targets the track and its mixer channel, move is explicitly top-level-only and not inside a folder, folder can create the folder with create: true, route takes a channel name. It also states the prerequisite that move/route/folder/renameEvents run through the 'MCP Track Edit task installed with the device'. There are no explicit exclusions or named alternatives for overlapping siblings, which keeps it below 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?

With no annotations, the description carries the full burden and does well: it discloses the return value, that a refused undo counts 0, and the non-obvious behavior that mixer parameter changes become late-recorded, merging undo steps. It omits whether undo is itself reversible or what a refusal means operationally (e.g., empty history vs. locked 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 the action and return value, then the caveat, then the corrective instruction. Dense but every sentence carries information; the parenthetical list of mixer parameters is slightly verbose but illustrative.

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

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

No output schema exists, and the description covers the return value and the tricky merge behavior, which is the main thing an agent could get wrong. The remaining gap is the undocumented 'steps' parameter, which leaves the caller guessing about multi-step semantics.

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, so the description must compensate and largely does not. 'Last edit(s)' hints at multi-step undo, but nothing explains the default, negative values, or the maximum range the schema allows.

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

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

The description opens with a specific verb and resource ('Undo the last edit(s) in the running Studio One') and states the return value ('returns how many ran'). It is clearly distinguishable from live_redo by the verb alone, though it 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?

It gives concrete operational guidance: check the result rather than counting steps, and 'Undo again until your edit is gone.' It explains the failure mode (mixer parameter changes recorded late and merging) that makes naive step-counting unreliable. It does not mention when to prefer live_redo or how to recover from over-undoing.

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 supplied, the description carries the full burden and discharges it: it explains why the operation is real-time (no API for envelope points), that the write is audible, that it overwrites existing automation in the range, that the channel is toggled to Write and left in Read, and that it is destructive to that parameter's curve. That is exactly the side-effect and reversibility information an agent needs before calling 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?

Densely front-loaded with the core action and payload formats first, then the behavioral explanation, then the alternative. Sentences are long and clause-heavy but each one carries distinct information; nothing 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-parameter, high-risk, unannotated mutation tool with no output schema, the description covers mechanism, side effects, preconditions and alternatives. It stops short of saying whether the write is undoable or what state remains if it is interrupted mid-range.

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%, but the description compensates by documenting the mutually exclusive point payloads ({at, db} in dB, {at, pan} -1..1, {at, value} 0..1) and by reinforcing the confirm constraint. 'channel' and the volume/pan meaning of 'parameter' are left to the schema, which is the only 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 and resource ('Write volume or pan automation on a channel'), names the parameter domain, and defines the point shapes inline. An agent can tell this apart from live_set_automation or live_events without opening any schema.

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

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

Gives a hard precondition ('Only runs with confirm: true') and routes a specific sub-case elsewhere ('For fades inside one clip, prefer live_events fade_in/fade_out'). It does not explicitly contrast with the adjacent live_set_automation sibling, which is the main remaining ambiguity.

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