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

Goes well beyond the annotations: 'Unspecified settings are preserved' discloses partial-update semantics, the gating/restore-of-enable-state sentence describes a real side effect, and the failure clause ('target output is requested off') discloses a safety-relevant behavior on error. This is exactly the extra context the destructive/non-idempotent annotations cannot convey.

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 core action is front-loaded and every sentence carries behavioral information rather than filler. The dense multi-clause sentences (gating/restore, failure handling) make it slightly hard to scan, but 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?

For a 7-parameter mutating tool with no output schema and destructive annotation, it covers side effects, partial-update behavior, model-dependent limits, and failure semantics well. Remaining gaps are the undocumented value/unit semantics of the numeric parameters.

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 clarifies 'enabled' handling, explains the waveform SQUARE vs PULSE distinction, and derives duty_percent behavior, but leaves offset_v, frequency_hz, amplitude_vpp (units, ranges) and the string-vs-integer waveform encoding 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 and resource ('Set channel parameters in wave mode') and adds a verify step, which is enough to distinguish it from sibling writers like set_phase and configure_sweep. It does not explicitly name those siblings, keeping it short of a 5.

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

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

Usage context ('in wave mode', on channel 1/2) is implied but there is no explicit when-to-use vs alternatives such as configure_sweep, set_mode, or set_outputs. The SQUARE/PULSE advice is parameter-level, not tool-selection 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 the destructive, non-idempotent write profile, so the bar is lower. The description adds genuinely useful context that output enable state is preserved and must be changed via set_outputs, but it never explains what the destructiveHint actually destroys or whether the sweep must be stopped first.

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 sentences, front-loaded with the core action and no filler. The 'read back limits' phrasing is slightly ambiguous but the structure is 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 7-parameter, destructive, non-idempotent tool with no output schema and 0% schema description coverage, the description is too thin. It omits the meaning of most parameters and the concrete consequences of the destructive flag, leaving real gaps for an agent to call 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 0% across 7 parameters, so the description carries the full burden. It explains only start (=true starts the sweep) and alludes to the frequency limits; scale, direction, time_s, and channel are left entirely undocumented in both schema and 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+resource: switch to sweep mode, configure and read back limits. An agent can identify it as the sweep-configuration tool and distinguish it from set_mode/configure_channel. It lacks explicit sibling differentiation, so it lands just below top marks.

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 one conditional usage rule (start=true starts the sweep) and routes output control to set_outputs. However, it never states when to prefer this over set_mode or configure_channel, so the guidance is partial and 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new behavioral context: the operation does not open a port (no hardware side effect) and include_points=true escalates the payload to the full amplitude/frequency table. That is meaningful disclosure 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?

Three tight sentences, front-loaded with the core action, then the flag behavior, then the applicability constraint. No filler or repetition of the schema.

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

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

There is no output schema, yet the description tells the agent what comes back (metadata/ranges, or the full point table) and when the tool is applicable. The only shortfall is that the meaning of the 'channel' argument is left unresolved.

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 fully explains include_points=true (returns the full measurement table) but says nothing about 'channel' — whether null means both channels, or what 1 vs 2 selects. Half the parameters are clarified, leaving a real 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 concrete verb and resource ('read measured power calibration metadata/ranges') and adds a distinguishing scope constraint ('without opening a port') that separates it from hardware-affecting siblings like preview_power or set_power. It never names a sibling directly, but the resource and constraint are specific enough to route correctly.

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

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

The description gives a real precondition ('Applies to zero-offset SINE into a physical 50-ohm load through measured cables') and implies when the extra flag is wanted, but it does not name alternatives or state when NOT to use this tool. Usage is inferable 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds genuine value by disclosing the returned fields, which matters because there is no output schema to convey the response shape.

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 listed field earns its place by describing the return payload.

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, read-only query with no output schema, listing the returned fields is the key completeness requirement and it is met. Minor gaps remain, such as error behavior when no device is connected, but 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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description cannot and need not add parameter meaning.

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 (device info) and enumerates the exact fields returned (model code, serial number, port, sine frequency limit). This clearly distinguishes it from siblings like get_state or list_ports, though it does not name any 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?

There is no guidance on when to call this versus get_state, list_ports, or get_manual, all of which could plausibly return overlapping device information. Usage is only implied by the field list, and no prerequisites or exclusions are given.

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/non-destructive, so the safety bar is met. The description adds real behavioral context beyond them: no serial port is opened (no hardware side effects, safe to call without a connected device) and it discloses that source page numbers and discrepancies are surfaced. It could still note caching or size 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?

Three tight sentences, front-loaded with the core action, followed by a compact content list and a behavioral caveat. The content enumeration is slightly list-heavy but each item is informative rather than filler.

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

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

With an output schema present, return-value structure need not be documented, annotations cover the safety profile, and there are no parameters. The description still adds value by previewing what the manual content contains, making it complete 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?

The tool takes zero parameters, so the schema carries no semantic burden and the baseline is 4. The description correctly adds nothing param-related, which 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?

States a specific verb and resource ("Read the bundled manual reference") and enumerates exactly what the manual covers (model/frequency/voltage limits, power estimates, modes, synchronization, protocol notes). "No serial port is opened" cleanly separates it from the hardware-controlling siblings like set_power and configure_channel.

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 this is a reference lookup that requires no device connection, which hints at when it is safe to call, but it never states explicit trigger conditions (e.g. "call this before configuring a channel") or names alternatives. Usage is left to inference.

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, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral detail that omitting the channel reads both channels, but says nothing about response shape, units, or error behavior for an out-of-range channel.

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, zero filler, with the core action stated first and the parameter rule second. 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?

There is no output schema and no annotation detail about the returned data, so the description is the only source of what "state" means. It names mode, phase and channel settings, which is minimally sufficient, but omits return format, units and value ranges that an instrument-control agent would likely need.

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 channel parameter has only an enum of 1/2 with default null, so the description must carry the semantics. It does explain the meaningful distinction (present = one channel, omitted = both), which is exactly the ambiguity the schema leaves open, though it never names which channel values are valid.

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?

Specific verb ("Read") plus a concrete resource set (mode, phase and channel settings), which separates it from siblings like get_calibration, get_manual and get_device_info. It does not explicitly name those siblings, but the resource is narrow enough that an agent can place it.

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?

"Omit channel to read both" is a genuine usage instruction for the optional parameter, implying the tool can be called with no argument to read all channels. However, there is no guidance on when to prefer this tool over get_calibration or the get_* siblings, and no stated prerequisites or ordering constraints.

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, idempotentHint, and destructiveHint=false. The description adds meaningful context beyond them: it performs discovery without opening a device session, so no generator connection or state change occurs. It does not describe output format, but the output schema covers 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?

A single short sentence with no waste, front-loading the action and resource before the clarifying constraint.

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, read-only discovery tool with an output schema, the description covers the essential behavior. It is close to complete; only an explicit pointer on when to prefer this over sibling enumeration tools would add value.

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, which is the baseline 4 case; there is no parameter syntax to explain. The description adds no parameter detail, but none is needed.

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 ("USB serial ports") with a clarifying scope note that it does not open the generator. This clearly separates it from device-control siblings like set_power or get_device_info, though it does not name an explicit 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 phrase "without opening the generator" implies the use case of enumerating available ports before connecting, but no explicit when-to-use/when-not guidance or named alternative is given. Adequate but inferred rather than stated.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about what is listed (built-in names/IDs and the 60 arbitrary slots), but does not disclose anything further about behavior, such as ordering or pagination.

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 that states the tool's scope without any wasted words. It is appropriately sized for a simple list operation.

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 output schema exists, so return values need not be explained. For a zero-parameter, read-only listing tool with a clear one-sentence scope, the description is complete enough for an agent to call 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?

The tool takes zero parameters and the schema is empty, so there is nothing to document. The baseline for zero-parameter tools is 4.

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 gives a specific verb ('List') and a precise resource/scope ('built-in waveform names/IDs and the 60 arbitrary waveform slots'), so an agent knows exactly what content is returned. It does not explicitly distinguish this tool from sibling readers like read_arbitrary or get_device_info, which keeps it from a 5.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as read_arbitrary or get_state. The usage is reasonably implied by the purpose, but no conditions or exclusions are 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?

Beyond the readOnly/idempotent/non-destructive annotations, the description reveals interpolation-only behavior, an output precision limit (1 mV amplitude quantization), and that the result is a prediction rather than a live measurement. These are meaningful fidelity caveats an agent cannot get from the annotations alone.

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 the core computation front-loaded and the caveats trailing. The opening 'Check generator identity' is slightly tangential to the tool's name but not wasteful enough to hurt readability.

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

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

For a 3-required-parameter tool with no output schema, the description usefully characterizes the return value (predicted power, quantized, not live) and the interpolation limitation. It is nearly complete, missing only input unit/range expectations that the schema also omits.

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 carry the parameter burden, and it partially does: it establishes the 50-ohm sine context and that frequency/power are interpolated. However, it never clarifies units, valid ranges, or the meaning of the channel enum, leaving real gaps for frequency_hz and power_dbm.

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 concrete computation ('calculate calibrated voltage for sine power into 50 ohms') plus a preliminary identity check, which is far more specific than a restatement of the name. It implicitly contrasts with the write-capable sibling set_power by noting there are 'no writes', though no sibling is named 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?

Gives a real usability boundary: 'Interpolates measured levels/frequencies; no extrapolation', which tells the agent the tool only works inside the calibrated measurement grid. It implies but does not explicitly state that set_power should be used when an actual change is desired.

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 safety profile is covered. The description still contributes useful behavior context by fixing the read size at all 2048 samples (i.e., no partial reads) and constraining the slot domain, but it says nothing about return format, units, or error behavior for an out-of-range slot.

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 that conveys action, scope (all 2048 samples), and the parameter domain with zero padding. 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 simple single-parameter read whose annotations already cover safety, the definition is adequate but incomplete: with no output schema, the description should describe what the 2048 samples look like on return, and it offers no error or boundary behavior.

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

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

Schema coverage is 0%, so the description must carry the parameter meaning, and it does: it identifies the single arg as an arbitrary-waveform slot with valid values numbered 1..60. That domain constraint is meaningful semantics absent from the bare integer 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?

Specific verb (Read) plus resource (samples from an arbitrary waveform slot) with the exact sample count (2048) and slot domain. An agent can immediately distinguish this read operation from the sibling upload_arbitrary without opening a schema.

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

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

Usage is only implied: the tool reads arbitrary-waveform data, and the counterpart upload_arbitrary is visible among siblings. The description never states when to reach for this versus upload_arbitrary or how it fits a read-after-upload workflow, so guidance is inferred rather than given.

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, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuine beyond-annotation context: unsupported registers may time out, and the call has no mode-selecting side effect. It stops short of describing the returned value shape or timing expectations for valid registers.

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, the core capability and valid range front-loaded, followed by the failure mode and the no-side-effect caveat. No filler and nothing repeated from the schema or annotations.

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 read tool with no output schema and annotations already carrying the safety profile, the description covers the actionable essentials: valid range, timeout risk on unsupported registers, and absence of mode switching. Only the interpretation of returned data is missing, which is minor.

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 schema only says "integer" with no bounds, so the description's 0..89 range is real added value. But it does not explain what individual registers map to (which hold diagnostics vs counter data) or what the returned value means, leaving the parameter only partly compensated.

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?

Specific verb + resource ("Read a protocol register") with a stated valid range (0..89) and a use domain (diagnostics or measurement/counter data). It does not explicitly distinguish itself from the closest sibling read_arbitrary, 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?

"for diagnostics or measurement/counter data" gives clear context for when this is the right call, and "this does not select a mode" is a useful negative hint. However it never names an alternative tool or states an explicit when-not-except-for-mode-selection condition, so usage remains implied rather than directed.

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 as destructive and non-idempotent. The description adds two useful behavioral details beyond annotations: it stops current actions (clarifying what is disrupted) and it verifies the selected mode (post-condition check). It still omits any permission or blocking behavior details.

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, front-loaded with the destructive side effect and then the selection and verification steps. Every word earns its place; no filler.

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

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

For a one-param enum tool with safety annotations and no output schema, the description covers the basic action and side effect. It omits what the modes mean and how the tool relates to siblings like configure_channel, leaving the agent with an incomplete operational picture.

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

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

Schema description coverage is 0% and the single 'mode' parameter is an enum with nine values, none explained. The description says 'operating mode' but does not add meaning for any enum value or constraints, so it fails to compensate 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 names a specific action ('select the operating mode') and a concrete side effect ('Stop current actions'), so the purpose is clear. However, it offers no differentiation from siblings such as configure_channel or set_outputs, which could also change device behavior.

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: use this tool to change the operating mode, and be aware it stops current actions. There is no explicit guidance on when to choose set_mode over configure_channel/set_outputs or 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 carry the safety profile (destructiveHint=true, readOnlyHint=false, idempotentHint=false). The description adds one genuinely useful trait beyond them: partial-update semantics where omitted channels keep their current state. It does not add anything further (no error behavior, no effect on signal/power 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 tight sentence with zero filler, and the most decision-relevant constraint ('independently... preserving unspecified output state') 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?

The tool is simple (2 optional booleans, no output schema, no nesting), and the description covers purpose plus the partial-update behavior. It leaves unanswered what the two channel parameters map to and what happens on failure, which matters given the zero schema description coverage.

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

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

Schema coverage is 0%, so the description must compensate. It does partially: 'preserving unspecified output state' explains that a null/omitted channel leaves state unchanged, which is the key semantic for the two optional boolean params. It never maps ch1/ch2 to specific channels or states the true/false meaning explicitly, so the agent still infers the per-parameter mapping.

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 pair ('Enable or disable') and a specific resource ('outputs'), and the words 'independently' and 'preserving unspecified output state' distinguish it from the sibling stop_outputs, which presumably acts on all outputs at once. Clear enough for an agent to choose between them, though neither sibling is named 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?

Usage context is implied rather than stated: 'independently' and 'preserving unspecified output state' signal this is for selective/per-output changes rather than a bulk stop. There is no explicit when-to-use-this-vs-stop_outputs routing, so the agent must infer 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 declare readOnlyHint=false, idempotentHint=false, and destructiveHint=true, so the safety profile is already covered. The description adds the normalized range and a readback behavior, which is useful context, but does not explain what is destructive, whether the change is reversible, or what the readback returns.

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 that packs purpose, range, and readback without wasted words. It is appropriately sized for a 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?

For a simple one-parameter mutation, the description covers purpose, value range, and readback, while annotations handle the destructive safety profile. It stops short of explaining the readback output or the operational context of inter-channel phase, but no output schema exists and the remaining gaps are minor.

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

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

Schema coverage is 0%, so the description must compensate. It does so well for the single parameter by specifying the normalized range 0..359.9 degrees, implying units and precision; it does not clarify accepted fractional values or wrap-around behavior, but it adds substantial meaning beyond the bare 'phase_deg' schema field.

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 ('inter-channel phase'), making the tool's function unambiguous. It does not, however, distinguish this from sibling tools like set_power or configure_channel, so an agent gets no routing signal beyond the resource 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?

Provides no when-to-use or when-not-to-use guidance, and does not mention any alternatives or prerequisites. The agent must infer that this is the tool for phase adjustments from the purpose 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?

Despite annotations covering the safety profile (destructiveHint=true, idempotentHint=false), the description adds substantial specifics: it forces waveform=SINE, DC offset=0, duty=50, preserves enabled state unless supplied, folds measured cable loss into the predicted dBm, and notes it reads registers rather than remeasuring with the scope. This is exactly the beyond-annotation context an agent needs.

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

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

Front-loads the core action in the first sentence and each following sentence carries distinct constraint information (prerequisites, side effects, measurement caveat). Dense but nearly every clause earns its place; slightly heavy phrasing costs it the top mark.

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, non-idempotent mutation with no output schema, the description covers prerequisites, applied defaults, state preservation, and the measurement caveat. It stops short of describing failure/error outcomes, but the essential calling context 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?

With 0% schema coverage the description must compensate, and it explains frequency/amplitude, the predicted-dBm meaning of power, and that enabled is preserved unless supplied. The channel parameter is only indirectly implied by 'matching serial number', so one parameter remains underspecified.

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), a precise resource (calibrated sine power into a physical 50-ohm load), and the mechanism (measured table / register readback). This clearly distinguishes it from preview_power (predicts without applying) and configure_channel (general configuration).

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 real prerequisites and exclusions: 'Requires wave mode and matching serial number' and 'other loads/waveforms are unsupported.' It establishes when the tool is valid, though it never explicitly names preview_power as the alternative for a dry-run.

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, idempotentHint=false and destructiveHint=true, so the mutation/safety profile is covered. The description adds useful scope (which action types are stopped and that both channels are disabled), but says nothing about whether the stopped operation can be resumed, whether channel configuration is preserved, or what happens on a redundant call.

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 that leads with the action and immediately qualifies the target and effect. No filler, no 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?

For a zero-parameter tool with no output schema and safety already conveyed by annotations, the description covers what the agent needs to decide to call it. Minor gap: it does not say whether configuration state is retained after the stop.

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 no parameters, so there is no parameter semantics for the description to clarify; the baseline for a zero-parameter tool applies. Nothing in the description misrepresents the empty 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 verb ('Stop') and enumerates the exact operation types it terminates (sweep/counter/pulse/burst) plus the secondary effect of disabling both output channels. This clearly distinguishes it from siblings like set_outputs and configure_sweep, which start or shape operations rather than halt 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?

The description implies the usage context (halting active waveform/pulse generation), but it never states when to prefer this over set_outputs or configure_channel, nor any prerequisite such as needing an active sweep. Usage is inferable but not 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is partly covered. The description adds real context beyond them: the overwrite scope (storage only), the readback verification step, and the explicit clarification that it does not affect output routing or slot selection. It does not cover failure behavior or what happens to an invalid sample value.

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 action and its constraints, followed by the scope limitation. Every clause carries information; nothing is redundant.

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

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

For a two-parameter write tool with no output schema, this covers the action, both parameter constraints, the destructive scope, and the readback verification. The remaining gap is error/validation behavior on out-of-range inputs, which an agent might need before calling.

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 the parameters — and it does: slot is constrained to 1..60, samples must be 2048 integers in 0..4095. Both parameters gain constraints absent from the schema. It does not state what happens when slot or sample count is out of bounds.

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 (Overwrite) plus resource (slot 1..60 with 2048 samples), and bounds the purpose with concrete constraints (0..4095 values, readback verification). It is clearly distinguishable from the sibling read_arbitrary by naming the write/overwrite semantic.

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 second sentence gives explicit negative guidance: it does not select the slot or enable output, implying those are separate operations (set_outputs/configure_channel). That is genuinely useful routing context, though it never names the specific sibling tool to use for those follow-on steps, so it stops short of a full when/when-not/alternative statement.

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