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

Annotations indicate readOnlyHint=false and destructiveHint=false, so the tool is a write operation but not destructive. The description adds the useful context that changes are grouped as one undo step, which is not captured by annotations. However, it does not disclose other behaviors like partial-failure handling, confirmation requirements, or response format.

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

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

The description is a single sentence with an inline JSON example, front-loading the core purpose and a concrete instance. There is no wasted prose, and the example is self-explanatory, making it highly efficient.

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

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

The description covers the primary purpose and a use case, and the schema covers all parameter definitions. However, the description does not explain the confirm parameter's role (e.g., whether it requires user confirmation) or the summary field, and it does not mention failure/rollback semantics. For a batch operation, this leaves some gaps in understanding edge 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 itself provides detailed descriptions for each ChangeSpec field (target, param, dest, delta, value) and the confirm/summary parameters, so the description does not need to repeat them. The description gives an example that maps to the schema, but does not add additional semantic nuance beyond the schema's own documentation.

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 verb ('apply') with a resource ('several changes at once') and provides a concrete example of a monitor mix rebalance. This distinguishes it from sibling tools like set_fader or set_mute, which handle single changes. The one-undo-step phrasing further clarifies its unique value.

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 when to use it (when multiple changes need to be applied together as one undo step) but does not explicitly state when not to use it or name alternatives like single-change tools. The example suggests a use case, but there is no explicit routing between this and the single-parameter setters.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that it is a summary of various elements, which is more about content than behavior. It doesn't mention any side effects, auth requirements, or performance implications, but given the read-only nature, the bar is lower and the description satisfies the basic expectation.

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, dense sentence that front-loads the core purpose ('Whole-board summary') and then lists the included elements. It ends with the actionable instruction 'Start here', which is both concise and purposeful with no wasted words.

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

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

Given the tool's simplicity (no parameters, read-only, no output schema), the description adequately covers what the agent can expect in terms of content. It lists all major board areas but doesn't describe the response format or any limitations, which is acceptable for a straightforward summary tool with annotations already providing the safety 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?

This tool has zero parameters, so the schema is trivially complete at 100% coverage. Per the baseline for zero-parameter tools, a score of 4 is appropriate; the description doesn't need to explain parameters since there are none.

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 tool's purpose as a 'Whole-board summary' and enumerates the specific items covered (inputs, buses, FX, main LR, DCAs). This is a precise verb-resource statement that distinguishes it from narrower tools like channel_detail or find_channels.

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 'Start here' gives explicit guidance that this is the recommended first tool to invoke, implying it provides an overview before diving into specifics. It doesn't name alternatives or exclusions, but it does establish a clear entry-point usage context.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful scoping (session-only, assistant-made changes) and ordering (newest first), but it does not clarify what counts as a change, whether changes are pending or applied, or any retention limits. No contradiction with annotations.

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 tight sentence that conveys scope and ordering with no wasted words. It is appropriately minimal for a read-only, one-parameter tool.

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

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

There is no output schema and the description does not state what the returned change records look like or how limit affects results. An agent can infer that it returns some list of session changes, but the level of detail is thin for a tool that has no output schema to fill the 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?

The only parameter, limit, has no description and the description never mentions it, so it does not compensate for 0% schema_description_coverage. The schema supplies type and default, but not semantics like maximum allowed value or behavior when omitted.

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 identifies the resource as in-session changes made by this assistant, and 'newest first' implies a chronological listing. It is distinguishable from undo and apply_changes, though it lacks an explicit verb like 'list' or 'view'.

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 this session' gives some context for when to use it, but the description does not contrast it with related tools such as apply_changes, undo, or preset history. No alternatives or exclusions are mentioned, so usage guidance is implied rather than explicit.

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 annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by listing the setting categories returned (config, preamp, gate, compressor, EQ bands, fader, sends, groups), but it does not disclose response structure, target format requirements, 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 a single compact sentence that front-loads the core purpose ('Every setting of one strip') followed by the strip types and setting categories. Every item in the list earns its place, and there is no fluff or repetition.

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

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

For a read-only one-parameter tool with safety annotations, the description gives the essential scope and a useful list of included settings. However, since there is no output schema, it leaves the response shape and the exact target value format unspecified, which is a noticeable gap for an agent calling the 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 0% description coverage for the sole 'target' parameter. The description implies that target selects one strip among the listed types, giving it conceptual meaning, but it does not specify the exact value format (e.g., 'ch1' vs 'channel 1'), so it only partially compensates for the schema gap.

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

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

The description clearly identifies the tool as returning all settings of one mixer strip, and it enumerates the supported strip types (channel, aux, FX return, bus, FX send, LR or DCA). It does not use an explicit verb like 'get' or 'returns', and it does not explicitly contrast with mixer_status or board_overview, but the resource and scope are 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 use this tool versus the many set_* siblings or read_meters. The read-only purpose is implied but not stated as 'use this to inspect current settings before making changes', and no exclusions or alternatives 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read-only nature is clear. The description adds context that the tool compares a saved preset with the current board or another preset, but does not disclose output format or any additional behavioral traits beyond that.

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 deliver the core purpose and intended question, with no wasted words. The main comparison behavior is front-loaded and the example phrasing adds user context without 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?

The description is adequate for basic invocation: it names the required comparison inputs and the optional other preset. However, with no output schema, it does not describe what the diff output looks like, and it leaves 'max_lines' unexplained, which is a notable gap for a formatting-related parameter.

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 description clarifies the 'other' parameter by name ('another preset given as other'), but does not explain 'name' or 'max_lines'. With 0% schema description coverage, the description should compensate, and it only partially does.

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

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

The description states a specific verb ('show what differs') and a clear resource: a saved preset versus the current board or another preset. It clearly distinguishes the tool from siblings like load_preset, save_preset, and list_presets by focusing on comparison rather than loading or saving.

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 'Answers what changed since ...' gives clear context for when this tool is useful. It does not explicitly name alternatives or exclusion conditions, but the comparison-focused framing makes the intended use case evident.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the case-insensitive matching and empty-query behavior, which is useful. It does not disclose return format or whether results are ordered, but for a simple read-only search this is acceptable.

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

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

Two sentences, no wasted words, and the most important behavior (case-insensitive substring match) is front-loaded. The empty-query behavior is a useful edge case stated efficiently.

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

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

For a simple read-only search tool with one optional parameter and no output schema, the description covers the key behaviors: matching semantics and empty-query behavior. It could mention what a 'strip' is or what fields are returned, but the sibling context and tool name make this largely inferable.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain the query parameter's semantics: substring match on name, case-insensitive, empty lists all. This adds meaning beyond the schema's bare 'Query' field, but it does not specify format details like trimming or wildcard behavior.

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

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

The description states a specific verb ('Find') and resource ('strips'), and clarifies the matching behavior (case-insensitive substring on name). It is clear enough to distinguish from siblings like channel_detail or board_overview, though it does not explicitly name a sibling alternative.

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

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

The description implies usage: use it to find strips by name, and empty query lists all named strips. It does not explicitly state when to prefer this over channel_detail or board_overview, but the context is reasonably clear for a search/lookup tool.

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

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

Annotations already mark it read-only and non-destructive, and the description reinforces this by stating it only suggests changes rather than applying them. It adds useful behavioral context: the loudest-part prerequisite, default target of -12 dBFS, and the fact that it measures peaks. The return format is not described, but the read-only safety profile is well covered.

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

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

Three tight sentences with no filler. The most critical operational instruction (play loudest part first) is front-loaded, followed by what the tool measures and its relationship to set_preamp. Every sentence carries 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?

The description covers the essential operational procedure and the tool's non-mutating role, but it lacks information about the output format and leaves two of three parameters undocumented. For a tool with no output schema, this is a meaningful gap, though the core usage is still understandable.

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 parameters. It only explains target_peak_db (with its default -12 dBFS), leaving seconds and targets completely unexplained. An agent cannot confidently infer what 'targets' refers to or how 'seconds' affects the measurement.

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 identifies the tool as a gain-staging helper that measures channel peaks and suggests preamp gain changes toward a target peak level. It explicitly distinguishes its advisory role from the applying tool set_preamp, making its purpose unambiguous relative to siblings.

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

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

It gives a clear when-to-use instruction: ask musicians to play their loudest part first, then run it. It also states the relationship to set_preamp (suggests only, apply separately), but it does not explicitly mention alternatives like read_meters for raw metering or say when not to use 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the ordering behavior ('newest first') and does not disclose response shape or pagination, but for a simple read-only list this is acceptable.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes meaning, and the ordering detail is efficiently appended in parentheses.

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 no-argument, read-only list operation, the description is essentially complete: it states what is listed and the ordering. It does not describe the return format, but the absence of an output schema and the simplicity of the operation make this a minor 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?

The tool has zero parametersional and schema coverage is trivially 100%, so there is no parameter detail to add. The description appropriately focuses on behavior rather than arguments.

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 ('List') and resource ('saved board presets'), with an additional ordering detail ('newest first'). This clearly distinguishes it from sibling tools like save_preset, load_preset, and diff_preset.

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 imperative 'List saved board presets' implies when to use the tool, but it does not explicitly contrast it with load_preset or snapshot_list, nor does it mention when not to use it. Usage is reasonably inferable but 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?

Adds substantial behavior beyond the annotations: only differing parameters are written, the current board is auto-saved first, the load is one undo step, and confirmation is always required. These details are not present in the annotations and meaningfully inform the agent about side effects and reversibility.

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

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

Two sentences, no filler. The first sentence front-loads the core purpose and partial-write behavior; the second covers all operational prerequisites. Every clause earns its place.

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

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

For a two-parameter tool with no output schema and annotations already marking it destructive, the description covers everything needed to invoke it correctly: what it does, the confirmation requirement, the auto-save safety net, and undoability. No critical operational detail is 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?

With 0% schema description coverage, the description must compensate, and it does: 'Restore a saved preset' implies name selects the preset, and 'Always needs confirm' directly indicates that the confirm parameter must be true (despite its schema default of false). It does not explicitly name the parameters but gives enough functional meaning for both.

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 ('Restore a saved preset to the mixer') and adds a crucial distinguishing behavior ('only differing parameters are written'). Clearly separates it from save_preset, list_presets, and snapshot_load by indicating this is a targeted partial restore, not a full snapshot reload.

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 a strong prerequisite: 'Always needs confirm,' which tells the agent the confirm parameter must be set to true. It also mentions the auto-save and undo-step effects, giving the agent enough context to decide when this destructive operation is appropriate. It does not explicitly name alternative tools or exclusions, 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?

Annotations already declare readOnlyHint and destructiveHint. The description adds the specific data fields returned, which is helpful context. However, it does not mention any potential side effects or limitations beyond the annotations, but since it's read-only, that's acceptable.

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

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

One sentence that front-loads the purpose and lists key fields. Efficient and no 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 no-parameter read-only status tool, the description adequately covers what it returns. Without an output schema, listing the fields is sufficient.

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?

Tool has zero parameters, so baseline is 4. The description doesn't need to explain parameters as there are none.

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 it returns connection info and lists specific fields (model, name, IP, firmware, guardrail limits, change count). It does not explicitly differentiate from siblings like board_overview or channel_detail, but the resource scope is clear.

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

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

No guidance on when to use this tool vs alternatives. It is a read-only status tool, but the description does not mention when to prefer it over other info tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds that it returns both the raw value and the mixer's text readout, which goes beyond annotations. No contradictions; minor gaps like error handling are acceptable given the read-only nature.

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 concise sentences with no waste: the first states the action and output, the second states its role as a fallback. Information is front-loaded and directly useful.

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

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

For a simple read tool with one parameter and no output schema, the description covers purpose, usage context, and return value. It lacks details on address validity or potential errors, but given annotations cover safety, it is sufficiently complete for an agent to invoke it correctly.

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

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

Schema has zero description coverage for the 'address' parameter, but the description provides an example format (/ch/01/eq/2/f) and clarifies it accepts any OSC address, adding meaningful semantic guidance beyond the bare schema.

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

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

States a specific action (read) and resource (any OSC address) with an example, and explicitly labels itself as an escape hatch for settings other tools don't cover, distinguishing it from specialized siblings like set_fader or set_eq.

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 clear context: use when other tools don't cover a setting, implying specialized tools are preferred when available. Lacks explicit exclusions or prerequisites but the 'escape hatch' phrasing is sufficient.

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?

Annotations are minimal (readOnlyHint=false, destructiveHint=false), so the description carries more burden. It discloses that this is a write operation, that guardrails still apply, and that system paths require confirmation. This adds contextual behavior beyond the annotations, though 'guardrails' remains somewhat vague and it doesn't detail success/failure or undoability.

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 parenthetical lists value types efficiently, and the guidance about dedicated tools and confirm is compact. No wasted words.

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

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

For a simple write tool with 3 parameters and no output schema, the description covers purpose, usage preference, and confirm behavior. It doesn't mention error cases or address formatting, but those are minor for its complexity. Overall it is reasonably complete.

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

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

Schema description coverage is 0%, so the description must compensate. It does for 'value' by explaining the expected types (floats, ints, text) and for 'confirm' by tying it to system paths. It doesn't elaborate on 'address' beyond the tool's name, but the address format is implied by the OSC context. This partial compensation meets the low-coverage need.

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 ('Write') and resource ('RAW OSC value'), and specifies the value types accepted (normalized floats, ints, text). It also signals its place among siblings with 'Prefer the dedicated tools,' distinguishing it from the specialized set_* tools without opening their schemas.

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?

'Prefer the dedicated tools' gives an explicit when-not direction, and 'system paths need confirm' clarifies one usage condition. It does not explicitly state 'use this only when no dedicated tool exists,' but the raw/fallback intent is strongly implied. Could be more explicit about selection criteria, but it provides clear 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the bar is lower. The description adds real behavioral context beyond that: the measurement is time-boxed ('for a few seconds'), the dBFS scale convention is disclosed ('0 = clipping'), and the returned signal classifications are enumerated (clipping, hot, low, silent). It does not state whether the call blocks for the duration or how thresholds map to dBFS values, but it adds substantial context.

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

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

Roughly 45 words front-loaded with the core purpose first, followed by compact scope semantics and flag types. Every clause earns its place and nothing is redundant with the schema's enum values or defaults.

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 tool with 3 optional parameters and no output schema, the description is nearly complete: it establishes the metric, the scale convention, valid scopes, and what signal conditions are flagged. What is missing is the return shape (structure of the per-channel readings) and the threshold semantics for hot/low/silent, but an agent can invoke this 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 compensate, and it does for the trickiest parameter: 'channels' is expanded into 'channel strips, FX returns, buses, main LR' and 'inputs' as 'raw mic/aux/USB inputs'. 'seconds' and 'include_silent' are not individually glossed, but their names and defaults make them largely self-explanatory, and 'for a few seconds' implicitly ties to the seconds 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?

The description states a specific verb and resource: 'Measure live levels for a few seconds' with explicit metrics (peak and average dBFS) and a scale convention (0 = clipping). It is clear and semantically distinct from the write-oriented siblings (set_fader, set_mute, set_gate) and from other read tools like gain_check, but it never explicitly names or contrasts a sibling, so it stops 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?

Usage context is implied: if an agent needs live level readings (clipping/hot/low/silent), this is the tool. The scope explanation explains parameter choice ('channels' vs 'inputs') but provides no explicit when-to-use versus alternatives such as mixer_status, board_overview, or gain_check, and no 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?

Annotations indicate this is not read-only (readOnlyHint false) and not destructive (destructiveHint false). The description adds value by explicitly disclosing the overwrite behavior and the file path format, which is useful context beyond the annotations. It does not contradict annotations; overwriting is expected and not a hidden destructive side effect.

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 main action and scope, followed by naming conventions and overwrite behavior. It is concise with no filler, earning a high score for efficiency.

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

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

The tool is simple (2 parameters, no output schema) and the description covers the primary function, naming, and overwrite. However, it does not mention what happens on success/failure (e.g., return values, errors) or how the 'notes' field is used. For a save operation, this is a minor gap but still leaves some uncertainty 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?

Schema description coverage is 0%, so the description must compensate. It explains the 'name' parameter with examples and clarifies it determines the file name. However, the 'notes' parameter is not explained at all; its purpose and how it is stored remain unclear. This is a significant gap given the schema provides no descriptions.

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 tool saves the entire board to a preset file, naming the resource (board) and specific components. It also mentions overwriting. However, it does not explicitly differentiate from siblings like load_preset or snapshot_save, though the action 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 implies when to use the tool (to save a preset) and provides naming examples, but it does not explicitly state when to use it versus alternatives like list_presets or load_preset, nor any exclusions or prerequisites. It gives some usage context with naming conventions but lacks explicit 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?

The description discloses range constraints and the ratio snapping behavior ('snaps to 1.1/1.3/...'), which goes beyond the sparse annotations. However, it does not disclose side effects, confirmation requirements, or how changes propagate. With readOnlyHint=false and destructiveHint=false, the description partially carries the behavioral burden but leaves the overall write behavior implicit.

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 dense sentence, front-loaded with the purpose and no filler. It efficiently packs all the ranges, but the run-on format buries individual parameters; a bulleted list would improve scannability.

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 14 parameters, no output schema, and minimal annotations, the description is insufficient. It covers roughly half the parameters, omits the required target semantics entirely, and does not explain mode/detector/hold or the confirm/apply_changes workflow. An agent would need to infer too much to use the tool confidently.

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

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

Schema description coverage is 0%, so the description is the only source for parameter meaning. It adds units and ranges for threshold, ratio, knee, makeup, attack, release, and mix, which map to seven schema parameters. However, it omits target, mode, detector, hold_ms, on, auto, and confirm, leaving those parameters semantically unexplained.

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

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

Description opens with 'Compressor on a channel, bus or main LR' – a specific, non-tautological statement of what the tool acts on and the effect. It clearly distinguishes itself from sibling tools like set_gate or set_eq by naming the compressor, though it lacks an explicit verb like 'configure'.

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

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

No guidance on when to use this tool versus alternatives such as set_gate or set_eq. The only scope information is the target type list, which is a constraint, not a usage rule. There is no mention of prerequisites, alternatives, or conditions for choosing this tool.

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

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

Annotations are minimal (only readOnlyHint false, destructiveHint false), so the description carries most of the burden. It does add useful behavioral detail: band availability by target type, allowed numeric ranges, and that 'on' without a band switches the whole EQ. However, it does not mention confirm behavior, whether changes are applied immediately or staged, or what happens with invalid combinations.

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 short sentences with no filler, and the most identifying information ('Parametric EQ') is front-loaded. Every sentence adds a meaningful constraint or behavior, though the omissions prevent a higher score.

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 parameters, no output schema, minimal annotations, and 0% schema coverage, the description is too thin. It explains several numeric bounds but omits essential semantics for target addressing, type choices, and the confirm parameter, making it insufficient for correct invocation in all cases.

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

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

Schema description coverage is 0%, so the description must compensate. It clearly documents ranges for gain_db, freq_hz, and q, explains band limits per target type, and clarifies the on parameter. But it leaves target format, the type enum values, and confirm semantics undocumented, which are significant 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 begins with 'Parametric EQ', clearly identifying the resource and function, and distinguishes it from sibling tools like set_gate and set_compressor by naming the effect type. The action verb is not explicit, but the tool name set_eq plus the parameter details make 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?

No guidance is given about when to use this tool versus related tools such as set_hpf or set_compressor. The description provides constraint context (band counts per target type and value ranges) but not conditions, prerequisites, or exclusions that would help select this tool over 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?

The annotations only declare the tool to be non-read-only and non-destructive, and the description adds no further behavioral context. It does not disclose whether the change applies immediately, requires apply_changes, can be undone, or what the confirm parameter actually does. For a mutating tool, this leaves meaningful behavior unexplained.

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 with no filler: the first identifies the operation and target scope, the second explains the two value modes. The critical parameter choice is front-loaded and every sentence earns its place.

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

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

For a simple setter, the description is close to sufficient, covering target scope and the db/delta_db choice. It is incomplete in exact target naming conventions, confirm behavior, and timing of the change, especially with no output schema or additional annotation 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 compensate; it does clarify the db range and delta_db relativity, and loosely describes target classes. However, it does not specify the exact target string syntax or the meaning of confirm, leaving two of four parameters only partially documented.

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

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

The description uses a specific verb-resource pair ('Set a fader') and enumerates the supported target types: channel, aux, FX return, bus, FX send, main LR, or DCA. This makes the tool's scope immediately clear and distinguishes it from sibling tools like set_mute, set_send, and set_eq.

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 clear operational guidance: provide either an absolute db value within -inf..+10 or a relative delta_db such as -3. It does not explicitly name exclusions, but the fader scope and sibling tool names make the intended use case obvious.

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 does not disclose any effects beyond what the parameter list implies, and the annotations only say the call is not read-only and not destructive. There is no mention of whether values are applied immediately, how the gate/expander responds, or what context (e.g., channel selection) 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 description is a compact single sentence with the resource front-loaded and every clause carrying parameter information. It is appropriately sized for a setter, though it leans telegraphic rather than explanatory.

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 no output schema and no parameter descriptions, the description is incomplete: it omits target format, mode semantics, on/off behavior, and any usage context. An agent could set numeric values but would have to infer the meaning of several fields.

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 adds useful constraints for five numeric parameters (threshold -80..0 dB, range 3..60 dB, attack 0..120 ms, hold 0.02..2000 ms, release 5..4000 ms). It does not explain the meanings of 'target', 'on', or 'mode', including the EXP2/EXP3/EXP4/GATE/DUCK enum values.

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

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

The description names the resource ('Channel noise gate / expander') and lists the adjustable parameters, so an agent can distinguish it from sibling tools like set_compressor or set_eq. However, it is a noun phrase rather than a verbed statement of what the tool does; the 'set' action is only implied by the tool name.

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 for when to use set_gate instead of alternatives such as set_compressor or set_hpf, and there are no exclusions or prerequisites. The scope is implied by the tool name and 'Channel noise gate / expander', but the description does not explicitly route the agent.

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

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

Annotations only declare readOnlyHint=false and destructiveHint=false, which indicate a mutating but non-destructive operation. The description adds valuable behavioral context beyond those annotations: it explains that setting freq_hz automatically switches the filter on unless on=false, and specifies the valid frequency range. This is exactly the type of side-effect disclosure that helps agents predict outcomes.

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 extremely concise: two sentences, no filler, and the core purpose is front-loaded. Every word adds information, making it easy to parse quickly.

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 filter-setting tool, the description covers the main behavior and range, but it omits any explanation of the target parameter (likely the channel identifier) and does not describe what happens when on is explicitly set versus when freq_hz is given. It also lacks any description of the output or confirmation. Given the absence of an output schema, these gaps matter, though the core operation is understandable.

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

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

With 0% schema description coverage, the description must compensate, but it only explains freq_hz and on partially. The required 'target' parameter is entirely undocumented; an agent cannot infer what value to pass (likely a channel identifier) from the description. The auto-switch behavior for freq_hz and the override with on are helpful, but the missing target semantics is a significant 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 clearly states the tool sets a channel high-pass (low-cut) filter with a specific frequency range (20–400 Hz). This verb+resource combination is unambiguous and distinguishes it from sibling tools like set_gate or set_eq without needing to inspect schemas.

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 the tool is for applying a high-pass filter to a channel, but it does not explicitly state when to use it versus alternatives or mention any prerequisites. The context is clear enough for a domain-savvy agent, but there is no explicit when-to-use or when-not-to-use 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?

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutating nature is known. The description adds only the mute/unmute action, which is obvious from the name, and does not disclose any side effects, confirmation behavior, or scope of impact (e.g., does it affect all strips or just targeted ones?). This is minimal added value beyond annotations.

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

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

The description is a single, front-loaded sentence with no filler. It states the core action and the parameter values directly. Every word earns its place, making it highly efficient.

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

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

For a tool with 3 parameters and no output schema, the description is too sparse. It fails to explain the 'confirm' parameter, which could affect behavior, and doesn't clarify what a 'strip' is or how targets are specified (e.g., identifiers). The lack of any mention of confirmation or safety makes it incomplete for correct usage.

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 carries the burden for parameter meaning. It explains 'muted' (true/false) and 'targets' (one or more strips), which covers two of three parameters. However, it omits any explanation of 'confirm', leaving the agent to guess its purpose (likely a safety confirmation, but not stated). This is partial compensation but 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 clearly states the verb ('Mute'/'unmute') and the resource ('one or more strips'), and it distinguishes itself from sibling set_* tools by being specifically about mute state. It doesn't mention the mixer context explicitly, but 'strips' is domain-appropriate and clear enough.

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

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

The description implies when to use this tool (when you need to mute/unmute strips) but provides no explicit guidance on when to use it over alternatives, nor does it mention exclusions or prerequisites. It's adequate but leaves the agent to infer the selection logic from the name and siblings.

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

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

The description adds a meaningful behavioral trait beyond annotations: 'Phantom changes always need confirmation' alerts the agent to a required confirmation flow. It also reveals the gain range and the absolute/delta distinction, which are behavioral semantics not visible in the raw schema. While it doesn't disclose potential side effects or persistence, the key confirmation behavior is a valuable addition.

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 with no unnecessary words. The first sentence front-loads the resource and the adjustable controls, and the second adds the critical confirmation requirement. Every sentence earns its place; this is an exemplary concise structure.

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

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

Given the tool's complexity (6 parameters, no output schema) and minimal annotations, the description provides a useful overview but leaves important details unspecified. The agent still needs to infer how target is addressed, how confirm applies to non-phantom settings, and what the default behavior is for null values. It is adequate for a straightforward call but not fully complete for edge cases.

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

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

With 0% schema description coverage, the description carries the entire burden. It explains gain_db (absolute with a -12..+60 dB range), delta_gain_db (delta), phantom, and invert at a high level. However, it does not clarify the target parameter, whether gain_db and delta_gain_db are mutually exclusive, or how confirm interacts with non-phantom changes. The core parameters are semantically covered, but 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?

The description states the resource (mic preamp of a channel) and enumerates the exact adjustable parameters (gain with range, absolute or delta, phantom power, polarity invert). It clearly distinguishes this from sibling tools like set_eq or set_fader by naming preamp-specific features. The purpose is instantly clear and specific.

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 explicit guidance on when to use this tool versus alternatives, nor does it mention any preconditions or exclusions. The only indirect hint is the preamp-specific feature list, but an agent is left to infer the tool's role from its name. No sibling comparisons or 'use this when' statements are present.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description does not need to repeat that it mutates state. However, it does not disclose behavioral nuances such as the purpose of the 'confirm' parameter, whether both db and delta_db can be provided simultaneously (and what happens if they are), or any side effects. The mention of db vs delta_db and tap point adds some context, but significant behavior remains undisclosed.

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, no fluff. It front-loads the core purpose and then provides essential parameter guidance. Every word earns its place, making it efficient and 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?

Given six parameters, no output schema, and minimal annotations, the description is incomplete. It omits the role of 'confirm', does not specify how to format source/dest beyond the general types, and does not explain edge cases like providing both db and delta_db. An agent would need to guess or consult other sources to use the tool correctly for all scenarios.

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 db (absolute) and delta_db (relative), and clarifies the tap point options (e.g., PRE = pre-fader, usual for monitors). It also implies the values for source and dest by stating 'from a channel/aux/FX return to a bus (bus1-6, monitor mixes) or FX send (fxsend1-4).' However, it does not describe the 'confirm' parameter or the exact string formats for source and dest. Partial compensation is present, but not complete.

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 tool's action: 'Set the send level from a channel/aux/FX return to a bus or FX send.' It specifies the resource (send level) and the destinations (bus1-6, monitor mixes, fxsend1-4), which distinguishes it from sibling tools like set_fader or set_mute. The verb 'Set' is explicit and unambiguous.

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

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

The description does not explicitly state when to use this tool versus alternatives. It implies it is for send levels, but it does not mention when not to use it (e.g., for faders or mutes) or reference sibling tools. An agent must infer the context, which is not ideal for a tool with many sibling setters. No exclusions or alternative routing is provided.

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

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

Annotations already indicate a mutating, non-destructive operation. The description adds the useful 'one undo step' behavior, but does not disclose confirmation requirements for phantom power or other side effects. No contradiction with annotations.

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

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

One sentence with no filler, front-loads the core action, but the parameter list makes it dense. Still readable and efficient.

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

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

For a complex bulk-update tool, the description misses critical guidance about the structure of the 'channels' array, the purpose of 'confirm', and error/confirmation behavior. The schema descriptions carry most of the semantic load, so the description alone is not fully complete.

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

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

Schema description coverage is 0%, so the description must compensate. It enumerates several field names (name, color, HPF, gain, phantom, USB, LR, fader, pan), but omits the required 'channel' and the 'confirm' flag, and provides no formats or constraints. Only partial compensation.

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

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

States a specific verb and resource: 'Set up many input channels' in one batch operation, lists the exact attributes (names, colours, HPF, etc.), and clearly distinguishes from the single-channel set_* siblings by emphasizing 'many' and 'in one go'.

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 when to use (bulk channel setup from an input list or stage plot) and contrasts with the individual set_* tools by highlighting the batch aspect. However, it does not explicitly name alternatives or state when-not-to-use, so it falls short of fully explicit 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?

The description discloses several non-obvious behaviors beyond the annotations: sources not listed are left unchanged, the tap point defaults to PRE-fader, and name/color/master fader are optional. Annotations already convey mutability (readOnlyHint false), so the added details are useful. It does not mention the confirm parameter or full side effects, but the coverage is still strong given the annotation context.

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

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

The description is compact and efficient: a clear purpose statement, a concrete example for the complex sends parameter, and key defaults in a couple of sentences. No filler or repetition, and the most important scoping behavior ('sources not listed are left unchanged') is front-loaded.

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

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

For a tool with 7 parameters, a nested object, and no output schema, the description provides a good overview but is not fully complete. It leaves out the confirm parameter, does not explain accepted formats for color/name, and does not describe how bus_fader_db interacts with the existing bus level. An agent would still need to make reasonable assumptions.

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 the sends object with a concrete dB example, mentions the tap default, and notes optional name, color, and master fader. However, it omits the confirm parameter entirely and does not clarify the meaning of the tap enum values or color format, leaving notable semantic 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 starts with a specific verb and resource: 'Build a monitor / in-ear mix on a bus in one step', which clearly states what the tool does. It differentiates itself from the many single-purpose sibling tools (set_send, set_fader) by framing this as a one-step, multi-part setup, and the sends map example anchors the purpose concretely.

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 when one wants to build a monitor mix in a single operation, but it does not explicitly say when to prefer this over alternatives like set_send or setup_channels. There is no when-not guidance or mention of sibling tools, so an agent must infer the intended scenario.

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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds useful scoping detail (only named snapshots, limited to 1-64), which helps an agent understand exactly what will be returned. It does not discuss auth or rate limits, but those are less relevant for a read-only, non-destructive list tool.

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

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

A single, tightly worded sentence that leads with the verb and resource, immediately clarifying scope. No filler or redundant details.

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, parameterless tool with no output schema, the description is mostly sufficient, but it does not specify the return shape (e.g., list of names, slot numbers, or pairs). Since the agent must call this tool without knowing the output format, this is a notable gap. The description covers the input and scope but not the expected response.

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, and schema coverage is 100% (vacuously). The description correctly specifies the complete parameter set, so the baseline of 4 applies without needing further parameter 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 states a specific verb ('List') and resource ('the mixer's internal snapshots (slots 1-64) that have a name'), making it clear what the tool does. This distinctly separates it from snapshot_save, snapshot_load, and list_presets, which target different resources or operations.

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 the use case clearly: when you need to enumerate named snapshots in slots 1-64. It does not explicitly mention alternatives or when not to use it, but the tool's name and clear scope provide sufficient context without 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?

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's 'changes the whole board' aligns with that. The description adds valuable behavioral context: the operation requires confirmation and the current board is auto-saved as a preset first, which mitigates the destructive nature. This goes beyond the annotations.

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

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

Two sentences, front-loaded with the core action and scope, then the critical safety behavior. Every word earns its place; no 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 destructive operation with no output schema, the description covers the key context: what it does, that it changes the whole board, that confirmation is required, and that the current state is auto-saved for recovery. It doesn't explain what happens if confirm=false or what the response looks like, but the annotations and schema cover the safety profile.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'slot' implicitly via 'one of the mixer's internal snapshots' and 'confirm' via 'Always needs confirm', but it doesn't explain what values slot accepts or what confirm does beyond the schema's default false. The description adds some meaning but not enough to fully compensate for the 0% coverage.

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 verb 'load' and the resource 'one of the mixer's internal snapshots', and adds the important scope 'changes the whole board'. It distinguishes from load_preset by noting the auto-save behavior, though it doesn't explicitly name the sibling in the description.

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 says 'Always needs confirm', which is a clear usage requirement. It also explains the auto-save behavior and mentions that the current board can be restored with load_preset, giving the agent a recovery path. It doesn't explicitly state when to use this vs snapshot_save or load_preset, 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?

Annotations already mark destructiveHint=true and readOnlyHint=false, so the write behavior is known. The description adds valuable nuance beyond annotations by stating that overwriting a named slot requires confirm and by giving the slot range and name length limits.

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 no filler. The main action is front-loaded, and the overwrite caveat is placed immediately after the core description. Every sentence adds needed 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 save operation with no output schema, the description covers the essential context: destination, slot range, name constraint, and overwrite confirmation. Minor gaps remain, such as exact behavior when confirm is false for a named slot or error/return format, but these are not critical for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does so by explaining slot is 1-64, name is max 12 characters, and overwriting a named slot needs confirm—thereby giving substance to the confirm parameter. It does not explicitly state what happens if confirm is false on an occupied slot, but coverage is solid overall.

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 ('Save'), a specific object ('current board'), and a precise destination ('mixer's internal snapshot slot 1-64'), plus the name constraint. This clearly distinguishes snapshot_save from read-only siblings like snapshot_list and snapshot_load.

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 purpose is clear enough that an agent can infer when to use it, but the description does not explicitly route away from alternatives such as save_preset, snapshot_load, or snapshot_list. It leaves the when/why-not comparisons to inference from sibling names rather than stating them.

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 adds meaningful behavioral context beyond the annotations by stating that it restores 'exact previous values' and limits itself to this assistant's change groups. This complements the readOnlyHint=false annotation by confirming this is a mutation while also suggesting non-destructive restoration 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 entire description is one tight sentence with a clarifying parenthetical. The key action, scope, and behavioral nuance are front-loaded with no wasted words.

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

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

The description covers purpose, scope, and outcome, which is enough for a simple default invocation. However, it leaves the 'steps' parameter semantically ambiguous and provides no information about response behavior or failure cases, so it is not fully complete for confident multi-step use.

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 only parameter, 'steps', is not explained in the description, and schema description coverage is 0%. The plural 'group(s)' hints that multiple groups can be reverted, but the description never explicitly maps 'steps' to a number of change groups or clarifies valid values.

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

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

The description uses a specific verb ('Revert') and a specific resource ('last change group(s) made through this assistant'), clearly distinguishing this from generic undo or other sibling tools. The parenthetical ('restores the exact previous values') adds precise semantics that help an agent understand the expected outcome.

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 'made through this assistant' provides a clear scope: this tool applies to assistant-originated changes and implicitly not to external changes. No alternative tools are named, but the boundary is specific enough for an agent to infer when to invoke it.

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