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 must reveal behavior itself, and it does: 'One failure does not abort the rest' discloses partial-failure semantics, and 'Handles from earlier calls work later' reveals ordering and data-flow between entries. It does not cover the response/error envelope or side-effect characteristics of the underlying operations, but those belong to the delegated func rather than the batch wrapper.

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, each adding a distinct fact: what batching is, what a call looks like, and how failures/handles behave. No filler or repetition of 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 generic batcher with nested call objects, the description covers the key mechanics: batching, call shapes, failure isolation, and handle propagation. It omits an explicit example of the full calls array and does not describe the return envelope, which would be more important given there is no output schema. Still, an agent has most of what it needs to invoke batch 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?

The schema only lists bare property names at 0% description coverage, so the description supplies the meaning: args/code/arguments are alternative payload forms and func refers to a grouped tool name. This is enough to construct a valid call. However, it does not explain the schema's `action` string property, leaving a legitimate parameter without documented semantics.

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

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

The description opens with 'Many operations in one IPC hop', which establishes batch as a composite execution tool rather than a single operation like track or midi. It further specifies that each item is one of three shapes and is 'for a grouped tool name', so an agent can distinguish it from the individual sibling tools. It stops short of an explicit imperative verb like 'execute', but the intent is clear.

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

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

The description gives the core rationale for choosing batch ('many operations in one IPC hop') and implies grouping multiple operations to reduce round-trips. It does not explicitly say 'use this when you have multiple calls' nor does it name the alternative of calling individual tools. Selection guidance is therefore more implied than stated.

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

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

With no annotations, the description carries the behavioral burden; it does disclose the key mutation trait that 'set replaces all points' and clarifies the native value scale. However, it does not say whether list/get have side effects, what set does if points are omitted, or what the response/return behavior is.

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?

Several short fragments pack the action enum, name semantics, set semantics, and value scale without padding. The structure is slightly choppy ('Track envelopes' as an opener) but still front-loads the core operations and keeps the description scannable.

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 tool with no output schema and no annotations, this is incomplete: an agent cannot tell what list/get return, how envelope_index is obtained, or how track_index is interpreted beyond its name. The useful fragments are not enough to confidently call all three actions 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?

The schema has 0% description coverage, and the description compensates with useful meanings: name examples (Volume, Pan, Mute), native value scale (1.0 = 0 dB), and set's full-replacement effect on points. But it leaves required track_index and envelope_index semantics unstated, and the inner point fields (beats, shape, tension, selected) are only named in the schema.

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

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

The description names the resource (REAPER envelopes) and specifies the operations (list, get, set), so an agent can see this is an envelope-management tool. It is not as crisp as a one-line 'Manage REAPER envelope automation points' and doesn't explicitly contrast with sibling tools, but the action enum makes the purpose 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?

There is no guidance on when to choose envelope vs sibling tools (track, item, action, project) or when to use list vs get vs set. The only conditional hint is 'set replaces all points,' which is a behavior, not a usage rule. An agent must infer usage from parameter names.

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 transparency burden. It discloses valuable semantics such as -1 representing the master track and the normalized 0..1 range for set, but it does not explain side effects of delete, bypass, or add, or whether operations are destructive. This is partial transparency, not a full behavioral profile.

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

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

The description is compact and front-loaded: the action list appears first, followed by the two most important numeric semantics. Apart from the slightly redundant 'Track FX.' opener, every sentence contributes usable 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 tool with 8 actions, 9 parameters, no output schema, and no annotations, the description is materially incomplete. It lacks per-action parameter requirements, return behavior for list/params, and semantics for dest_index and preset, so an agent would need trial and error or outside knowledge.

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

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

The schema has 0% description coverage and 9 parameters; the description only adds meaning for action, track_index (-1 = master), and value (REAPER normalized 0..1). It leaves param, preset, enabled, fx_name, fx_index, and dest_index undefined, and never maps which parameters belong to each action, so an agent cannot reliably construct a call.

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 FX) and enumerates eight concrete actions, so an agent can tell this tool is for manipulating effects rather than transport, items, or sends. It is terse and the opening phrase borders on restating the tool name, but the action list gives it real definition.

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

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

There is no explicit guidance about when to use fx versus sibling tools like send, track, or item; the need is only implied by the resource name and action list. The description does provide two operational rules (track_index -1 means master, set values are normalized 0..1), but no exclusions or 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 disclosure burden. It adds useful unit context ('fade_in / fade_out are seconds', 'position/length are beats') and names the two actions, but it does not disclose update side effects, mutability of fields, output shape, or error behavior.

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

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

The description is two short sentences with no filler; the action list and unit clarifications are front-loaded. It is concise and readable, though slightly terse given the tool's complexity.

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 10-parameter, two-action tool with no annotations and no output schema, so the description must carry substantial weight. It does not explain which optional properties apply to update, what list returns, or how item_index resolves relative to track_index, leaving important 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%, and the description partially compensates by explaining fade units, position/length units, and action values. However, it leaves mute, loop, gain_db, item_index, and the track_index relationship undocumented, so parameter meaning 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 identifies the resource ('media items on a track') and the supported actions ('list | update'), giving a clear verb+resource mapping. It distinguishes the tool from sibling concepts like track or midi, though it does not explicitly contrast itself with them.

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

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

No guidance is given about when to choose this tool over alternatives such as track, midi, or reaper_call, nor when to use list versus update. The description implies usage through the resource phrasing but never states selection criteria or exclusions.

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

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

No annotations are provided, so the description must carry behavioral disclosure itself. It does disclose two meaningful behaviors: replace rewrites the whole take in one undo step and add only appends, plus the time unit. However, it leaves the side effects and return behavior of get/update/delete/create_item unstated.

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

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

The description is compact and front-loads the resource and action enum before the key caveat. Every sentence adds either domain context or behavior, with no filler.

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

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

Given 12 parameters, no output schema, and no annotations, this is far too thin to guide correct invocation. It does not specify required parameters per action, return/output shape, or whether flat note fields are alternatives to the notes array.

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

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

With 0% schema description coverage, the description is responsible for explaining parameters, but it only clarifies that time values are in absolute project beats and lists action values already in the schema. It does not explain roles of notes, note_indices, item_index, muted, pitch/channel/velocity, or which parameters apply to which 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 identifies MIDI as the resource and enumerates six concrete actions, so an agent can tell this is the MIDI editing tool rather than sibling tools like item or track. There is no single explicit verb, but the action list makes the purpose 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 some within-tool guidance by distinguishing replace (rewrites whole take in one undo step) from add (appends), and it states that times are absolute project beats. It does not say when to prefer midi over sibling tools, nor does it specify prerequisites such as needing an existing track/item for certain 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?

There are no annotations, so the description must carry the behavioral disclosure burden. Saying 'edits' signals mutation but does not explain side effects, destructiveness, dependencies between actions, or what happens to existing 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?

The text is tightly written, front-loaded, and contains no wasted words. However, it is under-specified for a tool with ten parameters and four action modes, so its brevity reflects incompleteness rather than well-judged scoping.

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

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

With no annotations, no output schema, and 0% parameter coverage, the description needs to supply substantial context but only provides a phrase and an action list. It gives minimal orientation but is not sufficient to invoke the tool correctly across its different actions.

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

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

Schema description coverage is 0%, and the description adds no parameter semantics beyond repeating the action enum that already exists in the input schema. It does not map bpm, numerator/denominator, start/end_beats, or position_beats to the relevant actions, so an agent cannot determine which parameters apply to which 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 states the resource (project) and the operation class (edits), then enumerates the four edit actions: tempo, time_signature, time_selection, and marker. This gives an agent a concrete sense of what the tool does, though it does not explicitly contrast it with sibling 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?

No guidance is provided for when to use this tool versus siblings such as track, item, reaper_call, or run_lua. The action list implies project-level usage, but the description does not specify conditions, exclusions, or alternatives.

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

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

No annotations 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?

The description discloses two important behavioral traits: 'No undo' and 'Long timeout'. However, with no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that rendering is a potentially expensive or blocking operation, whether it overwrites files, what happens on failure, or whether it requires specific project state. The 'No undo' warning is useful but incomplete.

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

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

The description is very short and front-loaded with the key warning ('No undo') and the bounds enum. Every phrase carries some information, but the structure is telegraphic and could be clearer. It is concise but not well-structured enough to be a model of clarity.

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

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

Given 9 parameters, 0% schema coverage, no annotations, and no output schema, the description is far from complete. It does not explain the return value, the effect of each parameter, or the rendering workflow. The 'No undo' and 'Long timeout' warnings are valuable, but an agent would still be guessing about most parameters and the overall 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 for the 9 undocumented parameters. It only explains 'stems' and 'track_indices' partially, and lists 'bounds' enum values without explaining their meaning. Parameters like 'pattern', 'channels', 'end_beats', 'sample_rate', and 'start_beats' are completely unexplained. The description adds some value for stems/track_indices but leaves most 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?

The description starts with 'Render' as a verb, which identifies the core action, and lists the bounds enum values. However, it does not explicitly state what 'render' produces (e.g., audio file export) or what resource it operates on beyond the bounds options. It is distinguishable from siblings like 'transport' or 'midi' but not clearly differentiated from a generic render operation.

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

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

The description gives a brief hint about stems=true and track_indices, but it does not explain when to use this tool versus alternatives like 'batch' or 'run_lua'. There is no mention of prerequisites, typical use cases, or when not to use it. The guidance is minimal and mostly assumes the agent already knows when rendering is appropriate.

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 present, so the description carries the disclosure burden. It adds useful behavior: the `reaper` global is in scope and returning a value sends it back. However, it does not mention side effects, error behavior, or whether execution can mutate the project.

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

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

Two sentences, front-loaded with the core action, and every clause earns its place. The sentence about round-trips is the only non-essential but still useful guidance.

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

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

For a single-parameter code-execution tool with no output schema, the description covers the environment, the output mechanism, and the intended use case. The main gaps are error handling and explicit side-effect warnings, but an agent has enough to invoke it 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 has one `code` string with no description (0% coverage), so the definition must add semantics. It clarifies that `code` is a Lua snippet, that `reaper` is available inside it, and that `return` is the output mechanism. This is meaningful but still omits examples or return serialization details.

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 action ('Run'), a precise resource ('Lua snippet inside REAPER'), and a scoping detail ('reaper in scope'). The 'multi-step work... round-trips' line separates it from single-call siblings like reaper_call.

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 frames use as 'Best for multi-step work that would otherwise be many round-trips,' so an agent knows when to prefer it. It does not name sibling alternatives or state when not to use it, but the context is clear enough.

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 clarify that track_index is the source (-1 master) and dest_index is the destination track. However, it is silent on return values, side effects, and action-specific behavior such as which parameters are required for delete versus update.

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 action variants and the two key index parameters. The opening 'Track sends' is somewhat ambiguous, but the structure wastes little space and is easy to scan.

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

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

For a 7-parameter tool with no annotations and no output schema, this description is incomplete. An agent lacks essential context about action-specific parameter requirements, what send_index refers to, and what result is returned by list/add/delete/update.

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

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

Schema description coverage is 0%, so the description must compensate, but it only explains track_index and dest_index. Critical parameters like send_index, pan, mute, and volume_db are left to name inference, and send_index is especially important for identifying which send to delete or update.

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 (sends) and enumerates the supported operations via the action field, so an agent can see this tool manages sends on tracks. It does not use an explicit verb+object phrasing like 'manage audio sends,' but the action enum resolves most ambiguity. It does not explicitly differentiate from sibling tools, but the resource is distinct enough.

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

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

No when-to-use guidance or alternative tool comparisons are provided. The description implies the tool is for send routing, but it does not state when to prefer this over track, fx, or other siblings, nor does it explain prerequisites for add/update/delete.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only 'check' but does not state side effects, failure behavior (e.g., what happens if the bridge is not connected), or whether any state is modified. This is a significant gap for a tool that is presumably the first point of contact.

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 short sentences, each earning its place: the first states what the tool does, and the second tells the agent when to call it. It is front-loaded and free of 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 zero-parameter tool, the description adequately covers its purpose and the critical 'call first' usage. There is no output schema, but the description explicitly lists the returned items, so an agent knows what to expect. It lacks deeper context about output formatting, but that is minor for such a simple tool.

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

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

The input schema has zero parameters with 100% coverage, and the description adds no parameter-related confusion. Baseline for 0 params is 4, and the description correctly focuses on the output rather than nonexistent inputs.

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

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

The description clearly states a specific action ('Check the Lua bridge') and the exact data returned ('project tempo, play state, and tracks'), distinguishing it from action-oriented siblings like transport or track. This leaves no ambiguity about the tool's role.

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?

'Call first' provides a clear when-to-use instruction, establishing it as a prerequisite for other tools. However, it does not mention alternatives or when not to use it, so it lacks the explicit exclusions needed for 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 responsibility for behavioral disclosure. It does explain the bus behavior ('creates a submix and routes source_indices') and the update field set, providing some transparency. However, it omits effects of delete, the meaning of index, and what responses look like, leaving significant behavioral gaps.

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

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

The description is concise (two sentences) and front-loads the action enum. It efficiently conveys the core operations and specific param mappings without fluff. The structure is logical, though it could be slightly clearer if each action had its own line or separators.

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

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

Given 8 parameters, 5 actions, and no output schema, this description is incomplete. It fails to explain the index parameter, describe the result of delete or list (e.g., return format), or mention any side effects or prerequisites. The agent would need external knowledge to use this tool correctly for non-update/bus actions.

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

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

With schema description coverage at 0%, the description is the sole source of parameter meaning. It explains name, volume_db, pan (with range), mute, solo for update, and source_indices for bus, but leaves index completely unexplained and doesn't clarify the role of all params across other actions. Partial coverage merits a middle score.

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

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

The description clearly states the resource (track) and the specific operations (list, add, delete, update, bus) with a brief summary of what each does. It is specific enough to distinguish track operations from sibling tools like transport or midi, though it doesn't explicitly contrast with siblings.

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

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

The description provides no guidance on when to use this tool vs alternatives, such as action or fx, nor does it state prerequisites or exclusions. It merely enumerates the actions and their parameters, leaving the agent to infer the tool's scope from the resource name.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It names actions but does not describe their effects (e.g., whether 'record' starts or toggles recording, what 'goto_start' does to playback state, or side effects like project state 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 exceptionally brief and front-loads the purpose, with no fluff or redundant prose. The action list is redundant with the schema but arranged clearly.

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 control tool, the description still leaves critical gaps: no explanation of action semantics, no output/return expectations, and no preconditions (e.g., whether a project must be open). An agent cannot reliably decide which action to invoke without more context.

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

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

Schema description coverage is 0%, so the description must compensate. It merely repeats the enum values from the schema without adding meaning—'toggle_repeat' and 'goto_start' are left to the agent's inference, and the description does not explain the purpose or expected behavior of each 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 states 'Playback control' and lists six transport actions, giving a general sense of purpose. However, it is vague about the resource (e.g., DAW transport, project) and does not differentiate from siblings like 'action' or 'status'.

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

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

No guidance is provided on when to use this tool versus the listed siblings. There is no mention of alternatives, preconditions, or scenarios where a different tool would be more appropriate.

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