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

Annotations only convey read-only/mutation flags. The description adds concrete behavior: positive deltas capped at +5 per call and by the effective ceiling, while negative deltas are unrestricted. This is useful context beyond annotations and does not contradict them.

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 communicates the core operation and the key constraints without wasted words. Every clause contributes necessary 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 small mutating tool with 100% schema coverage, the description covers the critical operational constraints. It could be slightly more complete by noting what happens when a positive delta exceeds +5 and by explicitly contrasting with set_intensity, but nothing essential is missing for selecting and 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 schema already documents all four parameters, so the baseline is 3. The description adds meaning for the delta parameter by clarifying the effective positive limit and the unrestricted negative side, which goes beyond the schema's generic -200..200 range.

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 and resource: 'Apply a signed intensity delta to one channel.' This is more informative than the title and differentiates the tool from sibling dglab_set_intenensity, which would be for absolute setting rather than relative adjustment.

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 word 'delta' implies this is for incremental relative changes, so an agent can infer when it applies, but the description does not explicitly say when to prefer it over set_intensity or stop_channel, nor does it name any 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 idempotentHint=true and safe read-like behavior (destructiveHint=false), and the description reinforces this by stating it is safe to call again to fetch pairing info. It also reveals a behavioral trait beyond annotations: it returns a QR code and link for pairing. No contradictions found.

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

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

The description is concise and well-structured, front-loading the core action and outputs. Each sentence adds useful information: what it does, what it returns, how to use it, and that it is idempotent. No redundant phrases.

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 parameters and no output schema, the description is quite complete. It specifies the outputs, the pairing method, and the safe re-call property. A minor gap is not describing what the 'app socket URL' or 'session link' are used for in detail, but the core calling context is fully covered.

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

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

The tool has zero parameters, so schema coverage is complete (100%). The description adds value by explaining what the session setup entails and what outputs are delivered, which is meaningful despite the absence of 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?

The description clearly states the tool's function: start or reuse a DG-LAB 4 V4 relay session and return pairing information. It explicitly lists the outputs (QR code, app socket URL, session link) and distinguishes this from an ordinary connect action by noting it is safe to call again.

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 context: call to initiate pairing or fetch existing pairing info. It does not explicitly contrast with sibling tools, but the context is clear. No alternative tools are named, so it lacks explicit exclusions but still provides sufficient guidance for typical use.

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 destructive=true and idempotent=true, and the description adds valuable extra context about what exactly gets destroyed: 'the relay session and all cached pairing state.' It also discloses the broad side effect of emergency-stopping every device, which is meaningful behavioral information 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?

A single sentence with a clear before/after sequence: emergency-stop first, then destroy session and pairing state. Every part adds information, and the most safety-critical action 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 zero-parameter destructive disconnection tool with strong annotations and no output schema, the description covers everything needed: the scope, the sequence, and the collateral effects. The only minor gap is explicit routing versus emergency_stop, which is more of a usage-guidelines nuance than a completeness 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 no parameters and the schema has 100% coverage with an empty properties object, so there are no parameter semantics to document. The baseline for zero-parameter tools is 4, and the description appropriately focuses on behavior rather than non-existent 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?

The description uses a specific verb plus resource: it 'emergency-stop every device, then destroy the relay session and all cached pairing state.' This goes beyond the title by detailing the exact sequence and side effects, making it clearly distinguishable from siblings like dglab_emergency_stop, which likely only stops stimulation without destroying the session or pairing.

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

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

Usage is implied rather than explicitly stated: the description strongly suggests this is the full teardown tool for disconnecting and clearing pairing state. However, it does not explicitly say when to prefer it over dglab_emergency_stop or dglab_stop_channel, nor does it warn against using it when only a temporary stop is needed.

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 destructive and idempotent behavior, so the description's added value comes from 'bypassing all queues' and 'Cannot be undone by pending commands.' These clarify real-world execution behavior and are not redundant with the annotation metadata.

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

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

The description is two short sentences with no filler. Critical information—scope, immediacy, queue behavior, and non-undoability—is front-loaded and 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 parameterless global stop action, the description covers scope, behavior, and an important consequence, while annotations cover safety traits like destructiveness and idempotence. It does not describe the return value or error behavior, but with no output schema and this simplicity, that is 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 parameters and schema description coverage is 100%, so there is no parameter burden for the description to carry. The baseline of 4 is appropriate; no additional parameter explanation is needed or possible.

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 ('stop') and a precise resource ('every channel and waveform task on every paired app and device'), and it distinguishes itself from the sibling dglab_stop_channel by its global scope. There is no ambiguity about what this tool does.

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

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

The phrase 'Immediately stop every channel and waveform task on every paired app and device' and 'bypassing all queues' clearly conveys the emergency, global-use context. It does not explicitly name dglab_stop_channel as the alternative for stopping a single channel, but the scope contrast is strong enough to guide an 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 already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to restate safety. It adds meaningful behavioral context by explaining that setting refresh causes a re-query of device lists from the paired apps first. There is no contradiction with any annotation.

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 filler. The first sentence front-loads the tool's purpose with a compact but complete enumeration of what is read, and the second sentence crisply explains when and why to set refresh.

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 no required parameters and no output schema, the description fully covers what the agent should expect: relay state, safety lease, app/device details, and waveform tasks. Optional parameter disambiguation is already provided by the input schema, and the refresh side-effect is disclosed. Nothing essential 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 100%, and the schema already explains slotId, refresh, and clientId thoroughly. The description does restate the refresh behavior, but it adds no new parameter semantics beyond what the schema provides. Baseline 3 is appropriate given full schema 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 opens with 'Read relay state...' and enumerates the full scope of the status payload: safety lease, paired apps, device battery, Bluetooth state, intensities, channel condition, mute, comfort limits, ceilings, and waveform tasks. This clearly distinguishes it from the sibling mutation/control tools such as dglab_set_intensity or dglab_emergency_stop.

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 leading verb 'Read' and the detailed state inventory make the intended usage obvious: fetch current DG-LAB status whenever the agent needs device/app/safety state. The refresh condition is also stated explicitly. It does not explicitly name alternatives or state when not to use it, so it falls just short of full 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?

The description contradicts the annotations. It describes renewing a control lease and preventing automatic output shutdown, which is an active side effect, while readOnlyHint=true declares the operation read-only. Per the rubric, any contradiction between description and annotations yields a score of 1, despite the description otherwise offering useful timeout and expiry 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?

Three concise sentences each add essential information: the lease renewal purpose and timeout, the no-op behavior, and the consequence of lease expiry. No filler 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 zero-parameter tool with no output schema, the description is complete: it states the timeout, behavior when idle, when it is a no-op, and what happens on expiry. An agent has everything needed to decide when and why to call it, apart from the annotation contradiction noted above.

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 the schema description coverage is 100%, so the baseline is 4. The description does not need to explain input semantics because there are no inputs.

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

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

The description clearly identifies the operation: renew the control lease with an explicit timeout of 20000ms to keep output enabled. This is specific and distinct from sibling tools, which focus on connect/disconnect, intensity, or waveform actions rather than lease renewal.

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 states when to call this tool: while idle to keep output enabled, and that it is a no-op when no output is active. It does not explicitly name alternatives or exclusions, but no sibling tool fulfills this lease-renewal role, so the guidance 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 already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds a valuable behavioral detail beyond annotations: the pulse directory is rescanned on every call, so fresh files appear immediately. This explains dynamic behavior an agent would not otherwise know.

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 sentence states the core purpose and returned fields; the second adds a useful behavioral note. The purpose 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 parameterless read-only tool with annotations covering safety, the description is complete enough to invoke correctly. It also compensates for the absent output schema by naming the returned fields, leaving little ambiguity about what the agent will receive.

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 parameters and 100% schema coverage, so there is nothing to document. Per baseline, a parameterless tool receives a 4; the description's mention of returned fields is output semantics, which is acceptable given there is no output 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 uses a specific verb ('List') and names the exact resource ('built-in Coyote presets and external .pulse waveforms'), plus the fields returned (ids, labels, source, natural duration). This clearly differentiates it from sibling tools that connect, play, stop, or adjust — none of which are listing 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 establishes this as the enumeration tool for available waveforms, and the rescan note tells agents this is the way to see newly added or changed files on disk. It does not explicitly mention alternatives, but among siblings it is the only list-style tool, so the usage context is clear.

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 this is a non-read-only, non-idempotent, non-destructive operation, but the description adds important behavioral context: total duration is capped at 10000ms, a safe nonzero intensity is required, and the tool never changes intensity. This goes beyond the structured annotations and helps an agent assess safety and side effects.

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

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

Two sentences, front-loaded with the core action, and every clause adds value: the segment types, single-channel scope, duration cap, and intensity safety precondition. No filler or repetition of schema 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 tool with a rich nested schema and four segment variants, the description covers the key cross-segment constraints: total duration cap, channel scope, and the critical safety requirement that intensity is not changed. It leaves some operational details to the schema and does not describe result/error behavior, but the essential invocation guidance is present.

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

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

Schema description coverage is 100%, so the input schema fully documents each segment type and its parameters. The description's mention of segment kinds adds framing but does not add meaning beyond the schema. Baseline 3 is appropriate here.

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 and resource: 'Compile and play semantic waveform segments' on one channel. It also lists the segment types (ramp, hold, pulse, silence), which distinguishes it from the sibling dglab_play_waveform tool.

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 clearly indicates this tool is for custom waveform segments, implicitly separating it from playing saved/predefined waveforms via dglab_play_waveform. It also states key preconditions: a safe nonzero intensity is required, and the tool never changes intensity. It does not explicitly name alternatives, so it stops short of a 5.

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

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

Adds substantial behavior beyond annotations (readOnlyHint=false, destructiveHint=false): it discloses that playback 'replaces the channel's current waveform task', that it 'requires a safe nonzero intensity', and that it 'never changes intensity'. It also clarifies duration semantics via 'repeat or truncate'. No contradiction with annotations exists — the replacement is a task swap, not data destruction. Note: 'max 10000ms' conflicts with the schema's maximum of 30000, a description-vs-schema inconsistency, not an annotation contradiction.

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

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

Three dense sentences with the primary verb-resource pair front-loaded in 'Play a named waveform'. Each sentence earns its place: matching semantics, duration option, intensity requirement, and replacement side effect. The first sentence's parenthetical is somewhat heavy but packs crucial matching information without bloat.

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?

Covers the essentials for a mutating tool with 5 params and no output schema: what it plays, where (channel), the precondition (safe nonzero intensity), what it does not do (never changes intensity), and side effect (replaces current task). Gaps remain: no behavior for missing waveforms or unsafe intensity, no acknowledgment/return expectations, and the durationMs max discrepancy leaves the agent uncertain which bound is authoritative.

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

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

Schema description coverage is 100%, so the baseline is 3 with no obligation to compensate. The description does add value beyond the schema: case/separator-insensitive matching across ids and English/Chinese names for 'name', and repeat/truncate semantics for 'durationMs'. However, it introduces an error — 'max 10000ms' contradicts the schema's maximum of 30000 — which an agent could mistakenly trust, offsetting the added value.

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 — 'Play a named waveform ... on one channel' — and distinguishes itself from siblings: 'named waveform (built-in preset or hot-loaded .pulse file)' separates it from dglab_play_custom_waveform, while 'never changes intensity' separates it from dglab_set_intensity/dglab_adjust_intensity and 'replaces the channel's current waveform task' from dglab_stop_channel. The behavioral scope 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?

Gives clear usage context: 'Requires a safe nonzero intensity on the channel' states a precondition, and 'never changes intensity' + 'Playback replaces the channel's current waveform task' convey when-not and consequences. However, it never explicitly names sibling alternatives or states 'use dglab_list_waveforms to discover names' or 'use dglab_play_custom_waveform for arbitrary patterns', so the exclusion logic 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?

Beyond the annotations, the description discloses important behavioral constraints: the effective ceiling DGLAB_MAX_INTENSITY=30, the 5-step increase limit, and that reductions and 0 are always allowed. This is valuable operational detail consistent with the idempotentHint and destructiveHint=false 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?

Three concise sentences with no filler. The core operation is stated first, followed by the constraints. 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 4-parameter tool with no output schema, the description plus schema cover the key invocation details: channel selection, target semantics, caps, and step limits. It could be slightly more complete by explicitly noting when to prefer dglab_adjust_intensity, but this is not essential 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 coverage is 100%, so the baseline is 3, but the description adds meaning not present in the schema: the effective ceiling, the step increment rule, and the absolute-target semantics. The schema only provides min/max, so this is a meaningful supplement.

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 action ('Set'), the resource ('one output channel (A or B)'), and the specific semantics ('absolute target on the 0-200 scale'). This inherently distinguishes it from sibling dglab_adjust_intensity, which implies relative adjustment.

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

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

The description provides clear usage context: absolute target setting, the 0-200 scale, the effective ceiling, and the step rule for increases. It does not explicitly mention alternatives like dglab_adjust_intensity for relative changes, but the 'absolute' phrasing gives enough context for most agents.

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 specific behavioral detail beyond the annotations: it clears all waveform tasks and resets intensity exactly to 0 for one channel. The destructiveHint and readOnlyHint annotations are consistent with this behavior, and the description clarifies the exact scope of the destructive action.

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 that immediately states the two effects: clearing waveform tasks and resetting intensity. There is no filler or redundant 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 tool is well covered by a rich annotation set, a 100% documented schema, and a concise accurate description. The main gap is the lack of explicit relationship to emergency_stop or other stopping alternatives, but for basic selection and invocation the definition is largely 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?

Schema coverage is 100%, so all three parameters are already documented with clear descriptions and an enum for channel. The description adds no substantial parameter-level meaning, such as how slotId or clientId affect routing, so the baseline of 3 is appropriate.

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: clear all waveform tasks and reset the intensity of one channel to 0. This clearly distinguishes it from intensity-setting tools and general status tools, though it could be more explicit about how it differs from emergency_stop.

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

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

The description gives no guidance on when to use this tool versus alternatives such as dglab_emergency_stop or dglab_set_intensity. The intended use is only implied by the action described, with no explicit context or exclusions.

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