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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action (run a command) but doesn't disclose side effects, whether the command may be destructive, require specific REAPER state, or return any output. For a tool that can execute arbitrary REAPER commands, this is a significant gap.

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

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

The description is a single, focused sentence that front-loads the action and resource. Every word earns its place, and it avoids unnecessary elaboration.

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 that executes arbitrary REAPER commands, the description is thin. It lacks information about return values, error handling, side effects, and prerequisites. The output schema is absent, and the description doesn't explain what happens after the command runs. An agent would need external knowledge to use this tool safely and effectively.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that command_id is a numeric command id, which adds meaning beyond the bare integer type. However, it doesn't provide details like valid ranges, how to find command IDs, or whether the command ID is a native REAPER ID or a custom one. The description adds some value but leaves gaps.

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

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

The description states a specific verb ('Run') and resource ('REAPER Main_OnCommand by numeric command id'), which clearly identifies the tool's function. It distinguishes itself from siblings like run_lua and reaper_call by specifying the exact REAPER API function and input type, though it doesn't explicitly name alternatives.

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

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

The description implies usage: use this tool when you need to invoke a REAPER command by its numeric ID. It doesn't explicitly state when not to use it or mention alternatives like run_lua for scripts, but the context of sibling tools and the specific API reference provide some 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 meets it: it discloses there is no rollback, that failures do not abort the remaining calls by default, that stop_on_error=true skips later slots and marks them {skipped: true}, and that handles from earlier calls remain valid later. These are exactly the non-obvious traits an agent needs before composing a multi-call batch.

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 value proposition (one hop, one undo point) before the grammar details; nearly every sentence carries distinct information. It is dense but not padded, with only slight redundancy between the call-shape and handle-reuse statements.

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 complex multiplexer with no annotations and no output schema, the description covers call shapes, per-slot return values, error/skip behavior and cross-call handle reuse. The remaining gap is that valid 'func' values and the 'action' field are only gestured at rather than 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 coverage is 0%, so the description must explain the parameters, and it does for most: the three call shapes ({func, args}, {func: 'run_lua', code, timeout}, {func, arguments} for grouped names), plus stop_on_error semantics. It omits the 'action' property present in the schema, leaving one field undocumented.

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

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

The description states a concrete verb and resource: it runs many tool operations in one IPC hop and one undo point, and names the grouped sibling namespaces (track/midi/fx) it can dispatch into. That differentiates it from calling those sibling tools individually, though the generic name 'batch' alone would not.

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 benefit (single IPC hop, single undo point) implies when to prefer it over individual calls, but the description never says so explicitly and gives no when-not guidance or named alternative. Usage must be inferred from the stated benefits.

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

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

With no annotations, the description carries the behavioral burden and does disclose important side effects: set replaces all points or only points in a range, every new point must lie inside that range, and set re-activates an inactive envelope. It does not cover every possible behavior, such as permission needs or return shapes, but it is substantially transparent for a mutation-capable tool.

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

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

The description is dense but front-loaded with the action modes and key semantic details. Every sentence carries useful information, though the long run-on style makes it slightly harder to scan.

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

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

For an 8-parameter tool with nested point objects, no annotations, no output schema, and no schema descriptions, the definition covers the most important operational semantics. It remains incomplete because it leaves required track_index, envelope_index, and several point-level fields 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 description coverage is 0%, so the description must compensate for undocumented parameters. It adds useful meaning for name, value, unit, start_beats, and end_beats, including gain/dB semantics and range inclusion rules, but it omits explanation of required track_index and envelope_index and does not describe the point object fields such as shape, tension, or selected.

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 (track envelopes) and the three operations (list, get, set), with additional detail about point replacement and ranges. It is clear enough to distinguish the tool from unrelated siblings, but it does not explicitly differentiate it from nearby tools such as track or send.

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

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

The description explains the modes of action=list/get/set and clarifies how set and get behave with start_beats/end_beats ranges. However, it gives no explicit guidance on when to choose this tool over sibling tools like track, send, or item.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does a good job on 'set' semantics — normalized 0..1 vs formatted display-text values, and that set returns the formatted value actually set. But for mutations like delete, add, bypass and move it says nothing about required permissions, reversibility, or side effects, which is a meaningful gap for a tool with destructive capabilities.

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 reasonably compact with no filler, and it front-loads the action list. But it is a single dense run-on paragraph with no separation between action enumeration, per-action notes, and set semantics, which makes it harder to scan than a structured multi-line definition.

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 11 parameters, 8 dispatched actions and no output schema or annotations, the description is not complete enough. It never maps parameters to actions, so an agent cannot tell from the description that add needs fx_name or move needs fx_index/dest_index, and the absence of any delete/bypass transparency is a real risk.

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

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

Schema coverage is 0% across 11 parameters, so the description must compensate and only partly does. It clarifies the trickiest ones well — filter (case-insensitive part of parameter name), track_index (-1 = master), value (0..1 normalized) and formatted (display string like '3.2k'). It leaves preset, enabled, fx_name, fx_index, dest_index and the action-specific parameter requirements undocumented.

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

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

The description states the resource (Track FX) and enumerates all eight actions, which makes the tool's scope clear and distinguishes it from siblings like item, envelope, track and send. It isn't a full verb+resource statement like 'manage effects on a track' but the enumeration is functional. An agent can identify it as the FX tool without opening the schema.

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

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

The description gives some action-specific usage: 'params takes filter' to narrow results, 'track_index -1 is the master', and how 'set' resolves values. However, it never explains when to use a given action, what each of add/delete/bypass/move/preset requires, or when an agent should prefer this tool over siblings. Usage is implied by the action enum rather than guided.

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

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

With no annotations, the description carries the full behavioral burden and does well: it states split returns piece item_indices, duplicate is unpooled, dest_track_index returns new indices, import requires a host-local path, and item indices follow position so re-listing is needed after moves. It stops short of covering permissions, error behavior, or destructive warnings.

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 dense but appropriately sized for 20 parameters and six actions, and it is front-loaded with the resource and action list. It would be easier to scan as a bulleted action list, but every sentence adds actionable 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 20-parameter, multi-action tool with no annotations and no output schema, the description is largely complete, covering action semantics, units, side effects, and index behavior. The main gaps are the undocumented start_beats and track_index parameters, plus no mention of error or permission behavior.

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

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

Schema description coverage is 0%, so the description must compensate and largely does: it explains units (beats vs seconds for fades), update fields (gain_db, fades, loop, mute, position_beats, length_beats, left_edge_beats, dest_track_index, active_take), split's at_beats, delete's item_index/indices, duplicate's position_beats, and import's path/as_new_track. It omits start_beats and track_index, leaving two parameters with no semantic explanation.

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

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

The description opens with 'Media items on a track' and enumerates the six supported actions (list, update, import, split, delete, duplicate), giving a specific resource and action set. It clearly distinguishes this tool from track-level siblings by scope, though it never names an alternative tool 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?

Each action has clear usage context: split cuts at at_beats, delete takes item_index or item_indices, duplicate copies the item to position_beats by default, and import uses a path on the REAPER host. It lacks explicit when-not-to-use guidance or sibling-tool routing, but the per-action context is strong enough for correct selection.

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

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

With no annotations, the description carries the full burden, and it does disclose two valuable traits the schema cannot: replace's whole-take rewrite in one undo step, and get's omission of zero/false fields in the response. It says nothing about delete being destructive/irreversible, permission or track-item preconditions, or failure modes, which is a meaningful gap 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?

It is a single dense block with the action list front-loaded and no filler sentences; the replace/add and cc/get_cc contrasts each earn their place. It is terse to the point of being terse over telegraphic, but nothing is redundant.

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

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

For a 13-parameter, 8-action tool with no annotations, no output schema, and 0% schema coverage, the description is far from sufficient: an agent cannot learn the per-action parameter contract or the response shape for notes/CC reads. What is present is high value but covers a minority of the calling surface.

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

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

Schema description coverage is 0%, so the description must document the 13 parameters; it only clarifies that times are absolute project beats and explains the ccs[] shape (cc+value or program). notes[], pitch, velocity, length_beats, note_index, note_indices, item_index and track_index go entirely undocumented, and it never says which parameters are required per action.

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 ('MIDI on a track item') and enumerates all eight actions supported by the action enum, so an agent can see this is a multi-op MIDI note/CC manipulation tool. It does not disambiguate against siblings (e.g. item), but no sibling appears to overlap in MIDI domain, so the boundary is reasonably 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?

It explicitly contrasts replace vs add ('replace rewrites the whole take in one undo step; add only appends') and pairs cc with get_cc, which are real usage choices. However, nothing tells the agent when to choose create_item vs add vs update, or what preconditions exist (item must already exist, track must have a MIDI item), leaving the biggest routing decision implicit.

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

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

No annotations are provided, so the description carries the full burden. It does this well for save — creating missing folders, writing a copy with no dialog, an untitled project adopting the path, and the precondition that save-without-path needs a named project — but the other four actions receive no behavioral disclosure at all (no indication of whether they overwrite existing tempo/markers or how they fail).

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 action list appears before the save caveats. The telegraphic style ('save with path...') is dense but every clause carries operational meaning.

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 multiplexed tool with five actions and eleven parameters, no annotations, and no output schema, the description covers only the save path. It leaves which parameters belong to which action and what each non-save action returns entirely to inference, which is inadequate for 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 description coverage is 0% across 11 parameters, and the description explains only the action enum and the role of path for save. It never maps bpm, numerator/denominator, start_beats/end_beats, position_beats, region_end_beats, is_region, or name to their actions, so the agent must guess the action-to-parameter association.

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 title-like sentence 'Project-level edits' is weak on its own, but the action enumeration (tempo, time_signature, time_selection, marker, save) precisely delimits what this tool touches, so an agent can tell it edits project-level attributes rather than items, tracks, or fx. It never names a sibling to differentiate against, so it stops short of a 5.

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

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

Usage is implied through the action list rather than stated: an agent must infer that this is the tool for setting tempo, time signature, time selection, and markers. Conditional guidance exists only for save ('with path' vs 'without path'), and there is no statement of when to prefer a sibling such as transport or action instead.

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. While the description does explain pointer return format ({"__handle":"hN"}) and hints that handles can be passed back in, it omits key behavioral details: what happens if the function doesn't exist, whether calls are synchronous, whether they mutate project state, or error behavior. Since this can execute arbitrary ReaScript functions, the lack of safety/behavioral disclosure is a significant gap.

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

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

Highly concise: two sentences plus an example. The core purpose and pointer format are front-loaded, and the example is illustrative without extraneous content. Every sentence earns its place.

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

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

For a generic function-calling tool, the description gives the essential call pattern and pointer handling, but it lacks crucial operational context: no error handling, no mention of argument serialization rules, no discussion of side effects, and no differentiation from sibling tools like run_lua. With no annotations and no output schema, the description should do more to cover these gaps.

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

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

Schema description coverage is 0%, so the description must compensate for the bare schema. It does explain func as a ReaScript function name and args as the argument list, with an example (CountTracks with arg 0). However, it doesn't clarify what argument types are supported, how args map to ReaScript parameters, or what the pointer handle string structure means beyond an example. It adds some meaning but leaves ambiguity for arbitrary functions.

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

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

The description states a specific action (call any ReaScript function by name) and resource (ReaScript functions in REAPER). It also shows an example invocation with func and args. However, it doesn't explicitly differentiate from sibling tools like run_lua, which also executes scripts, leaving some ambiguity about when to use reaper_call over run_lua.

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

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

No guidance is given on when to use this tool vs alternatives such as run_lua or project tools. The sibling context includes run_lua, which could overlap significantly, and the description provides no criteria for choosing between them. It also doesn't mention constraints on function names, argument types, or error behavior.

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: no undo, long timeout, media brought online first unless media_online=false, refusal on existing files because REAPER's overwrite prompt would hang the bridge, and solo/mute restored afterward. The only gap is that it doesn't quantify the timeout or describe failure/timeout behavior beyond the hang rationale.

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 critical facts ('Render. No undo. Long timeout.') followed by bounds and output mapping. Dense but nearly every sentence carries a distinct behavior; the parenthetical stacking around solo/mute and format makes it slightly 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?

No output schema exists, but the description supplies the return shape itself (files with path, bytes, length_sec, peak_db, lufs_i, plus warnings) and enumerates warning types. For a 16-param mutation tool this is close to complete; the unaddressed channels/sample_rate/beat-range params are the only shortfall.

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 across 16 params, and it does for most: path, pattern, bounds (all four enum values), stems, track_indices, media_online, allow_solo, solo_indices, mute_indices, measure, format, and bit_depth (with 32=float and mp3=320 kbps). It leaves channels, sample_rate, and start_beats/end_beats unexplained beyond the 'custom' bounds hint, which is why this is not a 5.

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

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

States the specific operation (offline render of the master mix, or stems with track_indices) and the artifacts it produces (files written to `path` using `pattern`). It is clearly distinguishable from siblings like action, run_lua, or project, which would not describe render-bound/stem semantics.

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 branch conditions: stems=true plus track_indices for stems; allow_solo/solo_indices/mute_indices when tracks are soloed; measure=false to skip the loudness scan; format to override the project format for this render only. It also states when the tool refuses (existing target file, soloed tracks) and how to proceed in each case.

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

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

With no annotations, the description carries the full behavioral burden and does so well: errors carry the failing line, the timeout stops a still-running Lua snippet but cannot interrupt a call blocked inside REAPER, work completed before the timeout remains done, and REAPER is frozen while the snippet runs. These are exactly the operational facts an agent needs before invoking arbitrary code execution.

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

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

The description is front-loaded with purpose and use case, then covers return values, errors, timeout behavior, and the REAPER-frozen caveat without filler. The longer timeout sentence is dense but every clause carries operational meaning.

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 non-annotated arbitrary code execution tool with no output schema, the description is nearly complete: it covers scope, return mechanism, error reporting, timeout limitations, and host freezing. A minor gap is that it does not specify how returned values are serialized or whether there are restrictions on return types.

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, and it does. It explains that `code` is a Lua snippet with `reaper` in scope and that `return` sends a value; for `timeout` it adds the default (10), maximum (600), and non-obvious semantics about what can and cannot be interrupted.

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: running a Lua snippet inside REAPER with `reaper` in scope. It also signals the tool's niche as multi-step work that avoids many round-trips, though it never names the sibling tools (e.g., reaper_call or action) it is meant to replace.

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

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

It clearly frames the best use case as multi-step work that would otherwise be many round-trips, and gives a concrete pattern for long host commands (start in background with io.popen and poll). It does not explicitly say when not to use this tool or name the dedicated sibling tools for single-step operations.

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 source/destination semantics and that the destination channel count is raised to fit routing, but it does not state that delete is destructive, permission/error behavior, or exactly what update changes.

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

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

The description is front-loaded with the resource and action set, then follows with routing details. It is dense but efficient, with little wasted text, though it could be structured more clearly for scanning.

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 description omits `send_index` entirely and says nothing about list output or error behavior. It provides valuable routing context but leaves material gaps for safe 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?

At 0% schema description coverage, the description must compensate, and it does explain action, `track_index`/master, `dest_index`, volume_db, pan, mute, mode, and src/dst channel routing. However, `send_index` is never mentioned and ranges/defaults are left implicit, so the compensation is incomplete.

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 (track sends) and enumerates the supported actions, so an agent can tell it manages send routing rather than tracks, items, or FX. It does not explicitly contrast itself with sibling tools, which keeps it from a 5.

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

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

The action enum supplies operation-level guidance and `track_index` is clarified with `-1 master`, but there is no explicit when-to-use vs alternatives or prerequisites for add/delete/update. Usage is implied by action names rather than actively guided.

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

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

With no annotations provided, the description carries the full behavioral burden. It discloses the returned fields and the extra detail mode, but it does not explicitly say this is read-only, whether the call has side effects, what happens if the Lua bridge is unavailable, or whether detail=true has performance costs.

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 dense but front-loaded, starting with the core action and then adding operational guidance and detail-mode behavior. The long list of returned fields is useful, though the single packed sentence makes it slightly harder to scan.

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

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

There is no output schema and no annotations, so the description needs to explain what the tool returns, and it does list the key fields and the expanded detail fields. It is reasonably complete for a status tool, though it omits error behavior and the default for detail.

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 single optional parameter, and it does: detail=true adds arrangement facts and lists what those facts include. It could be slightly stronger by stating the default value explicitly, but the meaning is clear.

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: it checks the Lua bridge and returns a concrete set of project, transport, selection, and dirty-state fields. It is clearly not a tautology, but it does not explicitly differentiate itself from sibling tools such as transport or project, so it falls just short of the top score.

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 usage context with 'Call first' and a specific operational caveat about clearing a lingering solo before rendering. It does not name alternatives or state when not to use this tool, so it is strong but not exhaustive.

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

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

With no annotations, the description carries full behavioral burden. It valuably discloses that bus disables the source tracks' direct send to the master/parent, but it does not warn that delete is destructive, describe return behavior, or state permissions/constraints.

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

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

The description is three compact sentences, front-loads the purpose and action list, then adds only the non-obvious update and bus details. Every sentence earns its place.

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

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

This is a complex multi-action tool with eight parameters, no annotations, and no output schema. The description adequately covers update and the tricky bus action, but leaves list, add, delete, and index semantics 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 compensate. It adds meaningful semantics for update fields, pan's -1..1 range, and bus's source_indices routing, but leaves 'index' unexplained and does not clarify parameter usage for add, delete, or list.

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 clear resource ('Track operations') and enumerates the five supported actions, so an agent can tell what the tool does. It does not differentiate the tool from siblings such as item, send, or fx, which is the main remaining gap.

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 lists actions but gives no explicit guidance on when to use this tool versus alternatives like send or fx, and no when-not conditions. The bus explanation is behavioral detail, not usage guidance.

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

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

With no annotations, the description carries the full burden; it does disclose an important side effect (goto moves playback when playing) and names the returned fields. However, it omits whether stop/record reset position or arm tracks, permission or project-state prerequisites, and error behavior for invalid markers.

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 purpose, then compact action semantics in a single pass with no filler. The deeply nested parenthetical makes the goto rules dense but every clause carries information.

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

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

For a 3-parameter, no-annotation, no-output-schema tool it covers the return shape and the trickiest parameter interaction, which is good. Gaps remain around action/parameter pairing, precedence when both targeting params are given, and failure modes, so it is adequate rather than 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; it does explain goto's two targeting modes (position_beats vs marker by number or name), which is the most confusing part. It still doesn't state that marker and position_beats are only meaningful for goto, what happens if both are supplied, or that position_beats is non-negative.

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 clear domain statement ("Playback control") and then enumerates the exact actions available, so an agent knows this drives play/stop/pause/record and cursor navigation. It clearly is not the same as siblings like status, action, or render, though it never names those siblings to reinforce the distinction.

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

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

There is no explicit statement of when to use this tool versus adjacent tools (status vs action vs transport), and no conditions or exclusions. The action list implies usage, but the only real guidance is about goto's targeting options, not about tool selection.

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