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

With no annotations, the description carries the full behavioral burden. It usefully discloses that this is a destructive wholesale replacement, that it applies to both channels, and that an EQ plugin is required. It says nothing about behavior on failure (no plugin present), reversibility, or how mode/instance/pipeline affect the operation.

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

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

Two tight sentences with the action and scope front-loaded and the prerequisite trailing correctly. No filler, though the stray formatting break adds no value.

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?

An output schema exists, so return values need not be explained. However, for a 5-parameter mutation tool with no annotations and low schema coverage, leaving mode, instance, and pipeline undocumented leaves the agent under-informed about how to target the right EQ instance.

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

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

Schema description coverage is only 20%, so the description must compensate, and it largely does not. It only alludes to bands and hints at preamp via the AutoEQ reference; mode, instance, and pipeline are entirely unexplained in both the schema and the description.

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

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

States a specific verb and resource with scope: 'Replace the whole equalizer with a list of bands.' The phrase 'whole equalizer' implicitly contrasts with the per-band sibling set_equalizer_band, though the sibling is never named. An agent can tell it is a wholesale replacement rather than a single-band edit.

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

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

Gives clear context for use (band lists sourced from an AutoEQ ParametricEQ.txt) and states the prerequisite that an equalizer plugin must be in the chain. It does not name an alternative tool or state when not to use it, so it stops short of the top score.

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

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

No annotations are provided, so the description carries the full behavioral burden. It conveys that the operation is reversible ('re-enable'), but says nothing about whether bypass takes effect on live audio, whether it persists across sessions, or whether the target plugin must exist/be loaded.

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 front-loaded sentence with no filler; the core action leads. It is arguably too terse for a four-parameter tool, but nothing in the sentence is wasted.

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

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

An output schema exists, so return values need no explaining, but with four parameters at 0% schema coverage and no annotations the description leaves too much unstated: which pipeline is targeted, how instances are addressed, and what state change to expect. The tool's complexity is not matched by the description's depth.

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

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

Schema coverage is 0% and the description mentions none of the four parameters. 'Single plugin' and 're-enable' faintly gesture at the plugin and bypassed arguments, but pipeline (with its enum), instance (default 0, implying multiple instances), and the required/optional split are entirely undocumented.

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

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

States a specific verb+resource: 'Bypass (disable) or re-enable a single plugin.' The parenthetical resolves the jargon (bypass = disable) and 'single plugin' implicitly distinguishes it from the sibling set_global_bypass, though it never names that sibling explicitly.

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

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

'or re-enable' implies the tool is a bidirectional toggle keyed on the bypassed flag, and 'a single plugin' implies per-plugin scope. However, it never states when to prefer this over set_global_bypass or set_plugin_property, leaving the agent to infer the choice.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the returned content (gains, mode, active bands, both channels), which is real added value since there is no output schema, but it says nothing about permissions, side effects, or whether reading is fully non-mutating.

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

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

A single front-loaded sentence with no filler, and the resource and returned fields are stated up front. It is efficient and appropriately sized for a simple getter.

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

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

With no output schema and no annotations, the description partially fills the gap by listing what is returned. However, the two input parameters remain completely undocumented and no safety/context information is given, leaving the definition only partly adequate.

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 neither of the two parameters (instance, pipeline) is explained in the description. The phrase 'both channels' gestures at channel/pipeline semantics but never maps it to the input/output enum, so the description does not compensate for the coverage gap.

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

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

States a specific verb (Read) and resource (parametric equalizer) plus the data returned, which cleanly distinguishes it from the sibling writers set_equalizer_band and apply_parametric_eq. It stops short of explicitly naming those siblings as alternatives, so it lands at 4 rather than 5.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of sibling tools like get_status or apply_parametric_eq. The agent can infer that a getter reads current state, but the description never states the conditions for calling it.

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

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

No annotations are provided, so the description carries the behavioral burden. The verb 'Read' correctly signals a non-mutating, safe operation and return values are covered by the output schema, but auth requirements, error behavior (e.g. invalid property names), and read scope are not disclosed. It adds only minimal behavior beyond the structured fields.

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

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

A single front-loaded sentence with the core action first and the sibling pointer in a compact parenthetical. 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 read-only lookup tool with an output schema covering return values and a schema that documents the key identifiers, this is largely complete. The main gap is the absence of guidance on which sibling to prefer for whole-plugin or instance data, but nothing critical for correct invocation 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?

Schema description coverage is 60%, with plugin and property described in the schema and channel/instance partially or not documented. The description only restates that a single property is read and points to get_status for the plugin chain, adding little syntax or constraint detail beyond the schema. Baseline 3 fits when the schema does most of the work.

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

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

States a specific verb and resource (read one property of an active plugin) and implicitly separates itself from the write sibling set_plugin_property. It does not explicitly name the siblings it differs from (e.g. get_equalizer for whole-plugin state), so it stops short of a 5.

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

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

The parenthetical 'see get_status for the plugin chain' routes the agent to a sibling for discovering valid plugin/pipeline values, which is useful implied guidance. However, there is no explicit when-to-use vs set_plugin_property or get_equalizer, and no conditions or exclusions stated.

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

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

No annotations are provided, so the description carries the burden. It does disclose the content of the response (global bypass, mic monitoring, sharing, devices, presets, chains), which is useful since there is no output schema, but it says nothing about side effects, permissions, or latency; the read-only nature is only implied by the 'get_' prefix.

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

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

A single compact sentence fragment with the list of returned areas up front; nothing is padded. It is slightly under-specified rather than verbose, which is a mild cost but not a structural flaw.

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 status tool with no output schema, the description partially compensates by naming the returned sections, but it omits anything about response format, freshness, or whether all sections are always present. Adequate but leaves real gaps for an agent relying solely on prose.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly avoids inventing any parameter semantics and instead describes the return content.

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 enumerates the sections returned (bypass, mic monitoring, audio sharing, devices, presets, plugin chains), which makes the broad 'overview' intent inferable, but it never states a verb or explicitly says it retrieves current application state. It also does not distinguish itself from narrower siblings like get_equalizer, get_plugin_property, or list_presets.

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

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

There is no statement of when to call this versus the sibling get_* tools, nor any prerequisites or exclusions. The agent can only infer 'use this for a general snapshot' from the word 'Overview'.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses two return traits (results come in processing order and include bypass state), but says nothing about read-only safety, permissions, or pagination. For a plain list tool this is adequate but thin.

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

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

A single front-loaded sentence with no filler; every clause (pipeline scope, ordering, bypass state) conveys information an agent needs.

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?

An output schema exists, so return values need not be explained. However, for a tool an agent must route between several plugin-related siblings, the description gives no guidance on when to call it and no clarifying detail on the sole enum 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?

Schema description coverage is 0%, but there is only one parameter and its enum values (input/output) are self-explanatory. The description's phrase 'in a pipeline' loosely ties the parameter to the target chain without adding format or selection detail beyond the schema.

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

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

The description names a specific resource (active plugins) and scope (in a pipeline), plus the delivered attributes (processing order, bypass state), which clearly distinguishes it from the single-item siblings get_plugin_property and bypass_plugin. It stops short of explicitly naming any sibling, so it is clear but not fully differentiated.

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

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

There is no when-to-use statement, no condition selecting this over get_plugin_property, get_status, or bypass_plugin, and no prerequisites. The use case is only inferable from the phrase 'active plugins in a pipeline'.

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 full behavioral burden. It does disclose a non-obvious trait — that it also returns the last loaded preset for each direction — but says nothing about safety, permissions, ordering, or whether results can be empty.

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

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

A single front-loaded sentence with no filler; the primary action is stated first and the extra return-content detail follows. Nothing is wasted.

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

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

With no output schema and no annotations, the description must define the return shape, and it only partially does: it names what is listed but not ordering, emptiness, or whether presets are global versus scoped to a plugin instance. Adequate for a parameterless read, but there is room a richer description could fill.

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

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

The tool takes zero parameters, so the baseline is 4. There are no parameter semantics for the description to add or omit, and coverage in the (empty) schema is trivially 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?

States a specific verb ('List') and resource ('saved input and output presets'), and adds scope detail that the name alone does not carry ('plus the last loaded one for each'). It is naturally distinguishable from siblings load_preset, read_preset, and save_preset, though it never names those 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?

Nothing states when to call this rather than read_preset or load_preset, nor any preconditions. Discovery-before-loading is only weakly implied by the verb 'List'; an agent gets no routing guidance.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose whether loading overwrites the current pipeline state, whether it fails on unknown preset names, or whether it requires specific permissions — significant gaps for a state-mutating 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 front-loaded sentence with no filler or redundancy. It is appropriately sized, though the brevity comes at the cost of the usage and side-effect information noted elsewhere.

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?

An output schema exists, so return values need not be explained, but with zero annotations the description should disclose side effects and prerequisites. It covers the what but not the when or the consequences, leaving the definition only minimally viable.

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%, but the description partially compensates by clarifying the 'pipeline' parameter as input vs output and implying 'name' refers to a saved preset. It adds no format, case-sensitivity, or validity details beyond that.

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

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

States a specific verb+resource ('Load a saved preset') and names the target scope ('input or output pipeline'), which matches the pipeline enum. It does not explicitly differentiate itself from close siblings like read_preset or list_presets, but the action is unambiguous.

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

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

There is no guidance on when to use this versus list_presets, read_preset, or save_preset, nor any precondition (e.g. preset must already exist). The agent must infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden; it does disclose that the result is JSON file contents, which is genuine value absent from the structured fields. It says nothing about read-only semantics, missing-file behavior, or what 'saved' implies about prior state.

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

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

A single front-loaded sentence with zero padding that states the action and result directly. Efficient, though its brevity is partly the source of the gaps in other dimensions.

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

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

For a tool with no annotations, no output schema, and two fully undocumented parameters, the one-line description is thin. It omits parameter meaning, failure conditions, and any differentiation from the sibling preset tools.

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

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

Schema description coverage is 0%, so the description must compensate for both undocumented parameters. It never references 'pipeline' (the input/output enum) or explains what 'name' identifies, providing essentially no semantic guidance beyond what the raw schema already shows.

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 (return) and resource (JSON contents of a saved preset file), so the agent knows what it gets back. However, it does nothing to distinguish itself from the very close siblings load_preset and list_presets, leaving the read-vs-load boundary ambiguous.

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 and no mention of alternatives, despite obvious overlap with load_preset and list_presets in the sibling set. The agent must infer the selection criteria from the name alone.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses a real structural constraint (top-level key must be the pipeline name) and the format contract, but is silent on the most consequential behavior: what happens if the file already exists and overwrite is false, whether writes are reversible, and where the file lands.

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, front-loaded with the core action and its key constraint, followed by an actionable tip. No filler or restatement of the tool name.

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

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

The presence of an output schema means return values needn't be explained, and the format reference to read_preset usefully covers the nested object payload. But for a file-writing mutation with no annotations, the omission of overwrite semantics and failure modes leaves the definition under-specified.

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

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

Schema description coverage is 0%, so the description must compensate for all four parameters. It partially explains 'preset' (its format and required top-level key) and hints at 'pipeline', but 'name' and especially 'overwrite' — the parameter governing destructive replacement — are left entirely undocumented in both description and 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 opens with a specific verb+resource: 'Write a preset JSON file', and anchors the format by referencing the sibling read_preset. It implicitly separates itself from load_preset/list_presets, but never explicitly states the contrast (loading into the pipeline vs. saving a file), so it stops short of full sibling differentiation.

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 tip 'read an existing preset first and modify it, rather than writing one from scratch' gives concrete workflow guidance that steers the agent toward a safe pattern. It does not, however, state when to prefer save_preset over load_preset or what preconditions (pipeline must exist, etc.) apply.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the side effect (routing processed output to the virtual source), which goes beyond the name, but says nothing about persistence across sessions, whether toggling interrupts the audio stream, or whether permissions/state prerequisites exist.

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

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

A single sentence with the action front-loaded and the parenthetical clarification placed immediately after the ambiguous term. No filler and nothing redundant.

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

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

For a one-parameter toggle with an output schema (so return values need not be explained), the description covers the action and its effect adequately. It is short of full completeness only because annotations are absent and nothing is said about persistence or interaction with the other routing-related sibling tools.

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% for the single boolean 'enabled' parameter. The description's 'on or off' maps the boolean unambiguously to the action, which is the minimum needed, but adds no detail such as default state or error behavior when the virtual source is unavailable.

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 (turn on/off) and resource (audio sharing), and the parenthetical 'route processed output to the virtual source' defines the resource precisely rather than restating the name. It does not explicitly contrast with siblings like set_global_bypass or set_microphone_monitoring, so an agent must infer the distinction.

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

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

There is no guidance on when to enable versus disable sharing, no prerequisites, and no mention of alternatives such as set_global_bypass or set_microphone_monitoring that also affect output routing. Usage is only implied by the 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, the description carries the full burden. It usefully discloses partial-update semantics ('Only the fields you pass are changed') and the default channel scope, which are non-obvious behaviors. However, it says nothing about prerequisites (does an EQ plugin instance need to exist?), error behavior for out-of-range bands, or whether changes are persisted.

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

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

Three short, front-loaded sentences with no filler; the core action comes first and the behavioral caveats follow. Efficient, though the channel sentence duplicates the schema default rather than adding new 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 10-parameter mutation tool with no annotations and no output schema, the description is thin. It omits band-index range meaning, the role of instance and pipeline, mode/type selection context, and any sense of what the call returns or how failures are signaled.

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

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

Schema description coverage is only 40% across 10 parameters, so the description needs to compensate but largely does not. The one added fact — 'Applies to both channels by default' — merely restates the channel parameter's schema default, and band index semantics, q, instance, and pipeline (input vs output) remain 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?

Clear verb+resource: 'Change one equalizer band' tells the agent this mutates a single band's settings. It implicitly distinguishes itself from the sibling apply_parametric_eq (whole parametric EQ) and get_equalizer (read), though it never names those alternatives explicitly.

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

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

No statement of when to use this versus apply_parametric_eq (bulk EQ application) or get_equalizer. The phrase 'Change one equalizer band' only weakly implies the single-band edit scenario, leaving the agent to infer the routing decision.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does disclose one important semantic fact — 'Bypass on = all effects off' — but says nothing about persistence, effect on in-flight audio, or required permissions, so the disclosure is partial.

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 zero waste; the toggle semantics are front-loaded and the consequence is stated immediately after. Nothing is padded.

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

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

For a one-parameter boolean toggle with an output schema available, the description supplies enough to call it correctly. The only meaningful omission is its relationship to bypass_plugin, but the core contract is complete.

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

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

Schema coverage is 0% and the single boolean parameter is undocumented in the schema, so the description must compensate. It does so cleanly by defining true = enable and false = disable, which is exactly the semantic an agent needs for this parameter.

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

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

States a specific verb (enable/disable) and resource (global bypass) and clarifies the true/false mapping. However, it never distinguishes this global toggle from the sibling bypass_plugin, which an agent could easily confuse it with.

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 toggles the global bypass but gives no when-to-use guidance, no prerequisites, and no exclusions. With a similarly named sibling (bypass_plugin) present, the absence of routing guidance is a real gap.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does convey that this is a binary state toggle and that the audible effect is hearing the processed mic, but it says nothing about persistence across sessions, permissions, latency/feedback implications, or whether other audio paths are affected.

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

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

A single sentence that front-loads the action and the resource. Every word earns its place, and the clarifying parenthetical is the only addition.

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?

An output schema exists, so return values need not be described. For a one-parameter boolean toggle this is close to complete; the only gap is the absence of any statement about scope or persistence, which matters slightly for a mutation without annotations.

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

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

Schema description coverage is 0%, so the description must compensate. The phrase 'on or off' directly maps to the single boolean 'enabled' parameter, and for a one-boolean toggle that mapping is sufficient to prevent misuse; no further parameter nuance exists to explain.

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

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

Names a specific verb ('turn ... on or off') and a specific resource ('microphone monitoring'), and the parenthetical 'hear your processed mic' disambiguates the concept from raw input monitoring. It reads clearly against siblings like set_global_bypass or set_equalizer_band, though it never explicitly contrasts 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?

There is no guidance on when to use this versus alternatives, nor any stated preconditions (e.g. whether a device must be connected, whether this affects recording or only local monitoring). The agent must infer usage entirely from the 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?

No annotations are provided, so the description carries the full burden. It does usefully disclose a read-back verification behavior and that the plugin must be 'active', but omits persistence, permissions, side effects, and error behavior for a mutation tool.

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

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

Two tight sentences with the core action and return behavior front-loaded; no filler or redundancy.

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

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

An output schema exists, so return values need not be explained, and the description wisely notes the read-back. However, for a six-parameter mutation tool with no annotations, it lacks prerequisites and behavioral detail an agent would need to invoke it safely.

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

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

Schema coverage is only 50% (value, instance, and pipeline are undocumented) and the description compensates with nothing beyond 'one property'. It adds no meaning over the schema for the undocumented parameters.

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 (Set) and resource (one property of an active plugin), and clarifies scope with 'one property' and 'active plugin'. It implicitly distinguishes itself from get_plugin_property and set_equalizer_band, though it never names a sibling explicitly.

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

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

Contains no when-to-use guidance, prerequisites, or alternative routing. With siblings like set_equalizer_band and apply_parametric_eq, an agent gets no signal on which setter to pick or when this is preferred.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does convey that this toggles UI visibility rather than an audio setting, which is useful, but it says nothing about whether the state persists, whether it requires a GUI session, or whether hiding affects playback.

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 short, front-loaded sentence with no filler. Nothing to trim.

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

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

For a one-parameter UI toggle with an output schema available for return values, the description is largely sufficient. It omits edge-case behavior (already visible/hidden) and any environment prerequisites, but nothing critical to invocation 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?

Schema coverage is 0%, but the single parameter has an enum of 'show'/'hide' that is self-documenting, and the description restates those two operations. It adds no new detail (defaults, idempotency when already shown/hidden) beyond the enum.

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

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

States specific verbs (show/hide) and a concrete resource (the Easy Effects window), which clearly separates it from the audio-processing siblings like set_equalizer_band or load_preset. The tool name 'window' alone would be ambiguous, but the description resolves it. No explicit sibling routing, so not a 5.

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

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

There is no guidance on when to show versus hide, or in what workflow (e.g., to surface the GUI for the user) this should be invoked. The action enum implies the two modes but the description supplies no context for choosing between them.

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